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