Services & Networking

Domain 3 of the CKA blueprint is where Kubernetes stops being a scheduler for isolated containers and becomes a network of things that can actually find and reach each other. Weighted at 20% — the second-largest domain after Troubleshooting — it asks you to demonstrate Pod-to-Pod connectivity across nodes with no NAT in the way, write and reason about NetworkPolicy rules that flip a Pod from open to deny-by-default, choose correctly among ClusterIP, NodePort, and LoadBalancer Service types, route external traffic in with both the older Ingress resource and the newer Gateway API, and read how CoreDNS turns a Service name into a routable IP. None of it is abstract on exam day: you get a live cluster with something broken in exactly one of these places, and there's no partial credit for guessing which. This page goes section by section, with real manifests and the traps that catch people who understand the theory but haven't typed the YAML enough times.

Domain 3 of 5: where this page sits in the blueprint

☺ Like you're 10: Five topics make up the whole exam, and they're not equal — this one is a fifth of the total score, and it's the one about things actually talking to each other.

A quick honesty note before anything else: the "D1–D5" numbering used across this blueprint section is this course's own organizing label for its five pages, in the order the official curriculum happens to list them — it is not a number the CNCF itself prints anywhere. What is official is the weight next to each one, taken from the CNCF's Certified Kubernetes Administrator (CKA) Exam Curriculum, and confirmed against the current version on this course's own certifications hub before you rely on it.

One naming quirk worth flagging up front: the v1.35 curriculum PDF prints this domain's official name as "Servicing and Networking" — a lot of older study material, and this page's own title, write it as "Services and Networking." Same domain, same six competencies below; don't let the word order trip you up if you see it phrased either way.

Six bullets here, out of 27 published competencies across all five domains (8 + 5 + 6 + 5 + 3). The exam itself is performance-based — two hours on live clusters in a browser terminal, graded entirely on the end state you leave behind, not on the commands you typed to get there.

Pod-to-Pod connectivity: the flat network model

☺ Like you're 10: Every Pod gets its own phone number, and any Pod can dial any other Pod's number directly — no front desk has to patch the call through.

Kubernetes networking rests on a small set of guarantees every conformant cluster must provide, regardless of which plugin implements them:

• Every Pod gets its own IP address. Containers inside one Pod share that IP and a network namespace; they talk to each other over localhost.
• All Pods can reach all other Pods without NAT, whether they're on the same node or different nodes.
• All Nodes can reach all Pods without NAT, which is what lets the kubelet run liveness and readiness probes directly against a Pod's IP.
• The IP a Pod sees itself as is the same IP everyone else sees it as. No address translation happens in the middle of a Pod-to-Pod connection, so the source IP arriving at the far end is genuinely the sender's Pod IP.

That's the whole model — usually called the "IP-per-Pod, flat network" requirement. Kubernetes itself doesn't implement it; a CNI (Container Network Interface) plugin does, using one of three broad strategies: an overlay network that encapsulates Pod traffic inside VXLAN or Geneve packets between nodes (classic Flannel), native routing that programs each node's kernel routing table or speaks BGP so Pod-CIDR ranges are directly routable (Calico's default mode), or an eBPF datapath that skips iptables entirely and processes packets in the kernel (Cilium). The exam curriculum only asks you to understand that this interface exists — the CNI itself gets its own competency bullet under Domain 1 — but every symptom you'll troubleshoot in this domain assumes you know what "no NAT" is supposed to look like when it's working.

kubectl get pods -n shop -o wide
# NAME           READY   STATUS    IP            NODE
# web-7f9d8      1/1     Running   10.244.1.5    node-a
# web-8c2e1      1/1     Running   10.244.1.9    node-a
# api-5f7a2      1/1     Running   10.244.2.14   node-b

kubectl exec -n shop web-7f9d8 -- ping -c 2 10.244.2.14
kubectl exec -n shop web-7f9d8 -- curl -s -o /dev/null -w '%{http_code}\n' http://10.244.2.14:8080/healthz

