Files
kodekloud-engineer/kubernetes/level 1/task-2.md

3.5 KiB

Assignment

The Nautilus DevOps team is delving into Kubernetes for app management. One team member needs to create a deployment following these details:

Create a deployment named httpd to deploy the application httpd using the image httpd:latest (ensure to specify the tag)

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

Solution

Kubernetes Deployment — httpd

A Deployment named httpd running the httpd:latest image. Applied inline via a heredoc — no manifest file on disk.

Apply (heredoc → kubectl)

kubectl apply -f - <<'EOF'
apiVersion: apps/v1
kind: Deployment
metadata:
  name: httpd
  labels:
    app: httpd
spec:
  replicas: 1
  selector:
    matchLabels:
      app: httpd
  template:
    metadata:
      labels:
        app: httpd
    spec:
      containers:
        - name: httpd
          image: httpd:latest
EOF

How it works

The heredoc apply pattern

  • kubectl apply -f - reads the manifest from stdin; the heredoc feeds the YAML straight in, so nothing is written to disk.
  • <<'EOF' (delimiter quoted) disables shell expansion inside the body, so any $VAR / backticks in a manifest stay literal — the right default for Kubernetes YAML.
  • Indentation matters — keep it exact, spaces not tabs.

The manifest, field by field

  • apiVersion: apps/v1 / kind: Deployment — a Deployment is an apps/v1 object that manages a ReplicaSet, which in turn manages Pods. It gives you declarative updates, rollouts/rollbacks, and self-healing (recreates pods that die).
  • metadata.name: httpd — the Deployment's name, exactly as required.
  • spec.replicas: 1 — how many pod copies to run. The task doesn't specify a count, so one replica is the minimal correct choice.
  • spec.selector.matchLabels.app: httpd — how the Deployment finds the pods it owns. This must match the pod template's labels below, or the API rejects the manifest (selector does not match template labels).
  • spec.template — the pod blueprint the Deployment stamps out:
    • template.metadata.labels.app: httpd — labels applied to each pod; these are what the selector targets. The label key/value is arbitrary but must be consistent between selector and template.
    • template.spec.containers — one container:
      • name: httpd — container name.
      • image: httpd:latest — the Apache HTTP Server image at the latest tag, stated explicitly as required. (Bare httpd defaults to latest, but the task asks for the tag to be specified.)

Why the selector/template labels must agree

A Deployment is decoupled from its pods — it tracks them purely by label selector. spec.selector.matchLabels is the query; spec.template.metadata.labels is what gets stamped on each pod. If they don't match, the Deployment couldn't recognize its own pods, so Kubernetes rejects the config outright. Keeping both app: httpd satisfies that contract.

Verify

# Deployment exists and is available
kubectl get deployment httpd

# Rollout completed
kubectl rollout status deployment/httpd

# Pod is running with the right image
kubectl get pods -l app=httpd \
  -o jsonpath='{.items[0].spec.containers[0].image}{"\n"}'

Expected — httpd deployment showing READY 1/1, rollout reporting success, and the image printing httpd:latest.

If a pod sits in ImagePullBackOff, the node may be offline or rate-limited on the pull. kubectl describe pod <name> shows pull events under Events:.