Kubernetes and EKS

QuickCart needs two things from this lesson: to understand what Kubernetes really is, so the argument can be settled with facts, and a way to try EKS that is built and torn down completely in one sitting.

Kubernetes does the same job as ECS: it runs your containers, restarts them when they fail, keeps a set number running, and replaces them one by one when you release. It’s open source and runs anywhere: on every major cloud, and on your own servers. EKS is AWS’s managed Kubernetes.

The big idea is how you talk to it. You don’t tell Kubernetes what to do. You tell it what you want, in a file, and it keeps making that true.

The reconcile loop

Inside Kubernetes, small programs called controllers each watch one kind of object. Each one runs the same loop, over and over, for ever:

That loop is where self-healing comes from. A pod crashes, a node disappears, someone deletes a pod by mistake: the numbers stop matching, and the controller acts. Nobody has to be awake.

The objects, compared with ECS

A Deployment doesn’t create pods itself. It creates a ReplicaSet for each version of your app, and the ReplicaSet creates the pods. During a release, the Deployment grows the new ReplicaSet and shrinks the old one. That’s also how kubectl rollout undo is instant: the old ReplicaSet is still there, just scaled to zero.

Probes: is it alive, and is it ready?

Kubernetes checks each container with probes, small requests it makes on a schedule.

This is a real difference from ECS. On ECS, a task failing its load balancer health check is replaced. On Kubernetes, a pod failing its readiness probe is only taken out of traffic, and a failing liveness probe restarts the container in the same pod.

What EKS runs, and what you run

A Kubernetes cluster has two halves.

Each Kubernetes version gets about 14 months of standard support on EKS. After that it moves to extended support, which costs about six times more for the control plane, until you upgrade. So an EKS cluster isn’t set up once: it needs upgrading, with its nodes and add-ons, for as long as it exists. Prices change; check the EKS pricing page.

Every pod gets its own IP address from your subnet, and each node size has a limit. A t3.small holds about 11 pods, including Kubernetes’ own system pods, however much CPU is free.

Getting traffic in

A Service gives pods a stable name inside the cluster, but nothing outside can reach it. To get an AWS load balancer, you install the AWS Load Balancer Controller into the cluster. It watches for Ingress objects and builds a real Application Load Balancer for each one.

To build load balancers, the controller needs AWS permissions. You give them to that controller alone, not to every pod on the node, with IAM roles for service accounts (IRSA): a Kubernetes identity linked to an IAM role. It’s the same idea as ECS’s task role. EKS also has a newer way to do this, called Pod Identity; the idea is the same.

Releasing without dropped requests

The settings from Releases without downtime have Kubernetes equivalents:

Kubernetes needs two extra settings that ECS handles for you. When a pod is removed, Kubernetes takes it out of the Service and sends it SIGTERM at the same moment. The load balancer takes a few seconds to catch up, and without help, requests arrive at a pod that has already gone.

terminationGracePeriodSeconds is Kubernetes’ stop timeout. It covers the preStop wait and the app’s shutdown, so QuickCart sets it to 40: 15 for the sleep, 20 for gunicorn’s graceful timeout, and 5 to spare.

Here is the order service’s Deployment asking for 2 pods, on a cluster with two nodes. Delete a pod and watch the loop put it back. Then change the number of replicas, and stop node B.

What to notice: you never told Kubernetes to create anything. Every pod it made came from the same three steps: observe, compare, act. And the replacement always gets a new name. Pods are disposable: nothing should depend on one particular pod still existing.

Costs money — about $4 a day while it exists: the EKS control plane (about $2.40 a day), two t3.small nodes (about $1 a day together), and a load balancer (about $0.55 a day). Prices are for us-east-1 and change. Delete everything at the end.

You’ll create an EKS cluster, install the load balancer controller, run QuickCart’s order service on it, watch Kubernetes replace a deleted pod, release v2 under load and roll it back, and then delete everything.

