3 Answers
Since for feeding the entry in that endpoint object u need to have some selector(act as an identifier to identify the pods) whose info needs to be updated in the endpoint object. So that when Service needs to route the request to the pods it can be done on the fly by getting any random(not exactly) pods details to route the request to.
There are lots of registered are running pods. The service endpoint only cares about a subset of them, from them it can choose one when a request comes and forward the request to. In order to define the relationship between services and pods the labels are needed – each pod defines its labels and each service defines a set of pod labels it cares about.
A lot of articles & courses glance over this tiny detail.
There are labels and label selectors.
Labels live under Deployments (ie Pods, containers).
Label selectors live under Services.
You define "labels" as a metadata type, and then assign key-value pairs. Like so:
metadata:
labels:
name: searchapi
type: storefront-api
Where "name" and "type" can be anything you want, similarly for the value.
You then assign a "selector" (ie label selector) under the "spec" type. In the "selectors", you define the labels to look out for:
spec:
selector:
name: searchapi
type: storefront-api
:)!