Your image is published — but where does it run? In Project 2 you provision infrastructure as code with Terraform (reproducible, version-controlled), then deploy your app to Kubernetes with the resilience features that make it production-worthy: health checks, resource limits, and autoscaling.

🎯 Learning Objectives

• Provision a Kubernetes cluster with Terraform
• Understand remote state and why it matters
• Write Kubernetes manifests with health checks and resource limits
• Expose the app and enable autoscaling

Step 1 — Provision Infrastructure with Terraform

Rather than clicking around a cloud console, you declare the cluster in code. A minimal example provisioning a managed cluster:

# main.tf
terraform {
backend "s3" {                 # remote state (see below)
  bucket = "my-tf-state"
  key    = "prod/cluster.tfstate"
  region = "us-east-1"
}
}

module "cluster" {
source          = "terraform-aws-modules/eks/aws"
cluster_name    = "portfolio-cluster"
cluster_version = "1.30"
# ... vpc, node groups, etc.
}

output "cluster_endpoint" {
value = module.cluster.cluster_endpoint
}

The workflow is always the same three commands:

terraform init      # download providers, connect backend
terraform plan      # preview what will change (review this!)
terraform apply     # create the infrastructure

Step 2 — Use Remote State

Notice the backend "s3" block. Terraform tracks reality in a state file. Keeping it on your laptop is a disaster waiting to happen — lost laptop, no teamwork, conflicting changes. Remote state (S3, GCS, Terraform Cloud) fixes this:

• Shared — the whole team works from one source of truth
• Locked — prevents two people applying at once and corrupting state
• Durable & versioned — survives your machine and can be rolled back

Step 3 — Deploy to Kubernetes

With the cluster up, deploy your Project 1 image. A production-worthy Deployment includes probes and resource limits — not just the bare minimum:

apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp
spec:
replicas: 3
selector:
  matchLabels: { app: myapp }
template:
  metadata:
    labels: { app: myapp }
  spec:
    containers:
      - name: myapp
        image: ghcr.io/you/myapp:a1b2c3d      # deploy by SHA, not latest
        ports:
          - containerPort: 3000
        livenessProbe:                          # restart if hung
          httpGet: { path: /health, port: 3000 }
          initialDelaySeconds: 5
        readinessProbe:                         # don't send traffic until ready
          httpGet: { path: /health, port: 3000 }
        resources:
          requests: { cpu: "100m", memory: "128Mi" }
          limits:   { cpu: "500m", memory: "256Mi" }

Expose it with a Service so traffic can reach the pods:

apiVersion: v1
kind: Service
metadata:
name: myapp
spec:
type: LoadBalancer
selector: { app: myapp }
ports:
  - port: 80
    targetPort: 3000

deployment.apps/myapp created
service/myapp created

NAME                     READY   STATUS    RESTARTS   AGE
myapp-7d9f8c6b4-2xk9p    1/1     Running   0          20s
myapp-7d9f8c6b4-8mn4q    1/1     Running   0          20s
myapp-7d9f8c6b4-p7wz3    1/1     Running   0          20s

Step 4 — Autoscale

Let Kubernetes add and remove pods based on load with a HorizontalPodAutoscaler:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: myapp
spec:
scaleTargetRef:
  apiVersion: apps/v1
  kind: Deployment
  name: myapp
minReplicas: 3
maxReplicas: 10
metrics:
  - type: Resource
    resource:
      name: cpu
      target: { type: Utilization, averageUtilization: 70 }

Now the app scales out past 3 pods when CPU crosses 70%, and back in when load drops — capacity that follows demand, defined declaratively.

🧪 Hands-on Lab

🧠 Knowledge Check

💼 Interview Preparation

Summary

Project 2 is complete: Terraform provisions your cluster reproducibly with remote state, and your app runs on Kubernetes with probes, resource limits, a Service, and autoscaling. The final project adds the operational layer — observability and GitOps — to make the whole system truly production-grade.