Capstone Part 3 — Networking & Ingress

This is the third of five parts building one continuous project: a real storefront running on Kubernetes, deployed the hard way so every mechanism is something you typed and watched work, not something a course video skipped past. Part 1 gave the cluster its shape — nodes, namespaces, and the storefront namespace this whole capstone lives in. Part 2 gave it something to run — the web and api Deployments, each with its own ConfigMap and Secret, each already passing its own liveness and readiness probes. Both have been reachable only from inside the cluster this whole time, one kubectl port-forward away from anyone who wanted to look. Today that changes, deliberately and in layers. This page gives the app stable Service identities, a public hostname with a browser-trusted TLS certificate that renews itself, and — the part most tutorials skip — a NetworkPolicy posture that starts from deny-everything and opens exactly four narrow, named holes. By the end, shop.example.com answers over HTTPS, and nothing in the cluster can reach api except web, on purpose.

What this part assumes, and what it produces

☺ Like you're 10: The building, the units, and the tenants already exist — today is only about the front door, the mailboxes, and the locks.

This part assumes Part 2's web and api Deployments already exist and are healthy in the storefront namespace — kubectl get pods -n storefront should show every Pod Running with READY 1/1 before you touch anything below. You'll also need ingress-nginx and cert-manager installed as cluster add-ons — both are single Helm installs, covered in full on their own tool pages, and neither is specific to this capstone. Nothing here touches the Deployments, ConfigMaps, or Secrets Part 2 built; every object on this page is new, additive, and namespaced to storefront or cluster-scoped in a way that doesn't collide with anything that already exists. For the concepts underneath everything below — the flat, no-NAT Pod network, why NetworkPolicy is deny-by-selection rather than deny-by-default globally, and the exact Service/Ingress manifests this page builds on — see Services & Networking, the CKA blueprint domain this whole page is really a hands-on rep of.

The world model this part adds

Services: giving web and api a name that outlives any one Pod

☺ Like you're 10: Pods get replaced constantly and their addresses change every time — a Service is the one buzzer number that never changes, no matter which actual tenant answers it today.

Neither Deployment has a stable network identity yet — a Pod's IP is assigned when it starts and gone the moment it's rescheduled, which happens routinely. A Service fixes that with one virtual IP and DNS name in front of a changing set of Pods, selected purely by label; membership is tracked automatically in EndpointSlice objects that kube-proxy on every node watches and turns into real packet-forwarding rules, exactly as the API-and-controllers model and Networking & the CNI cover in depth. Both Services here are plain ClusterIP — internal-only is correct today, since nothing outside the cluster should ever reach either one directly; that's the Ingress's job, next section.

apiVersion: v1
kind: Service
metadata:
  name: web
  namespace: storefront
spec:
  selector: { app: web }
  ports:
    - port: 80
      targetPort: 8080

---
apiVersion: v1
kind: Service
metadata:
  name: api
  namespace: storefront
spec:
  selector: { app: api }
  ports:
    - port: 8080
      targetPort: 8080

Apply both, then confirm each has real endpoints — not just a ClusterIP — before moving on: kubectl get endpointslices -n storefront -l kubernetes.io/service-name=web should list the actual Pod IPs behind it. A Service with a valid ClusterIP but zero endpoints is the single most common silent failure in this domain: the object exists, DNS resolves it, and every connection to it just times out, because its selector doesn't actually match any Pod's labels.

The public entrypoint: Ingress, and a certificate that renews itself

☺ Like you're 10: The Ingress is the front door with a real lock; cert-manager is the helper who quietly swaps in a fresh ID card for that door every month, weeks before the old one expires, without anyone asking.

With both Services in place, one ClusterIssuer gives the whole cluster a single, shared way to get browser-trusted certificates from Let's Encrypt — create it once, and every namespace can reference it by name, exactly as cert-manager covers in full:

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: platform-team@acme.io
    privateKeySecretRef:
      name: letsencrypt-prod-account-key
    solvers:
      - http01:
          ingress:
            ingressClassName: nginx

Next, an explicit Certificate — written out in Git next to the Ingress that consumes its Secret, rather than left to the cert-manager.io/cluster-issuer ingress-shim annotation to create implicitly. Both routes end at the same object; writing it explicitly is what cert-manager's own checkpoint calls out as the better default for anything running in production, because the relationship between hostname, issuer, and Secret stays visible and reviewable in a pull request instead of hiding inside an annotation:

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: shop-tls
  namespace: storefront
spec:
  secretName: shop-tls
  duration: 2160h        # 90d — ignored by Let's Encrypt, requested anyway
  renewBefore: 720h       # renew 30d before expiry
  dnsNames:
    - shop.example.com
  issuerRef:
    name: letsencrypt-prod
    kind: ClusterIssuer

Finally, the Ingress itself — one object naming both routes and the certificate that protects them:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: storefront
  namespace: storefront
  annotations:
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
spec:
  ingressClassName: nginx
  tls:
    - hosts: [shop.example.com]
      secretName: shop-tls
  rules:
    - host: shop.example.com
      http:
        paths:
          - path: /api
            pathType: Prefix
            backend:
              service: { name: api, port: { number: 8080 } }
          - path: /
            pathType: Prefix
            backend:
              service: { name: web, port: { number: 80 } }

Apply all three in order — ClusterIssuer, then Certificate, then Ingress — and watch kubectl get certificate -n storefront shop-tls -w until READY flips to True. Behind that flip is the full ACME dance: a CertificateRequest, an Order, and an HTTP-01 Challenge that cert-manager solves through the Ingress it's already watching — the complete chain, and why evaluation can take a minute or two, is diagrammed on the cert-manager page itself; this page only needs the last mile.