NetworkPolicy: allow-all until one policy says otherwise

☺ Like you're 10: With no rules on the door, every room can call in. The moment even one card gets slipped under a specific door, that door only answers the calls the card allows — every other door stays exactly as open as before.

Out of the box, with zero NetworkPolicy objects in a namespace, the flat network from the section above means every Pod can reach every other Pod — allow-all is the default. A NetworkPolicy doesn't get layered on top of that as an extra filter you have to author from scratch for every Pod; instead, it flips a switch, one Pod (or group of Pods) and one direction at a time. The rule that trips people up every single sitting: the moment any NetworkPolicy's podSelector matches a Pod for a given policyTypes entry, that Pod becomes deny-by-default in that direction — only the traffic explicitly allowed by policies selecting it gets through. Pods that no policy selects are completely unaffected and stay wide open. And when two or more policies do select the same Pod, their rules are additive — the union of everything any of them allows — never a stricter intersection.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: shop
spec:
  podSelector: {}            # empty selector = every Pod in this namespace
  policyTypes:
    - Ingress
    - Egress
                              # no ingress/egress blocks at all = nothing is allowed

That five-line manifest is the standard default-deny baseline — apply it first in a namespace, confirm everything breaks, then add back exactly the paths you mean to allow. Here's the follow-up policy that reopens traffic for one real service, including the DNS egress most people forget:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: api-allow-scoped
  namespace: shop
spec:
  podSelector:
    matchLabels:
      app: api
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - from:
        - podSelector:
            matchLabels: { app: web }   # only web Pods may call api
      ports:
        - protocol: TCP
          port: 8080
  egress:
    - to:                               # api may call the payments Pods on 443
        - podSelector:
            matchLabels: { app: payments }
      ports:
        - protocol: TCP
          port: 443
    - to:                               # and must be able to reach CoreDNS, or
        - namespaceSelector:
            matchLabels: { kubernetes.io/metadata.name: kube-system }
          podSelector:
            matchLabels: { k8s-app: kube-dns }
      ports:
        - { protocol: UDP, port: 53 }
        - { protocol: TCP, port: 53 }   # TCP fallback for answers too large for UDP

Service types: ClusterIP, NodePort, LoadBalancer

☺ Like you're 10: Pods get replaced constantly and their IPs change every time — a Service is the one phone number that never changes, no matter which Pod actually answers.

A Service is a stable virtual IP and DNS name in front of a changing set of Pods, selected by label. Membership is tracked in EndpointSlice objects (the scalable successor to the older singular Endpoints object), which kube-proxy on every node watches and turns into local packet-forwarding rules — iptables, IPVS, or an eBPF datapath if the CNI supplies one — that DNAT traffic bound for the Service's virtual IP out to one of the live Pod IPs in its EndpointSlices. There are three Service types the curriculum names explicitly, and each is a strict superset of the one before it:

apiVersion: v1
kind: Service
metadata:
  name: checkout
  namespace: shop
spec:
  type: ClusterIP          # or omit `type` entirely — this is the default
  selector:
    app: checkout
  ports:
    - port: 80
      targetPort: 8080

kubectl get svc checkout -n shop
kubectl get endpointslices -n shop -l kubernetes.io/service-name=checkout -o wide

apiVersion: v1
kind: Service
metadata:
  name: checkout-external
  namespace: shop
spec:
  type: LoadBalancer        # superset of NodePort, which is a superset of ClusterIP
  selector:
    app: checkout
  ports:
    - port: 443
      targetPort: 8080
      nodePort: 31743        # optional — auto-assigned from 30000-32767 if omitted

kubectl get svc checkout-external -n shop -w
NAME                TYPE           CLUSTER-IP     EXTERNAL-IP   PORT(S)
checkout-external   LoadBalancer   10.96.14.201   <pending>     443:31743/TCP
checkout-external   LoadBalancer   10.96.14.201   203.0.113.44  443:31743/TCP

