Deploying to AWS EKS Conceptual Preview

Everything this section has deployed to AWS so far has run on ECS — Amazon’s own container orchestrator, tightly integrated with the rest of AWS. Kubernetes is the other major way to run containers at scale, and on AWS it shows up as EKS (Elastic Kubernetes Service). This chapter is intentionally shallow: it tells you what would change if you moved the same image from ECS to EKS, without standing up a real cluster or asking you to learn Kubernetes here. A full Kubernetes course is a better home for that depth than a handful of pages at the tail of a CI/CD course — this chapter’s job is just to make sure the shape of it isn’t a total mystery.

What Actually Changes, Conceptually

The image itself doesn’t change at all — the same devstuffs-hello image sitting in ECR since chapter 50 is exactly what an EKS deployment would run too. What changes is everything around the image:

The GitHub Actions side of the picture would look structurally familiar, even though the details differ:

    flowchart LR
    A[Build & push image<br/>to ECR — unchanged] --> B[aws eks<br/>update-kubeconfig]
    B --> C[kubectl apply<br/>-f deployment.yaml]
    C --> D[EKS control plane<br/>schedules pods]
  

The build-and-push half of the pipeline from chapter 50 would carry over untouched. What replaces the ECS-specific render/deploy steps is aws eks update-kubeconfig (which points your workflow’s kubectl at the right cluster) followed by kubectl apply against a manifest.

An Illustrative Manifest

This is shown to demonstrate the shape of a Kubernetes deployment, not something this chapter has you run — there’s no EKS cluster provisioned in this course, and applying this against nothing would simply fail:

deployment.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: devstuffs-hello
spec:
  replicas: 1
  selector:
    matchLabels:
      app: devstuffs-hello
  template:
    metadata:
      labels:
        app: devstuffs-hello
    spec:
      containers:
        - name: devstuffs-hello
          image: <account-id>.dkr.ecr.us-east-1.amazonaws.com/devstuffs-hello:latest
          ports:
            - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: devstuffs-hello
spec:
  type: LoadBalancer
  selector:
    app: devstuffs-hello
  ports:
    - port: 80
      targetPort: 8080

A few things worth recognizing even at a glance, without needing to master Kubernetes to read them:

• The Deployment describes the desired state — “one replica of this container should be running” — the same underlying idea as an ECS service’s desired-count, just expressed in Kubernetes’ own object model instead of an AWS API call.
• replicas: 1 is directly analogous to the --desired-count 1 you’ve passed to aws ecs create-service throughout this section.
• The Service is what gives the Deployment’s pods a stable network identity and, with type: LoadBalancer, would provision a real load balancer in front of them — conceptually similar to what an ALB would do in front of an ECS service, just requested declaratively instead of created as a separate AWS resource.
• The image reference is identical to the one ECS has been pulling all section — this is the detail that makes clear the container itself was never the AWS-specific or Kubernetes-specific part.

What Would Be Missing From This Preview

To actually run this for real, a workflow would need at minimum: an EKS cluster already provisioned (a nontrivial setup on its own, involving a control plane, node groups or Fargate profiles for EKS, and cluster networking), an IAM-to-Kubernetes-RBAC mapping so the workflow’s AWS credentials are recognized as an authorized Kubernetes user, and a real kubectl apply step with proper rollout verification (kubectl rollout status, the Kubernetes equivalent of the wait-for-service-stability flag you’ve used throughout this section’s ECS chapters). None of that is covered here — that’s genuinely a topic deep enough to deserve its own dedicated course, not a chapter appended to the end of this one.

Where This Leaves You

You now have real, working CI/CD pipelines deploying the same kind of container to two different real destinations conceptually — one you built end-to-end on ECS, and one you’ve seen the shape of on EKS without touching a real cluster. That’s the intended takeaway from this chapter: not Kubernetes fluency, just enough of a mental map that a future EKS pipeline won’t look like an entirely foreign shape when you get there.