TT Lab
Get started
Learn Learning paths Courses

KCNA — Kubernetes and Cloud Native Associate

The deployment succeeded, so why is the new release missing?

Continue in TT Lab

Goal

On a real k3s, you distinguish declaration acceptance, rollout completion, readiness failure, manual rollback, and external configuration recovery, each with its own evidence.

Why it matters

The fact that a deployment command has finished does not let you say that the new version handles requests. A rolling update keeps the existing healthy replicas, so the service looks normal even if the new version fails. If you then fix liveness or delete all the Pods, you lose even the evidence of what failed. This lab leaves the healthy comparison group and the last healthy replicas, and injects only the designated readiness failure. This is a 50-minute lab. If needed, extend before it expires. When the session ends, the VM and files are reclaimed.

Prepared environment and helpers

In the kcna-delivery space of a personal VM there are a web Deployment with two replicas, the settings ConfigMap, the web Service, and a control Pod. The app image is pinned by digest and uses non-root, cap drop ALL, RuntimeDefault, a read-only root, and the ServiceAccount token not mounted. v1, v2, and v3 are synthetic app versions that distinguish behavior from the same image. It is not an experiment that builds a new image or changes a real CI or GitOps. Do not change the nodes, the healthy comparison group, or the rollout protection settings, and do not bring in a production kubeconfig or secrets. Keep all student files under /root/kcna-delivery. You write the input JSON yourself, and the real observation JSON is made by capture. Add act, capture, grade, or prepare and a step number 1–8 after python3 /opt/fixtures/kcna_delivery_lab.py. observe reads the current API and HTTP responses. grade does not change files or objects. act leaves a record of the completed operation in /opt/fixtures/kcna-delivery-action-N.json. Do not fabricate the UIDs, responses, or completion status in the files.

Steps

  1. Save /root/kcna-delivery/baseline.json with capture 1. Investigate the two healthy Pods that are v1 and blue, the Deployment, ReplicaSet, and Pod UIDs, the container IDs and restart counts, Ready, the EndpointSlice, and the Service responses. The control Pod is an independent healthy comparison group.
  2. Save the string note=reviewed in annotation.json and make metadata_only.json with act 2 and capture 2. Only the Deployment object's annotation changes, and the original ReplicaSet, Pods, containers, and revision must be kept. Refute the hypothesis that an object change means a new process.
  3. Save the string color=green in config-green.json and make config_only.json with act 3 and capture 3. The value of the ConfigMap settings is green, but the running COLOR of the existing Pods and the Service is blue. Distinguish the time the environment variable was consumed from the value stored in the API.
  4. Save the string release=v2 and the boolean ready=true in release-v2.json. Make v2_complete.json with act 4 and capture 4. The new ReplicaSet and two Pods must respond as v2 and green, with updatedReplicas=2. Leave the healthy revision number in this observation.
  5. Save the string release=v3, the boolean ready=false, and the string color=purple in release-v3.json. Make v3_unready.json with act 5 and capture 5. v3 is Running but not Ready and gives a direct HTTP 503. The existing two v2 and green Pods remain with the same UIDs and containers, and the Service must deliver to these healthy replicas.
  6. With no additional change, save deadline_exceeded.json with capture 6. Check the actual Progressing=False and ProgressDeadlineExceeded and the desired template that is still v3. It is not a liveness restart or an automatic rollback but the progress failure of a new version that does not become ready. The 20-second criterion of this experiment is not a production recommendation.
  7. Investigate the deployment.kubernetes.io/revision of the Deployment saved in v2_complete.json and write it as a string in the revision of rollback.json. Make rolled_back.json with act 7 and capture 7. Compare the completion record of the actual rollout undo command, the preserved original v2 Pods, the increased revision, and the external ConfigMap that is still purple.
  8. Save the string color=green in restore-green.json and make config_restored.json with act 8 and capture 8. Recover the external configuration separately as well, and check the v2 and green responses and the preservation of the original healthy Pods and the comparison group. Explain with the earlier records why a Deployment rollback and external configuration recovery are different operations.

