Doubt on lecture on CKA

As I am studying through the CKA course I have noticed that in the “services” lecture I have noted that while creating the yaml for the service object we are not using the “matchLabels” directive which is required by selectors to identify which port of the pod is to be connected to the service instead of that simply the contents under the labels section of the pod were written


can someone explain this?

selector in the service-definition.yml, does not identify which port of the pod it is to be connected to, that is defined under ports section, rather it is used to select the pod itself(from a group of pods in this case) from the cluster.

You can read more about Labels and Selectors from the official docs.

Service and ReplicationController

The set of pods that a service targets is defined with a label selector. Similarly, the population of pods that a replicationcontroller should manage is also defined with a label selector.

Label selectors for both objects are defined in json or yaml files using maps, and only equality-based requirement selectors are supported:

Resources that support set-based requirements

Newer resources, such as Job, Deployment, ReplicaSet, andDaemonSet, support set-based requirements as well.

1 Like

Hi srikanth thanks for your reply but my question is
when im studying about pods and replicasets/deployments it is clear to me that under the selectors we are using matchLabels: below this is where we give the labels of the pod which needs to be connected to the replicaset similarly in my context the matchLabels: is not used by service-definition.yaml where we simply paste the labels contents don’t we need the matchLabels option on the service-definition.yaml?

um… selectors.
In short, yes, we don’t need to specify matchLabels option in the service-definition.yaml

Disclaimer: this is just my understanding, I can be wrong as well.

Service’s selector field is designed to identify the set of pods it routes traffic to and that is done using a simple key-value match. It only works by matching labels, hence you don’t have to explicitly specify to match. This is by design.

Whereas in case of deployments, replicates, etc, these require more advanced logic for managing pods, hence the need for matchLabels and matchExpressions.

selector:
  matchLabels:
    component: redis
  matchExpressions:
    - { key: tier, operator: In, values: [cache] }
    - { key: environment, operator: NotIn, values: [dev] }

Hope this helps.

1 Like

service has only a simple selector for labels

controlplane $ kubectl explain service.spec.selector
KIND:       Service
VERSION:    v1

FIELD: selector <map[string]string>

map[string]string is golang-speak for key value pairs which is what the service selector field wants - in this case key is label names and value is label values.

Now if we look at deployment

controlplane $ kubectl explain deployment.spec.selector
GROUP:      apps
KIND:       Deployment
VERSION:    v1

FIELD: selector <LabelSelector>
 
FIELDS:
  matchExpressions      <[]LabelSelectorRequirement>

  matchLabels   <map[string]string>

…it is more complex and the above explain relates to what is posted above by @Srikanth_Reddy

A <labelSelector> is

matchExpressions:
matchLabels:

One, the other or both.

<[]LabelSelectorRequirement> denotes list of LabelSelectorRequirement where that looks like { key: tier, operator: In, values: [cache] }

2 Likes