How to select a specific pod for a service in Kubernetes

Hotstepper13 picture Hotstepper13 · Dec 15, 2016 · Viewed 11.9k times · Source

I have a kubernetes cluster of 3 hosts where each Host has a unique id label. On this cluster, there is a software that has 3 instances (replicas).

Each replica requires to talk to all other replicas. In addition, there is a service that contains all pods so that this application is permanently available.

So I have:

Instance1 (with labels run: theTool,instanceid: 1)
Instance2 (with labels run: theTool,instanceid: 2)
Instance3 (with labels run: theTool,instanceid: 3)

and

Service1 (selecting pods with label instanceid=1)
Service2 (selecting pods with label instanceid=2)
Service3 (selecting pods with label instanceid=3)
Service (selecting pods with label run=theTool)

This approach works but have I cannot scale or use the rolling-update feature.

I would like to define a deployment with 3 replicas, where each replicate gets a unique generic label (for instance the replica-id like 1/3, 2/3 and so on).

Within the services, I could use the selector to fetch this label which will exist even after an update.

Another solution might be to select the pod/deployment, depending on the host where it is running on. I could use a DaemonSet or just a pod/deployment with affinity to ensure that each host has an exact one replica of my deployment.

But I didn't know how to select a pod based on a host label where it runs on.

Using the hostname is not an option as hostnames will change in different environments.

I have searched the docs but didn't find anything matching this use case. Hopefully, someone here has an idea how to solve this.

Answer

Tim Allclair picture Tim Allclair · Dec 15, 2016

The feature you're looking for is called StatefulSets, which just launched to beta with Kubernetes 1.5 (note that it was previously available in alpha under a different name, PetSets).

In a StatefulSet, each replica has a unique name that is persisted across restarts. In your example, these would be instance-1, instance-2, instance-3. Since the instance names are persisted (even if the pod is recreated on another node), you don't need a service-per-instance.

The documentation has more details: