Kubernetes Networking Services and Ingress for Exams

Mastering Kubernetes networking is non-negotiable for both certification success and real-world cluster management. This domain tests your practical understanding of how pods communicate, how applications are exposed, and how traffic flow is secured and controlled. For exams, you must move beyond memorization to applied reasoning, configuring resources that solve specific connectivity and access problems.

The Kubernetes Networking Model and CNI Foundation

All Kubernetes networking builds upon a fundamental model defined by a simple rule: every Pod gets its own unique IP address, and all pods can communicate with all other pods without Network Address Translation (NAT). This flat network model eliminates the complexity of mapping container ports to host ports for pod-to-pod traffic. The IP address is assigned at the Pod level, meaning containers within a pod share the same network namespace and can reach each other via localhost.

This model is enforced by the Container Network Interface (CNI), a plugin-based framework. The CNI plugin is responsible for the actual network plumbing: assigning the IP address to the pod's virtual interface, ensuring it is routable within the cluster, and cleaning up resources when the pod is deleted. Common CNI plugins include Calico, Cilium, and Flannel. For exams, you don't need to know plugin-specific commands, but you must understand that the CNI is a core component enabling the Kubernetes networking model. A cluster cannot function without a CNI plugin configured.

Pod-to-pod communication is thus direct. If Pod A (10.244.1.2) needs to talk to Pod B (10.244.2.5), it simply sends a packet to that IP. The CNI plugin and the underlying node networking (often using overlay networks or routing rules) ensure the packet is delivered. This direct communication is efficient but ephemeral—pods are created and destroyed dynamically, and their IPs change. This volatility is the primary problem that Services solve.

Services: Stable Endpoints for Dynamic Pods

A Kubernetes Service is an abstraction that defines a logical set of Pods (selected via labels) and a policy to access them. It provides a stable ClusterIP (a virtual IP) and DNS name that persists even as the backing pods are rescheduled. This decouples frontend clients from the ephemeral nature of pod IPs.

You must master the four core Service types and their exam-relevant use cases:

1. ClusterIP: The default type. Exposes the Service on an internal IP, making it reachable only from within the cluster. Use this for inter-microservice communication (e.g., a frontend pod talking to a backend API service).
2. NodePort: Exposes the Service on a static port (the NodePort, in the 30000-32767 range) on each node's IP. Traffic to *<NodeIP>:<NodePort>* is routed to the Service's ClusterIP and then to a pod. This allows external access but is rarely used directly in production due to port management complexity and security. It's often a building block for higher-level abstractions.
3. LoadBalancer: Typically used in cloud environments (AWS, GCP, Azure). It provisions an external cloud load balancer that points to the NodePort and ClusterIP. This is the standard way to expose a Service directly to the internet. The cloud controller manager handles the integration.
4. Headless: Created by setting clusterIP: None in the Service spec. This service does not load-balance or provide a stable ClusterIP. Instead, DNS returns all the pod IPs directly. This is crucial for stateful applications where clients, like databases, need to discover all individual pod endpoints (e.g., a MongoDB replica set).

A Service's selector continuously evaluates which pods are matching its label criteria. The kube-proxy component, running on each node, then programs network rules (using iptables or IPVS) to forward traffic destined for the Service's ClusterIP or NodePort to one of the healthy backend pods. For exam scenarios, be prepared to write a Service YAML manifest to expose a given deployment, selecting the correct type based on access requirements.

Ingress: Intelligent HTTP(S) Routing

While a LoadBalancer Service gives you a direct external endpoint, it's inefficient and costly to use one for every application. Ingress manages external HTTP/HTTPS access to services within the cluster, providing host-based or path-based routing, SSL/TLS termination, and name-based virtual hosting—all through a single point of entry.

It's critical to distinguish two components:

1. Ingress Resource: A Kubernetes API object that defines the routing rules. It is a set of declarative rules (e.g., send traffic for myapp.com/api to the api-service on port 80).
2. Ingress Controller: The actual process that fulfills the Ingress rules. It is a reverse proxy daemon (like Nginx, Traefik, or HAProxy) running in pods, watching for Ingress resource changes. You must deploy an Ingress Controller; it does not come with Kubernetes by default.

