Assignment

The Nautilus DevOps team is gearing up to deploy applications on a Kubernetes cluster for migration purposes. A team member has been tasked with creating a ReplicaSet outlined below:

Create a ReplicaSet using httpd image with latest tag (ensure to specify as httpd:latest) and name it httpd-replicaset.

Apply labels: app as httpd_app, type as front-end.

Name the container httpd-container. Ensure the replica count is 4.

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

Solution

Kubernetes ReplicaSet — `httpd-replicaset`

A ReplicaSet maintaining 4 httpd:latest pods, labeled app: httpd_app and type: front-end. Applied inline via a heredoc — no manifest file on disk.

Apply (heredoc → kubectl)

kubectl apply -f - <<'EOF'
apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: httpd-replicaset
  labels:
    app: httpd_app
    type: front-end
spec:
  replicas: 4
  selector:
    matchLabels:
      app: httpd_app
      type: front-end
  template:
    metadata:
      labels:
        app: httpd_app
        type: front-end
    spec:
      containers:
        - name: httpd-container
          image: httpd:latest
EOF

How it works

The heredoc apply pattern

kubectl apply -f - reads from stdin; the heredoc feeds the YAML in, nothing on disk.
<<'EOF' (delimiter quoted) disables shell expansion, keeping $VAR/backticks literal — the right default for Kubernetes YAML.

The manifest, field by field

apiVersion: apps/v1 / kind: ReplicaSet — a ReplicaSet ensures a specified number of identical pod replicas are running at all times, recreating any that die. (In practice you'd usually use a Deployment, which manages ReplicaSets and adds rollouts — but the task asks for a bare ReplicaSet.)
metadata.name: httpd-replicaset — the RS name, exactly as required.
metadata.labels — app: httpd_app and type: front-end on the ReplicaSet object itself, as required.
spec.replicas: 4 — the desired pod count. The RS controller works continuously to keep exactly 4 matching pods running.
spec.selector.matchLabels — how the RS identifies the pods it owns. This must match the pod template's labels, or the API rejects the manifest with selector does not match template labels.
spec.template — the pod blueprint:
- template.metadata.labels — app: httpd_app, type: front-end stamped on every pod. These are what the selector targets.
- template.spec.containers — one container: name: httpd-container with image: httpd:latest (tag stated explicitly, as required).

Why the selector and template labels must agree

A ReplicaSet is decoupled from its pods and 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 RS couldn't recognize its own pods, so Kubernetes rejects the config outright. Both carry app: httpd_app + type: front-end to satisfy that contract.

Selector caution: because a ReplicaSet adopts any existing pod matching its selector, reusing labels that other pods already carry can cause it to adopt (or fight over) them. The two-label selector here is specific enough to avoid that in a clean environment.

Verify

# ReplicaSet exists with 4 ready replicas
kubectl get rs httpd-replicaset

# Pods are running and labeled
kubectl get pods -l app=httpd_app,type=front-end --show-labels

# Container image is correct
kubectl get rs httpd-replicaset \
  -o jsonpath='{.spec.template.spec.containers[0].image}{"\n"}'

Expected — httpd-replicaset showing DESIRED 4 / CURRENT 4 / READY 4, four pods Running with both labels, and the image printing httpd:latest.

If pods sit in ImagePullBackOff, the httpd:latest pull failed (node offline / rate-limited). kubectl describe pod <name> shows the pull events.

4.0 KiB Raw Blame History