You need the quickcart-orders repository in ECR with the v1 and v2 images from Releases without downtime, your load.py, and a working AWS login in your terminal as an IAM user or role, not root. Set up your computer covers the login.

Why eksctl, not the console

You can create an EKS cluster in the console, but it takes two IAM roles you create first, a cluster form, a wait, a separate node group form, and then the terminal anyway, because kubectl and Helm only run there. eksctl is AWS’s recommended command-line tool for EKS. One command builds the control plane, a managed node group, their IAM roles and the networking, and connects kubectl to the new cluster. It uses CloudFormation underneath, so one more command deletes all of it again. This lab uses eksctl, and still uses the console wherever it has an equivalent.

1. Install the tools

   TerminalCopy

   brew install eksctl kubectl helm

   Part	What it means
   brew install	install programs on your computer with Homebrew
   eksctl	creates and deletes EKS clusters
   kubectl	talks to any Kubernetes cluster: creates, lists and deletes objects
   helm	installs packaged add-ons, called charts, into a cluster

   Check that each one works:

   TerminalCopy

   kubectl version --client

   Part	What it means
   kubectl version	print the version
   --client	only this program’s version. There’s no cluster to ask yet

   You should see

   A line starting Client Version: v1., followed by a version number. eksctl version and helm version print their versions too. Yours will be newer than anything written here.

2. Check who you're logged in as

   The identity that creates the cluster is the one that can use it straight away. Make sure it’s the one you’ll keep using:

   TerminalCopy

   aws sts get-caller-identity

   Part	What it means
   aws sts get-caller-identity	ask AWS who this terminal is logged in as

   You should see

   {
       "UserId": "AIDAEXAMPLEUSERID",
       "Account": "111122223333",
       "Arn": "arn:aws:iam::111122223333:user/quickcart-admin"
   }

   Your IDs and name will differ. The Arn must not end in :root.

3. Find and tag two subnets

   AWSIn the AWS console: VPC→Subnets

   Find the default VPC’s subnets in us-east-1a and us-east-1b: their VPC column shows the default VPC. Copy both Subnet IDs, and the VPC ID. They look like subnet- and vpc- followed by letters and numbers.

   Then tag each of the two subnets, so the load balancer controller knows it may put an internet-facing load balancer there:

   AWSIn the AWS console: VPC→Subnets→your us-east-1a subnet→Tags→Manage tags→Add new tag

   Field	Enter
   Key	kubernetes.io/role/elb
   Value	1

   Choose Save, then do the same for the us-east-1b subnet.

4. Create the cluster

   Put your two subnet IDs in place of SUBNET_A and SUBNET_B, with a comma and no space between them. The \ at the end of a line means the command carries on to the next line.

   TerminalCopy

   eksctl create cluster \
     --name quickcart-eks \
     --region us-east-1 \
     --vpc-public-subnets SUBNET_A,SUBNET_B \
     --nodegroup-name quickcart-nodes \
     --node-type t3.small \
     --nodes 2 \
     --managed

   Part	What it means
   eksctl create cluster	build a new EKS cluster, with everything it needs
   --name quickcart-eks	the cluster’s name
   --region us-east-1	the region to build it in
   --vpc-public-subnets SUBNET_A,SUBNET_B	use these two existing subnets in your default VPC, instead of building a new VPC
   --nodegroup-name quickcart-nodes	the name of the group of servers
   --node-type t3.small	the size of each server: 2 vCPUs, 2 GB of memory, about 11 pods
   --nodes 2	two servers, so there’s one in each zone
   --managed	a managed node group: AWS launches, and helps you update, the servers

   There’s no --version, on purpose: eksctl picks a current version on standard support.

   You should see

   Many lines over about 15 to 20 minutes, as eksctl builds the control plane and then the nodes. It ends with a line like EKS cluster "quickcart-eks" in "us-east-1" region is ready. It has also saved the cluster’s details for kubectl, so the next command just works.

   Check the nodes:

   TerminalCopy

   kubectl get nodes

   Part	What it means
   kubectl get nodes	list the servers in the cluster

   You should see

   NAME                            STATUS   ROLES    AGE   VERSION
   ip-172-31-17-201.ec2.internal   Ready    <none>   3m    v1.33.4-eks-a1b2c3d
   ip-172-31-90-12.ec2.internal    Ready    <none>   3m    v1.33.4-eks-a1b2c3d

   Your names, ages and versions will differ. Both must say Ready. In EC2 → Instances there are now two new instances: they’re yours, and on your bill.

5. Let one pod have its own IAM role

   The load balancer controller needs AWS permissions. This command switches on the feature that lets a single Kubernetes identity use an IAM role:

   TerminalCopy

   eksctl utils associate-iam-oidc-provider --cluster quickcart-eks --region us-east-1 --approve

   Part	What it means
   eksctl utils associate-iam-oidc-provider	register the cluster with IAM as an identity provider, so IAM can trust identities from inside it
   --cluster quickcart-eks	which cluster
   --region us-east-1	where the cluster is
   --approve	actually do it. Without this, eksctl only shows what it would do

   You should see

   A line saying the IAM OIDC provider was created for the cluster. In IAM → Identity providers, a new provider whose address mentions oidc.eks.us-east-1.

6. Create the controller's IAM policy

   The controller’s permissions are published as a JSON file called iam_policy.json, linked from the AWS Load Balancer Controller installation guide in the Amazon EKS documentation. It’s long, and AWS updates it with each controller release, so always take the current file from the guide rather than an old copy. Download it, and open it in a text editor.

   AWSIn the AWS console: IAM→Policies→Create policy→JSON

   Delete everything in the editor, then paste in the whole contents of iam_policy.json. Choose Next.

   Field	Enter
   Policy name	QuickCartLBControllerPolicy

   Choose Create policy.

   You should see

   The policy in the list. Open it and copy its ARN: arn:aws:iam::111122223333:policy/QuickCartLBControllerPolicy, with your account ID.

7. Give the controller that policy

   This step and the next have no console equivalent. Linking an IAM role to an identity inside Kubernetes takes a role with a special trust policy plus a Kubernetes object; eksctl does both in one command. Put your account ID in the ARN:

   TerminalCopy

   eksctl create iamserviceaccount \
     --cluster quickcart-eks \
     --region us-east-1 \
     --namespace kube-system \
     --name aws-load-balancer-controller \
     --role-name QuickCartLBControllerRole \
     --attach-policy-arn arn:aws:iam::111122223333:policy/QuickCartLBControllerPolicy \
     --approve

   Part	What it means
   eksctl create iamserviceaccount	create a Kubernetes service account (an identity for pods) and an IAM role linked to it
   --namespace kube-system	put it with Kubernetes’ own system programs
   --name aws-load-balancer-controller	the service account’s name. The controller will run as this identity
   --role-name QuickCartLBControllerRole	the IAM role’s name, so you can find it later
   --attach-policy-arn	give the role the policy you just created
   --approve	actually do it

   You should see

   About a minute of output, including a CloudFormation stack being created, and a line saying the service account was created.

