In Kubernetes networking, Services provide a stable IP for a set of Pods, but the actual traffic routing requires mapping that stable IP to dynamic Pod IPs. This is where Endpoints and EndpointSlices function as the glue between Services and Pods.
**Endpoints** represent the legacy mechanism. When…In Kubernetes networking, Services provide a stable IP for a set of Pods, but the actual traffic routing requires mapping that stable IP to dynamic Pod IPs. This is where Endpoints and EndpointSlices function as the glue between Services and Pods.
**Endpoints** represent the legacy mechanism. When a Service uses a label selector, the control plane creates a single Endpoints object listing the IP addresses and ports of all matching Pods. The `kube-proxy` on every node watches this object to configure iptables or IPVS rules. However, this has scalability limitations. In large clusters with thousands of Pods behind a Service, the Endpoints object becomes massive. Adding or removing a single Pod requires re-transmitting the entire huge object to every node, causing significant network strain.
**EndpointSlices** were introduced to solve this bottleneck. Rather than one monolithic object, the backing Pods are grouped into multiple smaller resources (slices), usually containing up to 100 endpoints each. When a Pod changes, only the specific slice containing that Pod updates, and only that small update is sent to the nodes. This drastically improves performance and scalability.
For the **CKA exam**, you must understand that while you define Services, connectivity fails if the Endpoints are not populated. If a Service is unreachable, use `kubectl get endpoints` or `kubectl get endpointslices` to verify that the Service's selector is correctly finding the Pod IPs. If the list is empty, your labels likely do not match.
Mastering Endpoints and EndpointSlices for CKA
1. Why is this Important? Kubernetes Services provide a stable Virtual IP (ClusterIP), but they do not process traffic themselves. Traffic must be forwarded to actual containers. Endpoints and EndpointSlices are the critical directory mechanisms Kubernetes uses to track the dynamic IP addresses and ports of the Pods that back a Service. Without them, the Service acts as a signpost pointing nowhere. Understanding this is vital for troubleshooting connectivity issues where a Service exists but cannot reach the application.
2. What are they? Endpoints (The Legacy Resource): An Endpoints object is a generated list of IP addresses and ports. Traditionally, when a Service is created, an Endpoints object with the same name is automatically created to store the IPs of the matching Pods. EndpointSlices (The Scalable Successor): As clusters grew, updating a massive, single Endpoints object every time a Pod changed became a performance bottleneck. EndpointSlices split these lists into smaller chunks (slices) to allow for greater scalability (thousands of Pods per Service). Kube-proxy now consumes EndpointSlices by default.
3. How it Works The workflow is automated via Label Selectors: 1. You create a Service with a selector (e.g., app: frontend). 2. The Control Plane (EndpointSlice Controller) watches for Pods matching this label. 3. It collects the IPs of Ready Pods and populates the EndpointSlice (and Endpoints for backward compatibility). 4. Kube-proxy on every node reads these Slices and updates iptables or IPVS rules to ensure traffic hitting the Service IP is forwarded to one of the specific Pod IPs listed.
4. How to Answer Questions in the Exam In the CKA, you generally encounter these resources in two contexts: Troubleshooting and External Services.
Scenario A: Troubleshooting Connectivity If a Service cannot access its Pods, you must verify the link. Command:kubectl get endpoints <service-name> If the ENDPOINTS column is <none> or empty: - Check if the Service selector matches the Pod labels exactly. - Check if the Pods are in a Running and Ready state. A failing Readiness Probe removes a Pod from the Endpoints list immediately.
Scenario B: Connecting to an External DB (Manual Endpoints) You may be asked to create a Service that points to an IP outside the cluster (e.g., a legacy database). 1. Create a Service without a selector. 2. Manually create an Endpoints object with the exact same name as the Service. 3. Add the external IP and Port to the Endpoints manifest.
Exam Tips: Answering Questions on Endpoints and EndpointSlices 1. Readiness is Key: If an exam question mentions traffic failing to reach specific Pods, check the readiness probe. Only Ready pods appear in Endpoints. 2. The Name Match Rule: When creating manual endpoints (for external services), the metadata.name of the Endpoints object MUST match the Service name. 3. Stick to 'get ep': While EndpointSlices are the underlying technology, for exam inspection purposes, kubectl get endpoints (or ep) is easier to read and sufficient for debugging. 4. Debugging Typos: The most common reason for an empty Endpoints list is a typo in the Service selector. Compare kubectl describe service <name> with kubectl get pods --show-labels.