CODEWITHSUNDEEP
kubernetes
Zavolokin Roman
Zavolokin Roman

Reputation: 165

How to remove pod from service without deleting it

I am looking for an option to remove pod from deployment/replication without deleting it. I found a good solution by using selector and labels here, but it's impossible in my case since I am not a pod/service creator so I can't force selector creation. My application just manipulates pods of existing services.

Many thanks for a help

Upvotes: 9

Views: 9777

Answers (3)

Shimran George
Shimran George

Reputation: 41

Pretty much what Javier said, but with some more detail.

First find the service in front of your pod, and find the selector:

kubectl describe svc

selector:          
  component=my-app

The selector will be associated with some labels. The labels are matched with labels in each pod spec.

Find the pod you want to take out of service and edit it's pod spec by removing the label associated with the selector in the service space:

kubectl edit pod <PODTOTAKEOUT>

labels:  
  environment: my-environment  
  component: my-app # Delete or comment out

The deployment will spin up a new pod, but the pod you just edited will no longer have traffic routed to it. You can verify by using kubectl get endpoints to make sure the podIP is not in the service spec.

Upvotes: 4

Darrin West
Darrin West

Reputation: 328

You could use a readiness probe on the pod. Then find your own way to make that probe fail. As soon as a service detects a pod is not ready, it is removed from the set of pods a service will forward connections to. This doesn't kill the pod, nor cause it to restart (liveness probe does that). It also does not disconnect current clients. You may want to wait for those connected clients to drain away if your plan is to eventually restart the pod.

One idea for doing this: use jmx or a rest call on the specific pod's ip and make the implementation of that tell the application to return not-ready for the readiness implementation. Same trick to switch it back to ready, or delay readiness on startup until you manually trigger that pod (e.g. if you are having the pod do some expensive startup like a DB scan/update).

Upvotes: 7

Javier Salmeron
Javier Salmeron

Reputation: 8827

AFAIK the service should have a selector (for instance, to a label), otherwise, how does the service know which pods provide the required service? Even though you may not be able to change the selection mechanism in the service itself, you could try changing the labels in the pod. If you can manipulate pods, you can remove its labels, and thus render it unselectable by the service.

Upvotes: 2

Related Questions