8. Install the controller with Helm

   First tell Helm where AWS publishes its EKS charts. The repository address is in the same installation guide, in its Helm section; put it in place of CHART_REPO_URL:

   TerminalCopy

   helm repo add eks CHART_REPO_URL

   Part	What it means
   helm repo add	remember a chart repository, so you can install from it
   eks	the short name you’ll use for it
   CHART_REPO_URL	replace this with the eks-charts repository address from the installation guide

   You should see

   "eks" has been added to your repositories

   Now install the controller. Put your VPC ID in place of VPC_ID:

   TerminalCopy

   helm install aws-load-balancer-controller eks/aws-load-balancer-controller \
     --namespace kube-system \
     --set clusterName=quickcart-eks \
     --set serviceAccount.create=false \
     --set serviceAccount.name=aws-load-balancer-controller \
     --set region=us-east-1 \
     --set vpcId=VPC_ID

   Part	What it means
   helm install aws-load-balancer-controller	install a chart, and call this installation aws-load-balancer-controller
   eks/aws-load-balancer-controller	the chart: from the eks repository, the one called aws-load-balancer-controller
   --namespace kube-system	install it next to the service account you made
   --set clusterName=quickcart-eks	tell it which cluster it’s in, so it can name and tag what it builds
   --set serviceAccount.create=false	don’t make a new identity
   --set serviceAccount.name=aws-load-balancer-controller	use the one eksctl made, with the IAM role
   --set region=us-east-1 and --set vpcId=VPC_ID	tell it where it is. Without these, it tries to look them up from the node, which can fail

   You should see

   A few lines ending in STATUS: deployed, and a note that the controller is installed.

   Check it’s running:

   TerminalCopy

   kubectl get deployment --namespace kube-system aws-load-balancer-controller

   Part	What it means
   kubectl get deployment	show a Deployment and how many of its pods are ready
   --namespace kube-system	look in the kube-system namespace, not default
   aws-load-balancer-controller	which Deployment

   You should see

   NAME                           READY   UP-TO-DATE   AVAILABLE   AGE
   aws-load-balancer-controller   2/2     2            2           70s

   If it shows 0/2, wait a minute and run it again. Count what you just did to connect a load balancer: an identity provider, a policy, a service account, a chart. On ECS it was one section of the service form. That difference belongs in the ECS or EKS decision.

9. Turn on readiness gates

   TerminalCopy

   kubectl label namespace default elbv2.k8s.aws/pod-readiness-gate-inject=enabled

   Part	What it means
   kubectl label	add a label to an object
   namespace default	the object: the default namespace, where your app will run
   elbv2.k8s.aws/pod-readiness-gate-inject=enabled	the label the controller looks for. Pods created in this namespace from now on get a readiness gate

   You should see

   namespace/default labeled

   From now on, a new pod here only counts as ready once the load balancer reports it healthy. Label the namespace before creating the pods: pods that already exist don’t get the gate.

