AWS EKS: From VPC to Running Blog

Enterprise problem: An Amazon Elastic Kubernetes Service (EKS) cluster can be “active” while Ziba remains unreachable, unschedulable, over-privileged, or OOM-killed because the customer still owns the virtual network, worker capacity, workload identity, manifests, and service outcome. Whole-course context: The incoming shared-responsibility matrix separates provider-operated control-plane infrastructure from customer configuration and workloads; today instantiates that model in AWS. Today’s slice: We follow Terraform and Kubernetes declarations through an Amazon Virtual Private Cloud (VPC), EKS control plane, managed node group, AWS load balancer integration, and Ziba pods. End-of-day evidence: Resource IDs, Kubernetes identities, rollout revision, network path, denied AWS action, OOM recovery, and reader probe form one deployment record. Still unsolved: Karpenter's just-in-time nodes, event-driven pod scaling, and GitOps promotion are deferred.

The thesis is that EKS manages a Kubernetes control plane, not the whole application platform. Start with AWS, pods, and readers; then expand the network, compute, identity, and ownership interfaces that must all work.

Creating an EKS resource is not a customer outcome, and conflating the two leaves broken network and identity paths undiscovered. These use cases prove deployment and recovery through the complete AWS-to-reader chain.

EKS operations cross AWS and Kubernetes identities, so acceptance must join both planes without implying that permission in one grants the other. These stories name the network, workload, denial, and recovery observations required.

An EKS deployment crosses two declarative control planes, so skipping the order can create pods before networking, nodes, or identities exist. The flow begins with a customer-approved release and ends with browser and denial evidence, not with an API returning success.

The EKS control plane and worker nodes occupy different ownership and network boundaries, so drawing them as one box conceals routing, security-group, IAM, and capacity failures. The design expands the AWS-managed and customer-managed VPCs and keeps AWS authorization distinct from Kubernetes authorization.

Troubleshooting stalls when an EC2 instance ID, Kubernetes node UID, pod UID, IAM role, and Terraform address cannot be joined. These records preserve references across planes while leaving authority with AWS IAM, Kubernetes RBAC, the workload controller, and the application data owner respectively.

Generated-application database: Not created in this slice — Ziba's existing content database remains application-owned; Terraform state, AWS resources, Kubernetes state, telemetry, and deployment evidence model the infrastructure slice.

Creating resources out of order produces misleading secondary failures, such as a node that cannot join because its routes, IAM role, DNS, or security path is incomplete. Build and prove each dependency before relying on the layer above it.

1. Account and region: establish quotas, IAM administration, audit logging, encryption policy, support path, and failure-domain requirements.
2. VPC and subnets: allocate non-overlapping addresses and enough pod IP capacity; decide public/private routing, NAT cost/availability, and VPC endpoints.
3. EKS control plane: select endpoint access, version/upgrade policy, logging, encryption, authentication, and control-plane subnets.
4. Compute: choose managed node groups initially, with instance types, image, subnets, labels, taints, scaling bounds, and update policy.
5. Cluster integrations: configure CNI, DNS, storage, metrics, load-balancer reconciliation, and workload identity through reviewed versions.
6. Ziba workload: apply immutable image, requests/limits, replicas, topology spread, probes, disruption policy, Service, and ingress.
7. Evidence: test public path, private API restrictions, denied AWS permission, node loss, OOM recovery, and rollback.

Managed node groups automate EC2 provisioning and draining around updates, but AWS states that customers remain responsible for deploying patched EKS-optimized AMI releases to their node groups; custom AMIs increase that ownership (EKS managed node groups).

Terraform code declares AWS resources while Kubernetes YAML declares desired cluster objects; neither line by itself proves a packet path or available RAM. Map each declaration to the API action, real compute, and customer observation it should cause.

module "eks" {
  source  = "terraform-aws-modules/eks/aws"
  version = "REVIEW_AND_PIN"

  cluster_name    = "ziba-prod"
  cluster_version = var.kubernetes_version
  subnet_ids      = module.vpc.private_subnets

  eks_managed_node_groups = {
    general = {
      instance_types = ["m7i.large"]
      min_size       = 3
      max_size       = 6
      desired_size   = 3
    }
  }
}

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ziba-blog
  namespace: blog
spec:
  replicas: 3
  template:
    spec:
      serviceAccountName: ziba-blog
      containers:
        - name: blog
          image: ACCOUNT.dkr.ecr.REGION.amazonaws.com/ziba@sha256:REPLACE_ME
          resources:
            requests:
              memory: 384Mi
            limits:
              memory: 768Mi

EKS control-plane health does not imply Ziba or its EC2 node has enough memory. Diagnose from the container outward and change AWS capacity only after proving that the scheduler—not merely the process limit—is the constrained layer.

kubectl -n blog get pod -l app=ziba-blog -o wide
kubectl -n blog describe pod POD_NAME
kubectl describe node NODE_NAME
aws eks describe-nodegroup --cluster-name ziba-prod --nodegroup-name general
aws ec2 describe-instances --instance-ids INSTANCE_ID
kubectl -n blog rollout status deployment/ziba-blog

EKS operates the Kubernetes control plane across AWS infrastructure while Ziba executes on customer-selected compute and network paths. Reliable operation joins AWS and Kubernetes identities, keeps their authorization planes distinct, and tests the public outcome plus a denied path.

• An active EKS cluster is necessary but insufficient for a reachable application.
• Managed node groups automate lifecycle steps but retain customer choices and patch rollout duties.
• OOM recovery changes manifests, application code, or worker supply according to the failed boundary.

An EKS deployment is incomplete if the team can show resources but not trace a request or denial across them. Verify each item with one immutable environment run.

• [ ] Linked VPC, subnet, EKS, node-group, EC2 node, Kubernetes node, pod, and revision IDs.
• [ ] Proved public Ziba access and denied unapproved cluster/AWS access.
• [ ] Distinguished AWS IAM from Kubernetes access and RBAC.
• [ ] Mapped Terraform and YAML to actual provider, software, VM, and memory effects.
• [ ] Replayed OOM recovery and preserved an unaffected positive control.