Default-deny first, then four narrow allows

☺ Like you're 10: The building manager changes every lock to open for nobody, then hands out exactly the keys that make sense — front door to lobby, lobby to 4B, nothing else, no exceptions, until someone deliberately cuts a new key.

Right now, with zero NetworkPolicy objects in storefront, the flat Pod network means every Pod in the cluster can already reach both web and api directly — a Pod in an unrelated namespace, a compromised sidecar three teams over, anything. That's the default Kubernetes ships with, and it's the opposite of what a public-facing app with a real backend should allow. The fix isn't one policy — it's five, applied in a specific order of reasoning even though Kubernetes evaluates them all at once: first, deny everything for every Pod in the namespace; then, name exactly what's still allowed to happen, one narrow rule at a time.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: storefront
spec:
  podSelector: {}
  policyTypes: [Ingress, Egress]

An empty podSelector: {} matches every Pod in the namespace; naming both Ingress and Egress in policyTypes with no ingress or egress rules underneath means every Pod here now accepts nothing in and sends nothing out — including, easy to forget, DNS lookups. Apply this alone and both web and api go instantly, completely dark. That's expected, and it's exactly why the four policies below exist.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-ingress-to-web
  namespace: storefront
spec:
  podSelector: { matchLabels: { app: web } }
  policyTypes: [Ingress]
  ingress:
    - from:
        - namespaceSelector:
            matchLabels: { kubernetes.io/metadata.name: ingress-nginx }
          podSelector:
            matchLabels: { app.kubernetes.io/name: ingress-nginx }
      ports:
        - { port: 8080, protocol: TCP }

---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-web-to-api
  namespace: storefront
spec:
  podSelector: { matchLabels: { app: api } }
  policyTypes: [Ingress]
  ingress:
    - from:
        - podSelector: { matchLabels: { app: web } }
      ports:
        - { port: 8080, protocol: TCP }

---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-dns-egress
  namespace: storefront
spec:
  podSelector: {}
  policyTypes: [Egress]
  egress:
    - to:
        - namespaceSelector:
            matchLabels: { kubernetes.io/metadata.name: kube-system }
          podSelector:
            matchLabels: { k8s-app: kube-dns }
      ports:
        - { port: 53, protocol: UDP }
        - { port: 53, protocol: TCP }

---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-api-egress-payments
  namespace: storefront
spec:
  podSelector: { matchLabels: { app: api } }
  policyTypes: [Egress]
  egress:
    - to:
        - ipBlock: { cidr: 203.0.113.0/24 }   # payments provider's published range
      ports:
        - { port: 443, protocol: TCP }

Read allow-ingress-to-web's single from entry carefully — namespaceSelector and podSelector sit inside the same list item, which means they combine with AND: only Pods matching both selectors at once. Split them into two separate entries in the from array instead and the meaning changes completely, to OR — any Pod in the ingress-nginx namespace regardless of its own labels, or any Pod anywhere carrying that controller's label. The single-entry, AND'd form here is deliberately the narrower one: only the actual ingress-nginx controller Pod, in its own namespace, gets in.

Proving it: what should work, and what absolutely should not

☺ Like you're 10: Ring the buzzer from outside — it should work. Try walking straight into 4B from the hallway without buzzing anyone — it shouldn't, and now it can't.

Apply everything above in order — Services, then the ClusterIssuer/Certificate/Ingress, then all five NetworkPolicies — and prove both halves independently. First, the app is genuinely reachable:

curl -sv https://shop.example.com/ 2>&1 | grep -E "HTTP/|subject:|issuer:"
# HTTP/2 200
# subject: CN=shop.example.com
# issuer: C=US, O=Let's Encrypt, CN=R3
# -- a REAL issuer, not cert-manager's self-signed fallback cert

curl -s https://shop.example.com/api/healthz
# {"status":"ok"} -- routed through web's Ingress rule to the api Service, over the policy chain

Then prove the negative — the part a passing curl above can't show on its own. From a throwaway Pod with no matching label, in a completely different namespace:

kubectl run stray --rm -it --restart=Never --image=curlimages/curl -n default -- \
  curl -m 3 http://api.storefront.svc.cluster.local:8080/healthz
# curl: (28) Connection timed out after 3001 milliseconds
# -- default-deny-all blocks it; allow-web-to-api only names Pods labeled app: web, and this isn't one

kubectl run stray --rm -it --restart=Never --image=curlimages/curl -n storefront -- \
  curl -m 3 http://web.storefront.svc.cluster.local:80/
# curl: (28) Connection timed out after 3001 milliseconds
# -- same namespace isn't enough either: allow-ingress-to-web only names the ingress-nginx
# controller as a source, and this Pod carries neither its namespace nor its label

Both timeouts are the point, not a bug to chase. The first curl succeeding and both of these failing, together, is what "default-deny with targeted allows" actually means in practice — reachable exactly where it should be, and nowhere else, proven from the outside rather than assumed from reading YAML.

Milestones

☺ Like you're 10: Tick each box only once you've actually watched it happen on your own screen, not because the step "sounds right."

Work these in order — each depends on the state left by the one before. Progress saves in this browser.

Part 3 gave the storefront a real front door, a certificate that renews itself, and a network posture that denies everything until you've said otherwise. Continue to Capstone Part 4 — Storage & Stateful Apps, where api gets somewhere durable to keep its data behind everything built here. Or step back to Build a Cluster — Start Here for how all five parts fit together, revisit Services & Networking and Networking & the CNI for the concepts behind what you just built, cross-check the security framing against Security: Defense in Depth and, cross-course, DevSecOps's Kubernetes security deep dive, or drill this exact failure mode under timed conditions in Drill — Diagnose a Networking Failure.