← CKAD: Kubernetes applications in production
08 / 9 · 60 MIN

Workload, configuration and capacity workshop

Read manifests, connect producers to consumers and prepare rollouts with consistent resources and configuration.

1. Start with the execution contract

A fictional funds team prepares an API and a reconciliation batch. The API provides an ongoing service; the batch finishes after producing results. A Job requesting six completions and parallelism of two promises neither six simultaneous executions nor absence of retries. Write the application success condition and how completed work is recognized. For finite preparation, a regular init container must finish. An endless watcher placed in that init prevents application startup. Identify this condition before increasing replicas or investigating probes for a process that has not started.

2. Connect the file to its consumer

The init writes settings.json under /out mounted from volume prepared. The application reads /config/settings.json. The same volume must be mounted at /config in the consumer container; sharing a Pod does not share all image directories. In the exercise, draw the volume, producer mountPath and consumer mountPath before correcting the manifest. Also choose durability: emptyDir suits temporary Pod data. With medium: Memory, tmpfs files add memory usage to the writing container. A large cache can compete with process memory, so observing heap alone is insufficient.

3. Distinguish configuration delivery and adoption

A new object does not mean consumers already use it. With configMapKeyRef, a process receives the value at startup; changing the ConfigMap does not rewrite the existing environment. A normal volume may receive later projections, while subPath does not automatically track updates. Even an updated file must be read by the application. For immutable rules-v1, prepare rules-v2, update the template reference and validate new Pod behavior. Retain the previous version while recovery needs it. In the tabletop exercise, separately mark object creation, reference change, Pod replacement and verified function.

4. Locate the template and interpret rollout

Labels on the Deployment object and labels under spec.template.metadata belong to different levels. A Service selects Pods; an external label does not automatically change them. Scaling replicas alone also creates no template revision. For three replicas and 25% limits, maxSurge rounds to one and maxUnavailable to zero. This is a strategy rule, not a capacity or recovery-time guarantee. ProgressDeadlineExceeded reports stalled progress; without additional automation, rollback cannot be declared complete. Preserve earlier events because they may show the initial blocking cause.

5. Calculate quota and review identity

With a 3Gi requests.memory quota, accounted usage of 2560Mi and a new 768Mi request, total usage is 3328Mi. Since 3Gi equals 3072Mi, accounted capacity is short by 256Mi. Do not confuse admission rejection with insufficient physical memory on a node. In another failure, /shared belongs to UID 0 and group 2000 with mode 0770; a UID 10001 process belonging only to group 3000 lacks permission in this model. Review identity, groups, mode and volume support before removing controls. fsGroup depends on volume type and driver; do not treat it as a universal fix. In v1.37, emptyDir.mode is an alpha feature, disabled by default and dependent on EmptyDirVolumeMode. These exercises do not use it: reason from the observed owner, groups and permissions, and check volume support before proposing fsGroup.

6. Deliver a verifiable RUN plan

Finish the workshop with a reviewed manifest, assumptions and acceptance criteria. The team should know which configuration each consumer uses, resources needed during surge and what happens if a new Pod never becomes ready. Syntactic validity proves neither admission, scheduling nor business success. These lesson examples were compared with v1.37 documentation while retaining each exercise’s explicit conditions. Inspection commands provide a route through an authorized laboratory and were not executed against a cluster in this review. Record those boundaries at handover.

# Fragment: Deployment spec.template.spec.containers[0]
env:
 - name: RULESET
 valueFrom:
 configMapKeyRef:
 name: rules-v2
 key: ruleset

# Read-only inspection plan for an authorized lab
kubectl get deployment reconcile-api -n funds -o yaml
kubectl describe deployment reconcile-api -n funds
kubectl get resourcequota -n funds
IN PRACTICE

In the 4Gi case, 3584Mi + 768Mi = 4352Mi exceeds 4096Mi by 256Mi. The progress deadline does not create that capacity.

Common pitfalls

Created ConfigMap as consumed; external label as template; timeout as rollback; quota as instantaneous usage; permissions as a memory issue.

Related topics: Deployments and recovery · Services and network policies

Take this idea with you

Connect lifecycle, configuration, identity and capacity before declaring rollout complete.

Create account

Reference: Deployments · CKAD Kubernetes v1.37

Kubernetes® and CKAD are trademarks or registered trademarks of The Linux Foundation. bigsavant.com is an independent preparation platform and is not affiliated with, associated with, sponsored, authorised or endorsed by The Linux Foundation. Content and questions are original, are not official exam questions, and completing our tests does not award or guarantee any certification. Names are used only to identify the subject. All other trademarks belong to their respective owners.