liveBook · Manning

Endpoints object

As explained in Kubernetes in Action, Second Edition

A service endpoint is a network destination representing a pod that is currently eligible to receive traffic through a Kubernetes Service.

A Kubernetes Service gives clients a stable address, even when the pods behind it change. An Endpoints object holds the destination IP addresses and ports for that Service. It has the same name as the Service; the destination list is not stored in the Service object itself. Endpoints can also point to destinations other than pods. section 11.3.1 section 11.3

To inspect the destinations, run `kubectl get endpoints`, or use its shorthand, `kubectl get ep`. Then run `kubectl get ep kiada -o yaml` for the full object. Each subset groups addresses that use the same ports. A pod-backed address can include a `targetRef` identifying its pod. section 11.3.1

$ kubectl get ep kiada -o yaml
apiVersion: v1
kind: Endpoints
metadata:
  name: kiada           #1
  namespace: kiada      #1
  ...
subsets:
- addresses:
  - ip: 10.244.1.7          #2
    nodeName: kind-worker     #3
    targetRef:
      kind: Pod
      name: kiada-002          #4
      namespace: kiada         #4
      resourceVersion: "2950"
      uid: 18cea623-0818-4ff1-9fb2-cddcf5d138c3
  ...      #5
  ports:              #6
  - name: https       #6
    port: 8443        #6
    protocol: TCP     #6
  - name: http        #6
    port: 8080        #6
    protocol: TCP     #6

The YAML shows how one subset pairs a pod address with its HTTP and HTTPS destination ports. section 11.3.1

For a Service with a label selector, Kubernetes creates and updates the Endpoints object as matching pods appear or disappear. A matching label alone does not mean a pod should receive traffic: readiness matters too. A pod that is not ready can appear under `notReadyAddresses` rather than `addresses`. A readiness probe lets an application delay traffic until it can handle requests; probe failure removes it as a service endpoint without restarting it. section 11.3.1 section 11.6.2 section 11.6.1

To supply destinations yourself, create a Service without a label selector and an Endpoints object with the same name. Put the destination IPs and ports in its subsets. This can give pods a cluster Service name for an existing external service. Kubernetes creates corresponding EndpointSlice objects from the manually created Endpoints object; you do not need to create those separately. section 11.3.3

Listing 11.6 An Endpoints object created by hand
apiVersion: v1
kind: Endpoints
metadata:
  name: external-service     #1
subsets:
- addresses:
  - ip: 1.1.1.1     #2
  - ip: 2.2.2.2     #2
  ports:
  - name: http      #3
    port: 88        #3

This manifest supplies two destination IPs on port 88 for a selectorless Service named `external-service`. section 11.3.3

How Kubernetes in Action, Second Edition covers it

How deep it goes
Explains object naming, subsets, inspection, automatic updates, manual creation, and readiness-related address placement without detailing routing implementation.
Examples
Uses `kubectl get ep` YAML, a selectorless Service with two external IPs, and an unready pod in `notReadyAddresses`.
What you can do after
Operate/configure it with `kubectl` and manifests to inspect service destinations or supply them for a selectorless Service.
How it connects
Connects Endpoints to Services, label selectors, pods, readiness probes, and EndpointSlices.

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Kubernetes in Action, Second Edition. The section links point to the parts of the book it draws on.