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 <https://kubernetes.io/docs/concepts/workloads/pods/pod/#termination-of-pods> 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 email@example.com. Visit this group at https://groups.google.com/group/kubernetes-users. For more options, visit https://groups.google.com/d/optout.