10. Describe the app

    In your order-service folder, create order-service.yaml. It describes three objects, separated by --- lines. Put your account ID in the image address.

    order-service.yamlCopy

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: order-service
      labels:
        app: order-service
    spec:
      replicas: 2
      selector:
        matchLabels:
          app: order-service
      strategy:
        type: RollingUpdate
        rollingUpdate:
          maxUnavailable: 0
          maxSurge: 1
      template:
        metadata:
          labels:
            app: order-service
        spec:
          terminationGracePeriodSeconds: 40
          securityContext:
            runAsNonRoot: true
            runAsUser: 1001
          containers:
            - name: app
              image: 111122223333.dkr.ecr.us-east-1.amazonaws.com/quickcart-orders:v1
              ports:
                - containerPort: 8080
              readinessProbe:
                httpGet:
                  path: /health
                  port: 8080
                periodSeconds: 5
                failureThreshold: 2
              livenessProbe:
                httpGet:
                  path: /health
                  port: 8080
                initialDelaySeconds: 15
                periodSeconds: 10
                failureThreshold: 3
              resources:
                requests:
                  cpu: 100m
                  memory: 128Mi
                limits:
                  memory: 256Mi
              securityContext:
                allowPrivilegeEscalation: false
              lifecycle:
                preStop:
                  exec:
                    command: ["sleep", "15"]
    ---
    apiVersion: v1
    kind: Service
    metadata:
      name: order-service
    spec:
      selector:
        app: order-service
      ports:
        - port: 80
          targetPort: 8080
    ---
    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      name: order-service
      annotations:
        alb.ingress.kubernetes.io/scheme: internet-facing
        alb.ingress.kubernetes.io/target-type: ip
        alb.ingress.kubernetes.io/healthcheck-path: /health
        alb.ingress.kubernetes.io/target-group-attributes: deregistration_delay.timeout_seconds=30
    spec:
      ingressClassName: alb
      rules:
        - http:
            paths:
              - path: /
                pathType: Prefix
                backend:
                  service:
                    name: order-service
                    port:
                      number: 80

    The Deployment

    Setting	What it does	If you leave it out	When you’d change it
    apiVersion: apps/v1, kind: Deployment	Which kind of object this is	Required	Never
    metadata.name	The Deployment’s name, used by kubectl commands	Required	Never, once created
    replicas: 2	The desired state: 2 pods	1 pod	To scale by hand, or let an autoscaler set it
    selector.matchLabels	Which pods belong to this Deployment: those labelled app: order-service	Required	Never. It can’t be changed after creation
    strategy.rollingUpdate.maxUnavailable: 0	During a release, never have fewer than 2 ready pods	25% of the replicas may be missing	Higher, to release faster when spare capacity doesn’t matter
    strategy.rollingUpdate.maxSurge: 1	During a release, run at most 1 extra pod	25% extra, rounded up	Higher, to release faster when you have spare node capacity
    template.metadata.labels	Labels on every pod. Must match the selector	The Deployment is rejected	Add labels for version or team
    terminationGracePeriodSeconds: 40	Kubernetes’ stop timeout: 15 s preStop + 20 s gunicorn + 5 spare	30 seconds: gunicorn could be killed mid-request	If your requests or shutdown take longer
    securityContext.runAsNonRoot: true	Refuse to start the container as root	Nothing stops a root container	Never
    securityContext.runAsUser: 1001	Run as user 1001, the appuser from the Dockerfile	Uses the image’s USER	Only if the image’s user changes
    containers[].name: app	The container’s name, used by kubectl set image	Required	Never
    image	The image to run, from ECR, by tag	Required	Every release
    ports.containerPort: 8080	The port the app listens on. Mostly documentation, like EXPOSE	The app still works; tools that read it can’t	If the app’s port changes
    readinessProbe	Ask /health every 5 s; 2 failures in a row takes the pod out of traffic	The pod gets traffic as soon as it starts, before the app is ready	Tighter for fast apps, looser for slow ones
    livenessProbe	Ask /health every 10 s after 15 s; 3 failures in a row restart the container	A stuck app is never restarted	Keep it lenient. See the mistake in the idea
    resources.requests	What the scheduler reserves on a node: a tenth of a CPU and 128 MB	The pod may land on a node with no room, and be squeezed	Measure real use, then set it a little above
    resources.limits.memory: 256Mi	The most memory the container may use. Above it, it’s killed, shown as OOMKilled	It can use all of a node’s memory, and starve its neighbours	When the app really needs more
    allowPrivilegeEscalation: false	The process can never gain more privileges than it starts with	Allowed	Never
    lifecycle.preStop sleep 15	Keep serving for 15 s after being told to stop, while the load balancer catches up	Requests arrive at a pod that has already gone	Match it to how long your load balancer takes to deregister

    The Service and the Ingress

    Setting	What it does	If you leave it out	When you’d change it
    Service selector: app: order-service	Send traffic to pods with this label, as long as they’re ready	The Service has no pods behind it	Never, while the labels stay the same
    Service port: 80, targetPort: 8080	Inside the cluster, order-service:80 reaches the pods on 8080	Required	If the app’s port changes
    ingressClassName: alb	Hand this Ingress to the AWS Load Balancer Controller	No controller claims it, and no load balancer is built	Never, on EKS with this controller
    alb.ingress.kubernetes.io/scheme: internet-facing	A public load balancer	internal: reachable only inside the VPC	For services only other services call
    alb.ingress.kubernetes.io/target-type: ip	Register pod IPs directly, like Fargate tasks	instance: traffic goes via a port on each node, an extra hop	Rarely
    alb.ingress.kubernetes.io/healthcheck-path: /health	The ALB’s health check path	/, which works here, but isn’t a real readiness check	If the health path changes
    target-group-attributes: deregistration_delay.timeout_seconds=30	The drain, as on ECS	300 seconds: slow releases	Longer than your slowest request
    rules with path: / and pathType: Prefix	Send every path to the order-service Service on port 80	Required	To route different paths to different Services

    This Ingress listens on HTTP port 80 only. For HTTPS you’d add a certificate from Certificate Manager with the alb.ingress.kubernetes.io/certificate-arn annotation and a listener on 443, as in Domain names and HTTPS.