Notes

Expressions such as note=reviewed in the task are explanations of fields and values. Write the files as valid JSON, as in the format examples. true and false are booleans without quotes. revision is a string and must be read from the healthy v2 observation. capture waits for the actual condition to converge. The six Service responses are a sample for learning, not a long-term availability guarantee. Preserve completed observations and inputs. prepare fills only the earlier steps that are missing and does not overwrite the current step's answers or existing wrong answers. If the records are interrupted midway, it does not reset automatically. In particular, when the rollback completion record is gone, do not reconstruct a past success on the grounds that the current state is v2. In that case, keep the files you need and start a new lab. No command is provided to reset all history on the same VM. Grading has a 60-second budget and step preparation a 90-second budget. The deadline waits for normal startup or readiness failure are done in capture. The record hash is for detecting accidental file changes and is not a remote attestation or security guarantee against the VM's root. Official sources: Deployment · ConfigMap.

Declaration and execution evidence of the healthy version

Save /root/kcna-delivery/baseline.json with capture 1. Investigate the two healthy Pods that are v1 and blue, the Deployment, ReplicaSet, and Pod UIDs, the container IDs and restart counts, Ready, the EndpointSlice, and the Service responses. The control Pod is an independent healthy comparison group.

Keep the UID and the container ID, not only the name.

An object annotation is not a rollout

Save the string note=reviewed in annotation.json and make metadata_only.json with act 2 and capture 2. Only the Deployment object's annotation changes, and the original ReplicaSet, Pods, containers, and revision must be kept. Refute the hypothesis that an object change means a new process.

Distinguish whether the change location is metadata or spec.template.

A configuration change and the running environment variable

Save the string color=green in config-green.json and make config_only.json with act 3 and capture 3. The value of the ConfigMap settings is green, but the running COLOR of the existing Pods and the Service is blue. Distinguish the time the environment variable was consumed from the value stored in the API.

The value stored in the ConfigMap and the existing process's environment variable do not change at the same moment.

Evidence that the new template was actually deployed

Save the string release=v2 and the boolean ready=true in release-v2.json. Make v2_complete.json with act 4 and capture 4. The new ReplicaSet and two Pods must respond as v2 and green, with updatedReplicas=2. Leave the healthy revision number in this observation.

availableReplicas may be the old version. Look at updatedReplicas and the response version together.

The new version is alive but not ready

Save the string release=v3, the boolean ready=false, and the string color=purple in release-v3.json. Make v3_unready.json with act 5 and capture 5. v3 is Running but not Ready and gives a direct HTTP 503. The existing two v2 and green Pods remain with the same UIDs and containers, and the Service must deliver to these healthy replicas.

Running, Ready, the HTTP response, and Service delivery are different observations.

Exceeding the progress deadline is not an automatic rollback

With no additional change, save deadline_exceeded.json with capture 6. Check the actual Progressing=False and ProgressDeadlineExceeded and the desired template that is still v3. It is not a liveness restart or an automatic rollback but the progress failure of a new version that does not become ready. The 20-second criterion of this experiment is not a production recommendation.

Check the status and reason of the Progressing condition, and whether the desired template is unchanged.

Manual rollback to the investigated revision

Investigate the deployment.kubernetes.io/revision of the Deployment saved in v2_complete.json and write it as a string in the revision of rollback.json. Make rolled_back.json with act 7 and capture 7. Compare the completion record of the actual rollout undo command, the preserved original v2 Pods, the increased revision, and the external ConfigMap that is still purple.

Do not memorize the revision number. A rollback does not roll back the external ConfigMap.

Recover the external configuration separately as well

Save the string color=green in restore-green.json and make config_restored.json with act 8 and capture 8. Recover the external configuration separately as well, and check the v2 and green responses and the preservation of the original healthy Pods and the comparison group. Explain with the earlier records why a Deployment rollback and external configuration recovery are different operations.

Do not look only at the healthy response; check the configuration the next Pod will read too.