Groundhog Deploy

beginnerCrashLoopBackOff

Objective

Escape Room: Groundhog Deploy

The application pod keeps crashing on startup and nothing seems to change.

Your Mission

Identify why the pod is crashing
Determine what configuration is missing
Fix the deployment so the pod runs successfully

Success Criteria

The escape-app pod is in Running state
The pod has been running for at least 30 seconds without restarting

Getting Started

# Check the pod status
kubectl get pods -n escape-room-groundhog-deploy

# You'll see something like:
# NAME                          READY   STATUS             RESTARTS   AGE
# escape-app-5d4f7b8c9-x2k7p   0/1     CrashLoopBackOff   3          2m

Namespace

All resources are in the escape-room-groundhog-deploy namespace.

Good luck, engineer. The clock is ticking.

Quick Start

Run this command in your terminal to set up the room:

$ make room-apply ROOM=room-groundhog-deploy

This creates the namespace escape-room-groundhog-deploy with the broken resources.

Other useful commands:

$ make room-test ROOM=room-groundhog-deploy

Verify the room is in the expected broken state

$ make room-escape-test ROOM=room-groundhog-deploy

Test if you have successfully fixed all issues

$ make room-reset ROOM=room-groundhog-deploy

Reset the room to try again

Useful Commands

Check pod status

$ kubectl get pods -n escape-room-groundhog-deploy

See the current state of pods in the namespace

View events

$ kubectl get events -n escape-room-groundhog-deploy --sort-by='.lastTimestamp'

Check recent events for error details

Describe pods

$ kubectl describe pods -n escape-room-groundhog-deploy

Get detailed information about pods

Check logs

$ kubectl logs -l app.kubernetes.io/part-of=K8sEscapeRoom -n escape-room-groundhog-deploy

View the application logs

Hints

0/4 revealed

Submit Proof

View Solution (Spoiler)

Solution preview locked

Complete the room to unlock the full solution here

Run this to see the full solution:

$ make room-solution ROOM=room-groundhog-deploy

Show solution anyway (spoiler)

Solution: CrashLoopBackOff - Missing Environment Variable

Root Cause

The deployment's pod template is missing a required environment variable DATABASE_URL. The application checks for this variable at startup and exits with an error if it's not present.

Diagnosis Steps

# 1. Check pod status - see CrashLoopBackOff
kubectl get pods -n escape-room-groundhog-deploy

# 2. Check logs to see the actual error
kubectl logs -l app=escape-app -n escape-room-groundhog-deploy
# Output: FATAL: Required environment variable DATABASE_URL is not set

# 3. Inspect the deployment spec to confirm missing env var
kubectl get deployment escape-app -n escape-room-groundhog-deploy -o yaml | grep -A 10 "env:"
# (No env section present)

The Fix

Option 1: Quick Fix with kubectl set env (Recommended)

kubectl set env deployment/escape-app DATABASE_URL=postgres://localhost:5432/mydb -n escape-room-groundhog-deploy

This adds the environment variable and triggers a rolling update automatically.

Option 2: Edit the Deployment Directly

kubectl edit deployment/escape-app -n escape-room-groundhog-deploy

Add the env section under the container spec:

      containers:
        - name: app
          # ... existing fields ...
          env:
            - name: DATABASE_URL
              value: "postgres://localhost:5432/mydb"

Save and exit — Kubernetes will automatically roll out the change.

Verification

# Wait for the rollout to complete
kubectl rollout status deployment/escape-app -n escape-room-groundhog-deploy

# Check the pod is now running
kubectl get pods -n escape-room-groundhog-deploy
# NAME                          READY   STATUS    RESTARTS   AGE
# escape-app-5d4f7b8c9-x2k7p   1/1     Running   0          30s

# Verify the logs show success
kubectl logs -l app=escape-app -n escape-room-groundhog-deploy
# Connected to database: postgres://localhost:5432/mydb
# Application started successfully

Lessons Learned

Always check logs first - CrashLoopBackOff usually has a clear error message
Environment variables matter - Many real applications fail without required config
Deployments make updates easy - kubectl set env lets you add env vars with a single command
Rollouts are automatic - Changing a Deployment's pod template triggers a rolling update

Real-World Considerations

In production, you would:

Store secrets in Kubernetes Secrets (not plain text in manifests)
Use ConfigMaps for non-sensitive configuration
Set up health checks (readiness/liveness probes)
Use rollback if a change causes issues: kubectl rollout undo deployment/escape-app

# Example: Using a Secret for DATABASE_URL
env:
  - name: DATABASE_URL
    valueFrom:
      secretKeyRef:
        name: app-secrets
        key: database-url