Endpoints are attached to the pods of each service. They are created and handled by services.
Below is an example of an "nginx-server" service with two endpoints with the IPs "10.150.1.10" and "10.150.3.30" on port "80":
Endpoints contain a combination of ports and IP addresses as we could see below, in a manually created endpoint Yaml configuration file:
Requests to the service backing the endpoints will be load-balanced between the supplied IPs.
In our case, we have just one "ready", namely"10.1.1.1" on port "8080".
We also notice that there are "ready"IP addresses - pod IPs which readiness probe was successful -, and "not ready" IP addresses - pod IPs which readiness probe was not successful -
We could check the endpoints, to see the state of the pods:
We could also use the "describe" command to have more details:
We could "watch" the endpoints "live" using the below command:
In big clusters, with huge number of pods, we would end up with a sizeable endpoint object, which means more work for the etcd server and the API server, also more data would be exchanged throughout the cluster network.
Endpoint slices help mitigate that, they also make the routing process of the "kube-proxy" more manageable.
Below is an example of two endpoint slices for the the "nginx-server"service with one IP each, "10.150.1.10" and "10.150.3.30" on port "80":
Kubernetes creates one endpoint per service, and the service divides that endpoint into smaller easily manageable endpoint slices, resulting in less data transfer across the kubernetes cluster.
Below is an example of a manually created endpoint slice:
The maximum number of IPsin an endpoint slice - in our example, we have just one - is defined in the parameter "--maxendpoints-per-slice", which we could pass to the kubernetes controller manager.
We could check the endpoint slices using the below command: