Kubernetes networking is easiest to understand when it is treated as an identity and reachability problem rather than a list of objects. Pods are intentionally replaceable, and their addresses can change as replicas are recreated or moved. Applications still need dependable ways to find one another, receive traffic, and communicate across nodes. Service discovery is the mechanism that lets a dynamic cluster present stable destinations even though the workloads behind those destinations keep changing.<\/p>\n
The current KCNA<\/a> treats networking and service discovery as foundational cloud-native knowledge. The expected depth is conceptual: know why stable service identity is needed, what Kubernetes Services accomplish, how DNS participates, what a cluster network must make possible, and where technologies such as service mesh<\/a> begin to add another layer. The goal is not to memorize every networking plugin or become a production network engineer.<\/p>\n That scope matters because networking problems often look like application problems. A healthy Pod can be unreachable because the Service selector is wrong. A Service can exist while no ready endpoint is available. DNS can resolve a name correctly while a policy or data-path problem blocks traffic. Good reasoning follows the path from identity to discovery to endpoint selection to network delivery.<\/p>\n A Pod is a runtime object, not a permanent host. When a controller replaces a failed replica, the new Pod can receive a different IP address. Scaling creates additional endpoints, while rollout or rescheduling removes old ones. Hard-coding Pod IP addresses would couple clients to identities that Kubernetes never promises to preserve.<\/p>\n This is why the cluster network and service-discovery model are built around indirection. Workloads communicate through stable logical names while Kubernetes keeps track of the changing set of endpoints behind those names. The abstraction is valuable precisely because the infrastructure underneath it is dynamic.<\/p>\n For KCNA-level reasoning, separate two questions. First, can one Pod reach another Pod across the cluster network? Second, how does a client discover which current endpoint represents the service it wants? Networking answers the first; Services and discovery mechanisms help answer the second.<\/p>\n A Kubernetes Service groups a set of Pods behind a stable virtual identity. Most commonly, labels and selectors define which Pods belong to that Service. Clients do not need to know which replica is currently healthy or where it runs. They use the Service identity, and Kubernetes routes traffic toward eligible backend endpoints.<\/p>\n That stable identity is what allows replicas to scale or roll without forcing every consumer to update configuration. A Deployment can replace all of its Pods during an upgrade while the Service name remains unchanged. This is a classic cloud-native design pattern: stable contracts in front of replaceable implementation instances.<\/p>\n Different Service types expose that identity in different ways. ClusterIP is primarily internal, NodePort exposes a port on nodes, LoadBalancer integrates with an external load-balancing mechanism, and ExternalName maps a Service name to an external DNS name. KCNA candidates should recognize the purpose of these forms without treating them as interchangeable.<\/p>\n Inside a Kubernetes cluster, DNS lets applications resolve service names instead of carrying IP addresses in configuration. A client can refer to a Service by a DNS name, and the cluster DNS service returns information that leads the client toward the correct service endpoint. This is one of the most practical forms of service discovery in Kubernetes.<\/p>\n DNS does not replace the Service abstraction. DNS gives the client a discoverable name; the Service represents a stable network identity and endpoint set. Understanding that layering prevents a common troubleshooting mistake: assuming a successful DNS lookup proves the entire application path works.<\/p>\n Name resolution can succeed while the Service has no ready endpoints, while traffic is blocked, or while the application is listening on a different port than expected. Troubleshooting therefore checks discovery and reachability separately.<\/p>\n The Service selector is a small configuration detail with large operational consequences. If the selector does not match the intended Pods, the Service can exist normally while sending traffic nowhere useful. If it matches the wrong workload, traffic can reach healthy but incorrect backends.<\/p>\n Endpoint information is therefore valuable evidence. It tells the operator which Pod addresses Kubernetes currently associates with the Service. A mismatch between expected replicas and actual endpoints points toward labels, selectors, readiness, or controller state rather than DNS itself.<\/p>\n This illustrates a useful diagnostic sequence: verify the Service object, inspect the endpoint set, confirm Pod readiness, and only then chase lower-level packet paths. Starting with the logical relationship often narrows the problem faster than immediately inspecting network interfaces.<\/p>\n Kubernetes assumes a networking model in which Pods can communicate through the cluster network without every application managing manual address translation. The concrete implementation depends on the environment and networking plugin, but the architectural expectation is that workload addressing and routing are coherent across nodes.<\/p>\n This is where the Container Network Interface, or CNI, enters the picture. CNI-based plugins help configure Pod networking and can add capabilities such as routing, network policy, or observability. KCNA candidates need the role of the interface and ecosystem more than vendor-specific implementation detail.<\/p>\nPod addresses are temporary by design<\/h2>\n
A Service creates a stable access point<\/h2>\n
DNS turns service identity into something applications can use<\/h2>\n
Selectors and endpoints connect the abstraction to real Pods<\/h2>\n
The cluster network must support direct workload connectivity<\/h2>\n