GuideIntermediate
Kubernetes And Eks In Production
Gives Andes Cargo the orchestrator it was missing: `andes-cargo-status-api`, the containerized component that the Serverless and Containers guide built but left "documented, never executed" on ECS, finally runs for real against a genuine Kubernetes cluster. This guide uses `kind` — real Kubernetes, not a simulator — as its $0 lab, with the strongest executable backbone in the ecosystem so far: nearly everything runs with no paid-plan limit whatsoever. It builds the workload primitives (Pod, Deployment, Service) up to production level with externalized configuration, `liveness`/`readiness`/`startup` probes, and horizontal autoscaling driven by real metrics; the cluster's networking model with `Ingress` and `NetworkPolicy`; real pull-based GitOps with ArgoCD over its own Git repository (Gitea, running inside the same cluster) that converges the system's state without anyone running a manual `kubectl apply`; real admission control with two engines (OPA Gatekeeper and Kyverno) that reject an object before it ever comes into existence; and container image scanning with Trivy. It closes with a module specific to EKS — managed node groups, Fargate profiles, IRSA/EKS Pod Identity, node autoscaling with Karpenter, the AWS Load Balancer Controller — shown and explained in depth but declared representative with exact honesty: EKS is only available on LocalStack's Ultimate plan, and even paying for it doesn't faithfully reproduce the real managed control plane. The capstone runs the full system end to end, with one change that passes the gate and one that the admission webhook stops.
- 64
- lessons
- 8
- modules
- English · Spanish
- available in
- Yes
- certificate
- Free
- access
Outcomes
What you'll be able to do
- Decide when Kubernetes beats ECS/Fargate and what that gain costs (more moving pieces to manage — it isn't batteries-included)
- Stand up a real Kubernetes cluster with `kind`, and get `andes-cargo-status-api` (inherited, without rewriting the Dockerfile) running inside it
- Master the workload primitives — Pod, Deployment, Service — and why you almost never create a standalone Pod
- Externalize configuration with ConfigMap and Secret, configure `liveness`/`readiness`/`startup` probes, and scale horizontally with a `HorizontalPodAutoscaler` that reacts to real metrics
- Expose the service with `Ingress` (`ingress-nginx`) and protect it with a real deny-by-default `NetworkPolicy`
- Build end-to-end pull-based GitOps with ArgoCD over a real Git repository (Gitea): a committed change converges on the cluster on its own, with no manual `kubectl apply`
- Implement real admission control with two policy engines (OPA Gatekeeper and Kyverno) and scan the container image with `trivy image`, rejecting an object before it ever exists
- Understand what changes when the cluster is real EKS: who runs the control plane, node groups versus Fargate profiles, IRSA and its successor EKS Pod Identity, node autoscaling with Karpenter, and the AWS Load Balancer Controller
Before you start
What you need to bring
It's for you if...
- Backend, DevOps, or Cloud engineers who completed the AWS Core Services and Serverless and Containers guides and need the container orchestrator that dominates real production
- Devs who built a Docker image and ran it locally but never deployed it with a real orchestrator
- Engineers preparing for roles where Kubernetes/EKS is an explicit requirement (market evidence shows it in the large majority of cloud postings)
- Teams that already have push-based GitOps (a CI pipeline running `apply`) and want to understand the other pole of the same principle: a pull-based operator that converges the cluster on its own
Requirements and materials
- AWS Core Services and Serverless and Containers on AWS guides completed (or equivalent: single-account IAM, the `Shipments` table, and `andes-cargo-status-api` already built in Docker)
- Docker Essentials guide completed (or equivalent: Dockerfile, layers, `docker build`/`run`)
- Docker installed and working (to run `kind`)
- Comfort with YAML and the command line; knowing the GitOps vocabulary (`push` vs. `pull`) helps but isn't required
Content
The syllabus, module by module
Open any of them to see its lessons.
- 1. Guide introduction: the orchestrator that was missing
- 2. Why Kubernetes when ECS was already enough
- 3. The continuity challenge: picking up `andes-cargo-status-api` where it left off
- 4. Hands-on: installing `kind` and `kubectl`
- 5. Hands-on: your first cluster
- 6. Cluster architecture: control plane, nodes, and `etcd`
- 7. Hands-on: loading the `andes-cargo-status-api` image into the cluster
- 8. Project: Andes Cargo's cluster, ready
- 1. Introduction: from a container to a managed workload
- 2. What a Pod is, and why you rarely create one directly
- 3. Deployments: ReplicaSets and the declarative control loop
- 4. Hands-on: your first Pod
- 5. Hands-on: `andes-cargo-status-api`'s Deployment
- 6. Services: `ClusterIP`, `NodePort`, and why a Pod isn't a stable address
- 7. Hands-on: exposing `status-api-service`
- 8. Project: `andes-cargo-status-api` with N replicas
- 1. Module introduction: what a Deployment alone doesn't give you
- 2. ConfigMaps: separating configuration from the image
- 3. Secrets: why a credential never lives in the image
- 4. Hands-on: `ConfigMap` and `Secret` for `andes-cargo-status-api`
- 5. Liveness, readiness, and startup probes
- 6. Hands-on: real probes on `status-api-service`
- 7. `HorizontalPodAutoscaler`: scaling by metrics, not by gut feeling
- 8. Project: `andes-cargo-status-api` under load
- 1. Module introduction: the layer that's "not batteries included"
- 2. Kubernetes' networking model: every Pod, an IP
- 3. `Ingress`: a single HTTP door for the cluster
- 4. Hands-on: installing `ingress-nginx` in `kind`
- 5. Hands-on: `Ingress` for `status-api-service`
- 6. `NetworkPolicy`: by default, everyone talks to everyone — and why that doesn't last
- 7. Hands-on: real `NetworkPolicy` on `andes-cargo`
- 8. Project: `status-api-service` exposed and protected
- 1. Module introduction: the other half of GitOps
- 2. Pull-based GitOps: an operator that watches, not a pipeline that pushes
- 3. Hands-on: Gitea in the cluster
- 4. Hands-on: installing ArgoCD
- 5. Anatomy of an ArgoCD `Application`
- 6. Hands-on: syncing `andes-cargo-status-api` from Git
- 7. Deployment strategies: rolling, blue/green, and canary
- 8. Project: a Git change, reflected on its own
- 1. Module introduction: the gatekeeper before `etcd`
- 2. What is an admission controller, and why it runs before the object exists
- 3. OPA Gatekeeper: `ConstraintTemplate` and `Constraint`
- 4. Hands-on: installing Gatekeeper and your first policy
- 5. Kyverno: the YAML-native alternative
- 6. Hands-on: the same policy, in Kyverno
- 7. Hands-on: `trivy image` on `andes-cargo-status-api`
- 8. Project: Andes Cargo's runtime guardrails
- 1. Module introduction: why this one is different from the previous six
- 2. The managed control plane: what AWS runs, what you still own
- 3. Node groups: managed, self-managed, and Fargate profiles
- 4. Node autoscaling: Karpenter vs Cluster Autoscaler
- 5. IRSA and its successor, EKS Pod Identity
- 6. The AWS Load Balancer Controller: the real production `Ingress`
- 7. Hands-on: the EKS YAML, shown and explained
- 8. Project: Andes Cargo's migration plan, `kind` → real EKS
- 1. Capstone introduction
- 2. Architecture review: the full cluster
- 3. End-to-end walkthrough: a change that crosses the whole gate
- 4. End-to-end walkthrough: a change the gate stops
- 5. What this guide left representative, final honesty
- 6. The continuity correction this guide leaves for the ecosystem
- 7. What Andes Cargo still needs
- 8. Final project: `andes-cargo-k8s/` as the capstone deliverable
Common questions
What people usually ask
No limit. It's a free guide: come in whenever you like, as often as you like.
No. Modules run from easier to harder, but you can jump to the one you need. Progress is saved per lesson.
Whatever is needed is listed under “What you need to bring”, above. If nothing is listed there, you can start from zero.
In the Club's WhatsApp group, and every two weeks there's a live with an instructor where questions get worked through.
Yes. It's issued automatically once you finish every lesson, with a verifiable code you can share on LinkedIn.
Start whenever you like
What students say
These reviews are from enrolled students who completed at least 50% of the course. We moderate reviews only on content grounds (spam, offensive language, personal data), never for being critical or negative.
No approved reviews yet.
Be the first to share your experience!