11. Start it

    TerminalCopy

    kubectl apply -f order-service.yaml

    Part	What it means
    kubectl apply	make the cluster match a file: create what’s new, update what changed
    -f order-service.yaml	the file to use

    You should see

    deployment.apps/order-service created
    service/order-service created
    ingress.networking.k8s.io/order-service created

    TerminalCopy

    kubectl get pods

    Part	What it means
    kubectl get pods	list the pods in the default namespace

    You should see

    NAME                             READY   STATUS    RESTARTS   AGE
    order-service-7d4b9c8f6-x2kqp    1/1     Running   0          40s
    order-service-7d4b9c8f6-m8zrt    1/1     Running   0          40s

    The part in the middle of each name comes from the ReplicaSet; the end is random. Yours differ.

    Now wait for the load balancer:

    TerminalCopy

    kubectl get ingress

    Part	What it means
    kubectl get ingress	list Ingresses, with the address of the load balancer built for each

    You should see

    NAME            CLASS   HOSTS   ADDRESS                                                                  PORTS   AGE
    order-service   alb     *       k8s-default-orderser-1a2b3c4d5e-1234567890.us-east-1.elb.amazonaws.com   80      3m

    The ADDRESS appears after two or three minutes; until then, it’s empty. In EC2 → Load balancers, a new load balancer starting with k8s-default- exists. Your YAML file made a real AWS resource.

12. Reach it, and delete a pod

    Copy the ADDRESS from the last command:

    TerminalCopy

    curl INGRESS_ADDRESS/

    Part	What it means
    curl	fetch the page and print it
    INGRESS_ADDRESS	replace this with the address from kubectl get ingress

    You should see

    {"served_by":"order-service-7d4b9c8f6-x2kqp","service":"order-service","version":"v1"}

    A pod’s hostname is its name, so served_by tells you which pod answered. Run it a few times: it switches between the two.

    Now delete one of them, using a name from your kubectl get pods:

    TerminalCopy

    kubectl delete pod POD_NAME

    Part	What it means
    kubectl delete pod	delete one pod
    POD_NAME	replace this with one of your pod names

    TerminalCopy

    kubectl get pods

    Part	What it means
    kubectl get pods	list the pods again, to see what Kubernetes did

    You should see

    Two pods again, 1/1 Running. One has the name you didn’t delete; the other is new, with an AGE of a few seconds. You changed nothing in the file. The reconcile loop saw 1 where you’d asked for 2, and acted.

13. Release v2 under load, then roll back

    Window 1: start the load test, with the Ingress address:

    TerminalCopy

    python3 load.py http://INGRESS_ADDRESS/ 240

    Part	What it means
    python3 load.py	the load test from Releases without downtime
    http://INGRESS_ADDRESS/	the EKS load balancer this time
    240	four minutes

    Window 2: change the image. Put your account ID in:

    TerminalCopy

    kubectl set image deployment/order-service app=111122223333.dkr.ecr.us-east-1.amazonaws.com/quickcart-orders:v2

    Part	What it means
    kubectl set image	change the image of a container in an object
    deployment/order-service	which object
    app=	which container: the one named app
    the rest	the new image: the v2 tag

    You should see

    deployment.apps/order-service image updated

    Watch the release:

    TerminalCopy

    kubectl rollout status deployment/order-service

    Part	What it means
    kubectl rollout status	wait, printing progress, until the release finishes or fails

    You should see

    Lines like Waiting for deployment "order-service" rollout to finish, one pod at a time because of maxSurge: 1, then deployment "order-service" successfully rolled out. When window 1 finishes, write down its totals. The target is failed: 0.

    Now go back to v1, with one command:

    TerminalCopy

    kubectl rollout undo deployment/order-service

    Part	What it means
    kubectl rollout undo	go back to the previous version. The old ReplicaSet is scaled up again; nothing is rebuilt

    You should see

    deployment.apps/order-service rolled back

    curl INGRESS_ADDRESS/ shows "version":"v1" again within a minute.

14. Release a broken version

    TerminalCopy

    kubectl set image deployment/order-service app=111122223333.dkr.ecr.us-east-1.amazonaws.com/quickcart-orders:v9-broken

    Part	What it means
    v9-broken	a tag that doesn’t exist

    TerminalCopy

    kubectl get pods

    Part	What it means
    kubectl get pods	list the pods, old and new

    You should see

    The two old pods still 1/1 Running, and one new pod with the status ErrImagePull or ImagePullBackOff, 0/1. Because maxUnavailable is 0, Kubernetes won’t remove an old pod until a new one is ready, so the site keeps working.

    This is where ECS and Kubernetes differ. ECS’s circuit breaker would roll back by itself. Kubernetes stops and waits. kubectl rollout status would wait up to the Deployment’s progress deadline, 10 minutes by default, then report exceeded its progress deadline, and still not roll back. You undo it:

    TerminalCopy

    kubectl rollout undo deployment/order-service

    Part	What it means
    kubectl rollout undo	go back to the previous version, the v1 ReplicaSet, which never stopped running
    deployment/order-service	which Deployment

    You should see

    deployment.apps/order-service rolled back, and within a few seconds kubectl get pods shows only healthy pods again.

15. Clean-up step: Clean up

    Do this in order. The load balancer was built by the controller, not by eksctl. Delete the app while the controller is still running, so it removes the load balancer too.

    1. Delete the app:

    TerminalCopy

    kubectl delete -f order-service.yaml

    Part	What it means
    kubectl delete -f	delete every object described in the file, including the Ingress, and so the load balancer

    You should see

    deployment.apps "order-service" deleted
    service "order-service" deleted
    ingress.networking.k8s.io "order-service" deleted

    2. Check the load balancer has gone. Wait two minutes, then look in EC2 → Load balancers. There must be no load balancer starting with k8s-default-. If one is still there after five minutes, delete it by hand, and its target group in EC2 → Target groups.

    3. Delete the cluster. This removes the nodes, the node group, the control plane, the service account’s IAM role and the other CloudFormation stacks eksctl made:

    TerminalCopy

    eksctl delete cluster --name quickcart-eks --region us-east-1 --wait

    Part	What it means
    eksctl delete cluster	delete the cluster and everything eksctl created for it
    --name quickcart-eks	which cluster
    --region us-east-1	where it is
    --wait	don’t return until it’s completely gone

    You should see

    10 to 15 minutes of output, ending in a line saying all cluster resources were deleted.

    4. Delete the policy. IAM → Policies, search for QuickCartLBControllerPolicy, select it, Delete, and type its name to confirm.

    5. Remove the subnet tags (optional, harmless to keep): VPC → Subnets, each of the two subnets, Tags → Manage tags, remove kubernetes.io/role/elb.

    6. The image repository, if you’ve finished with containers: Amazon ECR → Repositories, tick quickcart-orders, Delete, type delete.

    7. Check nothing is left:

    Where	Should show
    EKS → Clusters	nothing
    EC2 → Instances	no running instances from this lab; the two nodes show Terminated
    EC2 → Load balancers	nothing starting with k8s-
    CloudFormation → Stacks	no stacks starting with eksctl-quickcart-eks
    IAM → Identity providers	no provider mentioning this cluster. If one is left, delete it

    You should see

    All five checks pass. Nothing from this lab is still billing. Check the Billing page tomorrow to be sure.