Labels and Selectors

[khokha]

Hello,

What is the difference between labels and selectors?

which one of them would cause the Pod, Service not working if they don't match to the correct value?

In the above picture, there're different labels and selectors applied to both service and pod, so what should i look for if the service has no endpoint or the pod is CrashLoopBackOff state regarding labels and selectors?

Thanks

[Travis]

@khokha -

Labels are key-value pairs (dictionaries) that you attach to objects allowing you to identify and organize objects. Labels are usually attached at creation time and the keys for these labels are unique. This allows you to collect information and have more robust searches and output from things like the oc get command.

A selector (is a label selector) and again a key/value pair. In this instance, the selector is use as a "grouping" method as you can build this from a list, but more importantly, you are "choosing" the label(s) for resources you want to use.

In terms of your question, both labels and selectors could potentially cause things not to work as you must be selecting a valid value. If you don't have anything that matches, resources won't be created.

In terms of CrashBackoffs, most of what I see in class for this is people have messed up providing the container image or some other typo in the custom resource definition files. You can do  oc get events and then use oc logs XXX to help narrow things down a bit and identify the culprit. Normally, this is with a "resource" being specified and not being found, most of the time, it is the result of a typo.

[Chetan_Tiwary_]

Hello @khokha !

Thanks for reaching out !

Labels are key/value pairs that are attached to objects such as Pods, ReplicaSet,  Deployments, Services, etc. 

Label Selectors depend on labels to select a group of resources such as pods. Selectors can be used in a variety of ways, such as to select the Pods that a Service should expose, or to select the Pods that a Deployment should manage.

Here, ponder over this :

1. service is an abstraction that defines a logical set of pods as well as a policy for accessing the pod set. The selector  in service selects particular pods ( endpoints )  in the backend based on one of the labels that pods have. 

So, if the Service has no endpoints, then it is likely that the labels on the Pod do not match the selector on the Service.

A pod can have multiple labels - service has to select based on any label specificed on the pod. Or you can apply a label to the pod which the service selector is seeking .

Now, NodeSelector : same way as the service "selects" pods based on the pod "labels" , we can constraint or restrict the pods to schedule on a particular node by specifying the NodeSelector and Node labels : specify the node labels you want the target node to have and K8s  only schedules the Pod onto nodes that have each of the labels you specify.

Another issue you mentioned about is CrashLoopBackOff : which means pods are failing, and they are being restarted. The grace period , in between the consecutive restarts is what is represented as CrashLoopBackOff. It can happen due to misconfiguration or may be due to a resource not available at that time.

Refer this post for details : https://learn.redhat.com/t5/DO280-Red-Hat-OpenShift/CrashLoopBackOff-in-K8s/m-p/35221#M18 

[khokha]

Thank you @Travis @Chetan_Tiwary_ 

I've another question, which error is shown when the service's selector doesn't match the pod's label, other than that the service has no endpoint?

How can i know from the logs or events that there's something misconfigured in the service's selector?

Thanks

[Chetan_Tiwary_ · Accepted solution]

@khokha for example one can get HTTP 503 Service Unavailable error too if the service tried to route a request to a pod but could not find any pods matching its selector. 

Check oc get endpoints to confirm if the service endpoints are there or not as expected. Or use oc get pods -l label=labelname to check the pods with expected labels. Then use oc describe svc or oc describe pod match the specifications as mentioned in the manifest yaml for each of the object. 

I don't remember all the error in the logs regarding this - it depends upon what is the exact issue you have in your project resources but oc get events  &  oc logs  do give enough information about potential errors / misconfigurations / issues. 

[khokha]

@Chetan_Tiwary_ 

For the deployment/deploymentconfig the selector or labels must match one of those for the pod?

[Chetan_Tiwary_]

@khokha With the selector field in the spec section of Deployment, the pods will be part of deployment if the labels in the pod's template match with that of the selector's field.

selector: matchLabels tells the deployment to match the pod, according to that label. In other words, deployment uses the labels to ensure that the pods it is managing are the correct pods.