Kubernetes networking

Exam tasks: 2.1 (networking)

The decision: for a given traffic path (container to container, Pod to Pod, client to app, app to the internet), which Kubernetes object or plug-in is responsible, and what name or address does the caller use?

The networking modelCopy Anchor Link

Kubernetes sets the rules and leaves the plumbing to plug-ins:

• Every Pod gets its own IP address. Containers in the same Pod share it and reach each other on localhost.
• Every Pod can reach every other Pod on any node without NAT. The cluster network is flat.
• Agents on a node (the kubelet, for example) can reach all Pods on that node.
• Pod IPs are ephemeral. When a Pod is replaced, its IP changes. That's why Services exist.
• Dual-stack (IPv4 and IPv6 at once) is stable and supported if the CNI plugin supports it.

CNI: who builds the Pod networkCopy Anchor Link

The Container Network Interface is a CNCF spec for plug-ins that the container runtime calls when a Pod sandbox is created. The plug-in creates the Pod's network interface, assigns an IP (IPAM) and sets up routes.

• An overlay (VXLAN, Geneve) wraps Pod packets inside node-to-node packets. Easy to set up, small overhead.
• A routed network advertises Pod CIDRs to the underlay (often BGP). No encapsulation, needs network support.
• A cluster has no working Pod network until a CNI plugin is installed. Nodes stay NotReady without one.

Services: stable names for moving PodsCopy Anchor Link

A Service selects Pods by label and gives them one stable virtual IP and DNS name. The control plane tracks the matching Pod IPs in EndpointSlices.

• kube-proxy runs on every node and programs the dataplane that turns a Service IP into a Pod IP. Its modes are iptables (default), nftables (GA since v1.33, recommended on newer kernels) and ipvs.
• eBPF CNIs such as Cilium can replace kube-proxy entirely.

DNS and service discoveryCopy Anchor Link

CoreDNS (CNCF graduated) runs as a Deployment in kube-system and serves names for Services and Pods.

• A Service gets <service>.<namespace>.svc.cluster.local. From the same namespace, the short name works.
• A Pod behind a headless Service in a StatefulSet gets <pod-name>.<service>.<namespace>.svc.cluster.local.
• Named ports get SRV records, so clients can look up port numbers too.
• The kubelet writes each Pod's /etc/resolv.conf to point at the cluster DNS Service, with search domains.
• Kubernetes also injects environment variables for Services that existed when a Pod started. DNS is preferred, because it sees Services created later.
• ExternalDNS (a separate project) publishes Service and Ingress hostnames to public DNS providers.

For example, a quotes Service in namespace bookshelf is quotes.bookshelf.svc.cluster.local, and Pods in bookshelf can call http://quotes.

Getting traffic in: Ingress and Gateway APICopy Anchor Link

Both APIs describe HTTP routing (hostnames, paths, TLS) to Services. Neither does anything without a controller that reads them.

• Gateway API is the recommended direction for new work. It also covers service-to-service traffic through the GAMMA initiative, see Service mesh.

NetworkPoliciesCopy Anchor Link

By default, every Pod accepts traffic from anywhere. A NetworkPolicy changes that for the Pods it selects:

• Policies are namespaced and select Pods by label (podSelector).
• Once any policy selects a Pod for a direction (ingress or egress), that direction becomes deny by default, and only what some policy allows gets through. Policies are additive: there are no "deny" rules.
• Rules allow traffic from or to Pods (podSelector), namespaces (namespaceSelector) or IP ranges (ipBlock), on given ports.
• They work at L3/L4 (IPs, ports). Path- or method-based rules need a CNI extension or a service mesh.
• An egress default-deny also blocks DNS, so you usually allow UDP and TCP port 53 to CoreDNS.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: ledger-from-api-only
  namespace: payments
spec:
  podSelector:
    matchLabels:
      app: ledger
  policyTypes: ["Ingress"]
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: payments-api
      ports:
        - protocol: TCP
          port: 7070

For hands-on depth, see the CKA pages on Services, Gateway API and network policies.

ScenariosCopy Anchor Link

Further readingCopy Anchor Link

• Cluster networking
• Service
• DNS for Services and Pods
• Gateway API