One naming detail worth locking in for exam speed: a headless Service (spec.clusterIP: None) skips virtual-IP load balancing entirely and instead makes CoreDNS return the individual Pod IPs directly — the mechanism StatefulSets rely on for stable per-Pod DNS names, covered in the CoreDNS section below.

Ingress vs. the Gateway API

☺ Like you're 10: Both are ways to let the outside world in through one front door and get routed to the right room by web address — one is the older concierge who only speaks in sticky-notes, the other is a newer one with an actual rulebook.

Services (even LoadBalancer ones) operate at L4 — IPs and ports, no awareness of HTTP hostnames or paths. Routing shop.example.com/checkout and shop.example.com/catalog to two different backend Services through one shared IP needs an L7-aware object, and the curriculum names two of them.

Ingress: the established resource

An Ingress object (networking.k8s.io/v1) declares host- and path-based routing rules, but it does nothing on its own — it needs an Ingress controller (ingress-nginx, Traefik, HAProxy, a cloud provider's own) actually running in the cluster to watch Ingress objects and program a real reverse proxy from them. The object's core fields are portable across controllers; anything beyond basic host/path routing — rewrite rules, rate limiting, canary weighting — gets bolted on through annotations, and annotation keys are controller-specific and non-portable. Move from ingress-nginx to a different controller and every annotation-driven behavior has to be re-translated by hand.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: shop-ingress
  namespace: shop
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  ingressClassName: nginx
  rules:
    - host: shop.example.com
      http:
        paths:
          - path: /checkout
            pathType: Prefix
            backend:
              service: { name: checkout, port: { number: 80 } }
          - path: /catalog
            pathType: Prefix
            backend:
              service: { name: catalog, port: { number: 80 } }

Gateway API: the newer, role-oriented family

The Gateway API is a separate resource family, developed as its own subproject with an independent release cadence from Kubernetes core — its v1.0 release, which took GatewayClass, Gateway, and HTTPRoute to General Availability, shipped in October 2023. It splits the single Ingress object into three, deliberately assigning each to a different owner: a GatewayClass (cluster-scoped, provided by whoever installed the implementation — Cilium, Envoy Gateway, and others all ship one) names an implementation; a Gateway (owned by cluster/infra operators) binds to a class and declares listeners — ports, protocols, hostnames, TLS; and one or more Route resources — HTTPRoute, and also TCPRoute, GRPCRoute, TLSRoute for protocols Ingress never addressed at all — attach to a Gateway and are owned by the application teams that actually need the routing rules. That split is the headline improvement over Ingress: infra and app teams stop needing write access to the same object, and traffic splitting, header-based matching, and weighted backends are typed schema fields instead of controller-specific annotation strings.

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: shop-gateway
  namespace: infra
spec:
  gatewayClassName: cilium
  listeners:
    - name: https
      protocol: HTTPS
      port: 443
      hostname: "*.example.com"
      tls:
        certificateRefs:
          - name: shop-tls-cert
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: checkout-route
  namespace: shop
spec:
  parentRefs:
    - { name: shop-gateway, namespace: infra }
  hostnames: [ "shop.example.com" ]
  rules:
    - matches:
        - path: { type: PathPrefix, value: /checkout }
      backendRefs:
        - { name: checkout, port: 80, weight: 90 }
        - { name: checkout-canary, port: 80, weight: 10 }   # native traffic
                                                              # splitting — no
                                                              # annotation needed

The curriculum lists both bullets, so treat this as "know both, on a live cluster," not "the new one replaced the old one." For the deeper mechanics of Gateway API implementations and the CNI overlap, see Platform Engineering's Cilium tool page and its Networking & Connectivity deep dive — this course's own ingress-nginx and cert-manager tool guides cover the TLS half of the Ingress example above.

CoreDNS: how a Service gets a name

☺ Like you're 10: Every Service already has a phone number (its ClusterIP) — CoreDNS is just the phone book that turns the name you actually remember into that number.

CoreDNS runs as a Deployment in kube-system, fronted by a Service still historically named kube-dns for backward compatibility — that Service's ClusterIP is what every kubelet writes into a Pod's /etc/resolv.conf as its nameserver, via the default dnsPolicy: ClusterFirst. Every Service automatically gets an A/AAAA record at <service>.<namespace>.svc.cluster.local, resolving to its ClusterIP; a headless Service (clusterIP: None) instead returns the individual Pod IPs directly at that same name, and a StatefulSet's per-Pod hostname resolves at <pod-name>.<service>.<namespace>.svc.cluster.local — the exact mechanism that gives each StatefulSet replica a stable, individually addressable identity.

kubectl exec -n shop web-7f9d8 -- nslookup checkout.shop.svc.cluster.local
kubectl exec -n shop web-7f9d8 -- cat /etc/resolv.conf

Server:    10.96.0.10
Address:   10.96.0.10:53
Name:      checkout.shop.svc.cluster.local
Address:   10.96.22.108

nameserver 10.96.0.10
search shop.svc.cluster.local svc.cluster.local cluster.local
options ndots:5

Read that resolv.conf closely — it's a common exam and production trap. With ndots:5, any name containing fewer than five dots gets every entry in search appended and tried, in order, before the bare name is ever attempted. A short internal name like checkout (0 dots) benefits from this — it resolves in one hop as checkout.shop.svc.cluster.local. But an external name like api.stripe.com (2 dots) also falls under that threshold: the Pod tries api.stripe.com.shop.svc.cluster.local, then api.stripe.com.svc.cluster.local, then api.stripe.com.cluster.local — three lookups that can only fail — before finally trying api.stripe.com itself. That's real added latency on every external call, worse under any packet loss, and it's the classic explanation for "external API calls are randomly slow" tickets that have nothing wrong with the external API at all.

Common exam traps in this domain

☺ Like you're 10: These are the specific ways people who understand every idea above still lose points on the actual task.

• An Egress NetworkPolicy with no port-53 rule to CoreDNS. Covered above at length because it's the single most common self-inflicted outage in this domain — the symptom is total application failure that looks nothing like a networking problem.
• Assuming a NetworkPolicy is enforced just because the API accepted it. Confirm the CNI actually implements the NetworkPolicy API before trusting a policy did anything at all.
• Chasing a LoadBalancer Service stuck at <pending> as a bug. On a cluster with no cloud-controller-manager or MetalLB, that's the correct, permanent state — use NodePort or port-forward instead of waiting for an external IP that will never arrive.
• A Service selector that doesn't match its own Pods' labels. The Service object still exists and still resolves in DNS — it just has an empty EndpointSlice, and every connection to it times out with no obvious error. kubectl get endpointslices -l kubernetes.io/service-name=<svc> is the fastest way to confirm.
• Treating Ingress annotations and Gateway API fields as interchangeable. They solve the same problem in different, non-portable ways — know which resource family a given task is actually asking for.
• Forgetting ndots:5 when a Pod is slow to reach something external. Not every latency ticket is a networking bug in the usual sense — sometimes it's four wasted DNS lookups before the fifth one succeeds.

Domain 2 covers what runs before traffic ever needs to find it — see Workloads & Scheduling — and Domain 4 covers what those workloads keep on disk, in Storage. For the mechanics behind everything on this page taken further — CNI internals, service mesh sidecars, multi-cluster networking — see this course's own Networking & the CNI deep dive, and for the RBAC and admission-control half of "who's allowed to touch what," see RBAC & Admission Control. NetworkPolicy's security framing is covered from the defense-in-depth angle in this course's own Security: Defense in Depth and, cross-course, in DevSecOps's Kubernetes security deep dive. CKA sits at the base of the CNCF's wider Kubestronaut ladder alongside CKAD and CKS; the other certifications on that ladder — including Cilium's own CCA — are covered on the sibling Golden Astronaut course. When you're ready to drill this domain specifically, continue to the CKA study plan and CKA practice tasks.