When you terminate a pod (either directly or indirectly through more 
abstract objects like a Deployment), the kubelet sends a TERM signal to 
your pod. You can extend your application to catch this signal, trigger the 
shutdown procedure (in your case apparently "send the logs to the other 
place"), and terminate eventually. As soon as the termination procedure is 
initiated, your pod's endpoints will be removed asynchronously, which 
should cause load-balancer-like intermediaries (like Sevices and Ingress 
controllers) to remove the pod from rotation (thereby draining requests). 
Make sure though you set the graceful termination period parameter high 
enough so that your pod isn't SIGKILLed by the kubelet prior to it being 
able to conclude the shutdown.

What Kubernetes does behind the scene is mark your pod as unready as soon 
as the termination phase begins. It's also possible to trigger this event 
manually by installing a readiness check into your pod and letting it fail 
when you want to stop receiving traffic. This would be a way to drain the 
pod "during runtime".

The documentation on the pod termination sequence 
provides additional information.

Hope this helps!

On Tuesday, August 8, 2017 at 11:00:06 AM UTC+2, Jeremy Woo wrote:
> I have a question about `services` , for example, I have a pod which 
> version is v1 and it receive the traffic from the `services`, now I have 
> create a new pod which version is v2 and I want to terminate the v1 pod, 
> but the logs in the v1 pod should be sent to other place and would take 
> some time, so  how can I ensure that no traffic send to v1 pod during send 
> logs ?

You received this message because you are subscribed to the Google Groups 
"Kubernetes user discussion and Q&A" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to kubernetes-users+unsubscr...@googlegroups.com.
To post to this group, send email to kubernetes-users@googlegroups.com.
Visit this group at https://groups.google.com/group/kubernetes-users.
For more options, visit https://groups.google.com/d/optout.
  • [kubernetes-user... Jeremy Woo
    • [kubernetes... 'Timo Reimann' via Kubernetes user discussion and Q&A

Reply via email to