From first cluster to EKS — local dev, Gateway API, and controllers
From first cluster to EKS — local dev, Gateway API, and controllers
1. Local cluster → managed control plane
The minikube reading teaches you a cluster you own end to end: you start it, you own the control plane, you tear it down. EKS keeps the same Kubernetes API and splits ownership.
| What the reading shows locally | On EKS | Who owns it |
|---|---|---|
| minikube start brings up API server, etcd, scheduler | EKS managed control plane | AWS (control plane, etcd, upgrades) |
| Single node runs your pods | Managed node groups, self-managed nodes, or Fargate | You choose; AWS runs the node software |
| minikube addons for ingress, metrics, dashboard | EKS add-ons (CoreDNS, kube-proxy, VPC CNI, EBS CSI) | Shared — AWS packages, you enable/version |
| kubectl against local context | Same kubectl, auth via IAM + access entries | You, through aws eks update-kubeconfig |
| You pick the Kubernetes version | EKS offers a supported version window | AWS sets the window; you upgrade within it |
The portable part: every manifest, every
kubectl verb, and the whole object model you learn on minikube run unchanged on EKS. The part that changes: you stop operating the control plane and start operating access to it (IAM, access entries) and the nodes under it.2. Gateway API → EKS
The Gateway API reading is the forward-looking replacement for Ingress: a role-oriented, extensible set of resources (
GatewayClass, Gateway, HTTPRoute, and friends). On EKS the resources are the same; what differs is which implementation backs them.| Gateway API concept | EKS implementation path | Owner |
|---|---|---|
| GatewayClass (who implements the API) | AWS Gateway API Controller (backed by VPC Lattice), or a self-managed implementation (Envoy Gateway, Istio, NGINX Gateway Fabric) | You pick the implementation |
| Gateway / listeners | VPC Lattice service network, or an in-cluster data plane | Shared |
| HTTPRoute traffic rules | Translated to Lattice routing, or to the chosen proxy | You author routes |
| TLS termination | ACM certificates (Lattice/ALB path) or in-cluster certs | Shared |
Staleness callout — Ingress vs Gateway API. The study notes almost certainly lead with Ingress and the AWS Load Balancer Controller (ALB/NLB). That is still fully supported and is the pragmatic default today. Gateway API is the direction of travel, not a forced migration — treat the reading as "learn both, default to what your team already runs." Do not take for granted that VPC Lattice covers every L7 feature a self-managed Envoy/Istio data plane gives you; confirm the specific routing/policy features you need against current AWS docs.
3. Building a controller → operators the AWS way
The "how to create a Kubernetes controller" reading is controller-runtime fundamentals: a reconcile loop, a work queue, watches, and the idea that reconciliation is idempotent and level-triggered. That mental model is exactly what you need on EKS — and AWS has a first-party expression of it.
| Controller-runtime concept from the reading | AWS counterpart | Owner |
|---|---|---|
| Reconcile loop over a Custom Resource | ACK (AWS Controllers for Kubernetes) — CRs that reconcile real AWS resources | AWS ships the controllers; you apply CRs |
| Your own CRD + controller | kubebuilder / controller-runtime, deployed on EKS | You build and run it |
| Controller needs cloud credentials | IRSA or EKS Pod Identity for the controller's ServiceAccount | You wire the identity |
| Owner references + garbage collection | Unchanged on EKS | You |
The through-line: the reconcile-loop discipline the reading teaches is the same discipline ACK controllers use to keep an S3 bucket or an RDS instance matching a manifest. If your team writes operators, kubebuilder/controller-runtime on EKS is the path; if you want AWS resources managed as Kubernetes objects, ACK is the reference implementation to read first.
Questions this page should leave you able to answer
- When I move from minikube to EKS, which Kubernetes skills transfer unchanged, and which operational responsibilities shift to AWS?
- On EKS, do I reach for Ingress + the AWS Load Balancer Controller, or Gateway API — and what decides it?
- If I adopt Gateway API, which
GatewayClassbacks it: VPC Lattice, or a self-managed data plane, and what do I trade either way? - How does a controller running on EKS get AWS credentials — IRSA or EKS Pod Identity?
- When should I build my own controller versus letting ACK reconcile AWS resources for me?
- Which cluster components are AWS's responsibility on EKS, and which stay mine?
Verified, and not
- Grouped by title and path, not by opening every file. This review maps the topics these sources cover (local cluster, Gateway API, controllers, end-to-end notes) onto AWS services. I did not read each PDF page or the full study notes end to end; the per-file detail may go deeper than the mapping above.
- Canonical names only. Service names (EKS, VPC Lattice, ACM, ACK, IRSA, EKS Pod Identity, AWS Load Balancer Controller) are used as AWS and the upstream projects name them. No install commands, no version pins.
- Time-sensitive items flagged inline. Gateway API implementation coverage, VPC Lattice feature parity, EKS add-on and version windows, and the Ingress-vs-Gateway-API default all move — verify against current AWS documentation before acting.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article