Watch How an Application Actually Lives

This lab runs on a cluster where the application really runs

A real k3s is running inside a VM. The kubelet actually runs the probes, Jobs actually complete, and ConfigMaps are actually mounted.

In the fake cluster that the other labs in the CKAD course run on, none of this happens. Attach a probe and it does not run, create a Job and it does not complete.

The first startup takes about 2 minutes.

Goal

You confirm the three probes, Jobs and CronJobs, QoS, and configuration injection through behavior.

Why it matters

What people often get wrong in CKAD is not syntax but differences in behavior.

• Why startupProbe is needed is something you only learn by attaching a short liveness to an application that starts slowly. It dies before it is fully up and restarts, over and over forever.
• completions and parallelism are "how many times it must succeed" and "how many to run at the same time" respectively. If you mix them up, the Job never ends or runs more than necessary.
• If you inject a ConfigMap as a volume, the file is updated when the value changes, but if you inject it as an environment variable, you have to recreate the Pod.

Steps

Create everything in the ckad namespace.

1. slow-start — Attach both a short livenessProbe and a startupProbe to a container that takes about 20 seconds to start, and record in /root/ckad/startup.txt that it becomes ready without a restart.
2. Create the api Deployment (3 replicas) and a Service, but make only one Pod fail readiness, and record in /root/ckad/endpoints.txt that it drops out of the endpoints.
3. Record in /root/ckad/job.txt that the batch Job (completions: 3, with parallelism specified) actually completes.
4. Record in /root/ckad/backoff.txt that the doomed Job uses up its backoffLimit and becomes Failed.
5. Create the tick CronJob, let it actually run at least once, and record it in /root/ckad/cronjob.txt. Decide on concurrencyPolicy as well.
6. Create the three QoS classes with the three Pods qos-guaranteed, qos-burstable, and qos-besteffort, and record them in /root/ckad/qos.txt.
7. With cfg-pod, inject a ConfigMap as both a volume and an environment variable, and record in /root/ckad/config.txt how it looks inside the Pod.
8. In /root/ckad/report.md, write three lines, startup_restarts=, job_completions=, and evicted_first=, along with an explanation.

Notes

• Until the startupProbe succeeds, the livenessProbe and readinessProbe do not start. That is why it is used for applications that start slowly.
• Check a Job's status with kubectl -n ckad get job batch -o jsonpath='{.status}'.
• QoS is in kubectl get pod <이름> -o jsonpath='{.status.qosClass}' (the placeholder is the Pod name), and it is not set directly but determined by requests/limits.
• Write a CronJob's schedule like */1 * * * *. If it runs every minute, it runs at least once during the lab.
• Common mistake 1: attaching only a startupProbe and no livenessProbe. A startupProbe is a device that postpones liveness, so it is meaningless on its own.
• Common mistake 2: giving only requests to make QoS Guaranteed. requests and limits must be exactly equal for every resource.

When startup is slow

slow-start — Attach both a short livenessProbe and a startupProbe to a container that takes about 20 seconds to start, and record in /root/ckad/startup.txt that it becomes ready without a restart.

If you attach only a short liveness, it dies before it is fully up. The startupProbe postpones it.

A Pod that is not ready drops out

Create the api Deployment (3 replicas) and a Service, but make only one Pod fail readiness, and record in /root/ckad/endpoints.txt that it drops out of the endpoints.

Make readiness fail in only one of the three replicas, and look at the EndpointSlice.

completions and parallelism

Record in /root/ckad/job.txt that the batch Job (completions: 3, with parallelism specified) actually completes.

completions is how many times it must succeed, and parallelism is how many to run at the same time.

When does a Job give up

Record in /root/ckad/backoff.txt that the doomed Job uses up its backoffLimit and becomes Failed.

After retrying as many times as backoffLimit, the Failed condition is attached. Set it small so you do not have to wait.

When runs overlap

Create the tick CronJob, let it actually run at least once, and record it in /root/ckad/cronjob.txt. Decide on concurrencyPolicy as well.

Make it run every minute with */1 * * * * and wait for it to run at least once. Decide on concurrencyPolicy as well.

Who is evicted first when resources run short

Create the three QoS classes with the three Pods qos-guaranteed, qos-burstable, and qos-besteffort, and record them in /root/ckad/qos.txt.

QoS is not set directly but determined by the combination of requests/limits.

A volume and an environment variable are different

With cfg-pod, inject a ConfigMap as both a volume and an environment variable, and record in /root/ckad/config.txt how it looks inside the Pod.

Inject the same ConfigMap in two ways, and compare how it looks inside the Pod.

What you learned

In /root/ckad/report.md, write three lines, startup_restarts=, job_completions=, and evicted_first=, along with an explanation.

Write three lines, startup_restarts=, job_completions=, and evicted_first=, along with an explanation.