# Assignment

A junior DevOps team member encountered difficulties deploying a stack on the Kubernetes cluster. The pod fails to start, presenting errors. Let's troubleshoot and rectify the issue promptly.


There is a pod named webserver, and the container within it is named httpd-container, its utilizing the httpd:latest image.

Additionally, there's a sidecar container named sidecar-container using the ubuntu:latest image.

Identify and address the issue to ensure the pod is in the running state and the application is accessible.

Note: The kubectl utility on the jump-host has been configured to work with the Kubernetes cluster.

# Solution

There is incorrect image in the pod ... just fix it

# Troubleshoot Pod — `webserver` (httpd + ubuntu sidecar)

The `webserver` pod won't start. This walks the diagnosis, then applies a corrected
manifest via heredoc.

## Step 1 — Diagnose

```bash
# Overall state + which container is failing
kubectl get pod webserver -o wide

# The authoritative source: events + per-container state at the bottom
kubectl describe pod webserver

# Logs from each container (the sidecar is the usual culprit)
kubectl logs webserver -c httpd-container
kubectl logs webserver -c sidecar-container
```

Look at the container states in `describe`: `ImagePullBackOff` / `ErrImagePull` points to
a **bad image name or tag**; `CrashLoopBackOff` with the sidecar exiting `Completed` points
to a **container with no long-running process**.

## Step 2 — The two usual root causes

For this specific setup (an `httpd` container plus an `ubuntu` sidecar), the failure is
almost always one or both of:

1. **Image typo** — e.g. `httpd:latst`, `httpd:letest`, or a misspelled `ubuntu` — which
   yields `ErrImagePull` / `ImagePullBackOff`.
2. **The ubuntu sidecar exits immediately.** `ubuntu:latest` has no long-running entrypoint
   — it starts a shell, finds nothing to do, and exits `0`. Kubernetes sees the container
   terminate and puts the pod in `CrashLoopBackOff` (it keeps restarting a container that
   keeps exiting). A sidecar **must** be given a command that keeps it alive.

## Step 3 — Fix (recreate with a corrected manifest)

A pod's container image and command are effectively immutable in place, so the clean fix is
delete and re-create:

```bash
kubectl delete pod webserver

kubectl apply -f - <<'EOF'
apiVersion: v1
kind: Pod
metadata:
  name: webserver
  labels:
    app: httpd
spec:
  containers:
    - name: httpd-container
      image: httpd:latest
    - name: sidecar-container
      image: ubuntu:latest
      command:
        - /bin/sh
        - -c
        - "while true; do echo sidecar running; sleep 5; done"
EOF
```

## How it works

### The heredoc apply pattern

- **`kubectl apply -f -`** reads the manifest from **stdin**; nothing written to disk.
- **`<<'EOF'` (delimiter quoted)** keeps the `while`/`$`-free command literal so the
  container's shell runs it as written.

### What the corrected manifest fixes

- **`httpd-container` → `image: httpd:latest`** — a valid, correctly-spelled image/tag, so
  the pull succeeds (fixes any `ImagePullBackOff` from a typo).
- **`sidecar-container` → `command: [...while true...sleep 5...]`** — gives the ubuntu
  container a **long-running foreground process**. Now it never exits, so the pod stays
  `Running` instead of crash-looping. Any equivalent keep-alive works (`sleep infinity`,
  `tail -f /dev/null`); the infinite loop is a clear, portable choice.

### Why a sidecar needs a command but httpd doesn't

`httpd:latest`'s default entrypoint **is** a long-running server (Apache in the
foreground), so it stays up on its own. `ubuntu:latest` has no such default — its job here
is just to accompany the main container, so **you** must supply the process that keeps it
alive. This asymmetry is the heart of the bug: the same manifest that's fine for httpd
leaves ubuntu dead on arrival.

### "Application accessible"

Once both containers stay up, the pod reports `2/2 Running` and Apache serves on its
default port 80 inside the pod. You can confirm the app responds from within the pod
(below); exposing it externally would be a separate Service, which this task doesn't ask
for.

## Verify

```bash
# Both containers up: READY should show 2/2
kubectl get pod webserver

# No more restart churn / crash events
kubectl describe pod webserver | sed -n '/Events/,$p'

# httpd actually serving inside the pod
kubectl exec webserver -c httpd-container -- sh -c 'apt-get -v >/dev/null 2>&1; echo ok' 2>/dev/null || true
kubectl exec webserver -c sidecar-container -- echo "sidecar alive"
```

Expected — `webserver` in `Running` with `READY 2/2`, no crash-loop events, and both
`exec` checks succeeding. Apache serving on port 80 within the pod.

> If `describe` still shows `ImagePullBackOff` after the fix, the node is offline or
> rate-limited on the registry — not a manifest problem. If the sidecar still exits,
> confirm its `command` made it into the spec:
> `kubectl get pod webserver -o jsonpath='{.spec.containers[1].command}'`.