A typical Ingress manifest specifies a host, paths, and a backend serviceName and servicePort. The Ingress Controller, once deployed with a LoadBalancer or NodePort Service of its own, reads these rules and configures its internal proxy. For exams, practice writing Ingress YAML that routes multiple paths to different backend services. Understand key annotations (like nginx.ingress.kubernetes.io/rewrite-target) as they are controller-specific extensions to the standard Ingress spec.

Network Policies and CoreDNS for Granular Control

With basic connectivity established, you need to control it. Network Policies are firewall rules for pods. By default, all pods are non-isolated (allow all traffic). A NetworkPolicy, defined by a pod selector and rules, restricts traffic. Rules specify allowed ingress (incoming) and egress (outgoing) traffic based on source/destination pod selectors, namespaces, or IP blocks.

For example, a policy can dictate that only pods with the label role: frontend can talk to pods labeled role: backend on port 6379. Enforcement of these policies requires a CNI plugin that supports the NetworkPolicy API, like Calico or Cilium. Exam questions often test your ability to write a NetworkPolicy YAML to implement a specific security requirement, such as isolating a namespace or restricting pod egress.

Internal discovery is handled by DNS. Kubernetes has a built-in DNS service (CoreDNS is the modern default) that provides naming for Services and Pods. A Service gets a DNS entry of the form *<service-name>.<namespace-name>.svc.cluster.local*. A pod's DNS name is less commonly used but follows a stable pattern. Understanding DNS resolution is key for troubleshooting. For instance, a pod in the default namespace can reach a Service named db in the prod namespace via the hostname db.prod.svc.cluster.local.

Troubleshooting Connectivity: A Systematic Approach

Exam scenarios will test your ability to diagnose failures. Follow a logical, layered approach:

1. Start with the Pod: Is the pod Running and Ready (kubectl get pods -o wide)? Are the application ports correctly defined in the container spec? Use kubectl logs and kubectl describe pod for clues.
2. Check the Service: Does the Service's label selector match the labels on the target pods? Check with kubectl describe service <name>. The Endpoints section should list the IPs of the matched pods. If it's empty, the selector is wrong.
3. Verify DNS: Can you resolve the Service's DNS name from inside a pod? Use kubectl exec -it <pod> -- nslookup <service-name>.
4. Inspect NetworkPolicy: Are there any NetworkPolicies that might be blocking the traffic? A deny-all policy in the namespace would block all unintended allows.
5. Examine Ingress: For external access issues, ensure the Ingress Controller pods are running. Check the Ingress resource status (kubectl describe ingress). Verify the rules point to the correct service and port. Remember, the Ingress Controller itself needs a way to be reached (e.g., a LoadBalancer Service).

Common Pitfalls

• Confusing Service Types: Using a ClusterIP Service when external access is needed, or deploying a LoadBalancer for every internal service, incurring unnecessary cost. Remember the hierarchy: Internal -> ClusterIP, External Direct -> LoadBalancer, External Smart HTTP -> Ingress.
• Misconfiguring Selectors: The most common cause of a "Service has no endpoints" error. The labels in the Service's selector field must exactly match the labels on the target Pods.
• Assuming Ingress Works Out-of-the-Box: Forgetting that an Ingress Controller must be deployed separately from the Ingress Resource definition. The rules are useless without a controller to implement them.
• Overlooking NetworkPolicy Defaults: Assuming pods are isolated by default. Without a NetworkPolicy, all pods can talk to each other. A policy must be explicitly defined to restrict traffic.

Summary

• Kubernetes uses a flat pod network model where each pod gets a unique IP, enabled by a CNI plugin.
• Services provide stable networking and discovery for dynamic pods, with types (ClusterIP, NodePort, LoadBalancer, Headless) defining their scope of access.
• Ingress manages external HTTP/S routing via declarative rules (the Ingress Resource) implemented by a reverse proxy (the Ingress Controller).
• Network Policies act as pod-level firewalls to segment network traffic, crucial for security but not enabled by all CNI plugins.
• CoreDNS provides internal service discovery via DNS, using the naming pattern *<service>.<namespace>.svc.cluster.local*.
• Troubleshoot connectivity methodically: Pod -> Service -> DNS -> NetworkPolicy -> Ingress.