Deployments, Services, and Ingress

Prerequisites: completion of Kubernetes Fundamentals, or equivalent comfort with kubectl apply, Pods, and a local kind cluster.

Version note: verified against kubernetes.io, gateway-api.sigs.k8s.io, and gateway.envoyproxy.io docs, July 2026. IMPORTANT: as of March 24, 2026, the Kubernetes project has fully retired the community ingress-nginx controller — no further releases, bug fixes, or security patches. The Ingress API object itself still exists and is not deprecated, but SIG Network's official guidance is to migrate to the Gateway API. This project teaches Gateway API directly with Envoy Gateway v1.8.2 — a CNCF-adjacent, actively maintained, spec-conformant implementation — rather than teaching a retired controller. Re-check gateway.envoyproxy.io for the current Envoy Gateway release before installing.

A bare Pod that crashes stays dead — nothing brings it back. A Deployment wraps Pods in a controller that continuously reconciles a desired replica count, handles rolling updates, and lets you roll back a bad release with one command. A Service then gives that shifting set of Pods a single, stable network identity, because individual Pod IPs change every time a Pod is replaced.

Getting traffic in from outside the cluster is the last piece, and it's also the piece that changed most recently: the Ingress-NGINX controller, long the default choice for this job, was officially retired in March 2026 after years running on one or two volunteer maintainers. The Ingress API still works, but new investment is going into the Gateway API instead — a more expressive, role-oriented API that splits "where traffic enters" (Gateway) from "how it's routed" (HTTPRoute). This project builds all three layers using currently-maintained tooling.