Kubernetes Advanced Deployment Strategy - Part 3

A quick update regarding my last post: while I didn't discuss services and routes in detail, I wanted to address how Kubernetes routes traffic to the isolated Pod. I only had one label as part of the Deployment in my previous post, specifically app: echoapp. Only having one label will cause the Kubernetes service and, therefore, the route to stop sending traffic to that Pod when we modify the Pod to remove that label.

Services use labels to determine what Pods should be handling traffic. As an example, this is a Service definition we could use for our Deployment:

apiVersion: v1
kind: Service
metadata:
  name: echo-service
spec:
  selector:
    app: echoapp    
  ports:
    - name: http
      protocol: TCP
      port: 8080
      targetPort: 8080

Notice the selector field also specifies the same app: echoapp label. If we modify our Pod to remove this label, the Service will no longer send traffic to that Pod. In some cases, this behavior can be desired; you may want to allow a pod to finish processing any inflight transactions but not send any more work. But in the scenario we discussed in my first post, we would want the Service to continue to send traffic to the isolated Pod (at least at first, more on this later).

There's a straightforward fix: Add another label to our Deployment and reference it in the Service selector. In this example, I added the label "backend: default".

deployment.yaml
...
  replicas: 3
  selector:
    matchLabels:
      app: echoapp
  template:
    metadata:
      labels:
        app: echoapp
        backend: default

We can now reference this label in our Service:

apiVersion: v1
kind: Service
metadata:
  name: echo-service
spec:
  selector:
    #app: echoapp
    backend: default
  ports:
    - name: http
      protocol: TCP
      port: 8080
      targetPort: 8080

Applying these changes will allow the isolated Pod to continue to receive traffic.

We can use this same concept to stop traffic from being sent to the isolated Pod once we're ready to shut it down. Edit the isolated Pod to remove the "backend: default" label. The Pod will no longer be part of the Service, and it will no longer receive traffic. Once the application running in the Pod has finished processing, the Pod can be safely stopped. This technique can be used on any Pod even if it's not isolated from a Replica Set.