CKAD: Certified Kubernetes Application Developer

The CKAD Exam Focus

The Certified Kubernetes Application Developer (CKAD) exam tests your ability to design, build, configure, and troubleshoot cloud-native applications running on Kubernetes.

Similar to the CKA, the CKAD is a practical, hands-on, terminal-based exam lasting 2 hours.

CKAD Exam Domains

1. Application Design and Build (20%)

- Define multi-container pod patterns (sidecar, adapter, ambassador)

- Utilize Jobs and CronJobs for automated processing

1. Application Deployment (20%)

- Understand deployment strategies (rolling updates, canary, blue-green)

- Perform helm chart deployments and troubleshooting

1. Application Environment, Security and Configuration (25%)

- Define resource requests and limits

- Configure ConfigMaps and Secrets to inject configurations

- Build SecurityContext settings (runAsUser, readOnlyRootFilesystem)

1. Application Observability and Maintenance (18%)

- Implement Liveness, Readiness, and Startup probes

- Query container logs, monitor CPU/memory usage

1. Services and Networking (17%)

- Setup NetworkPolicies, expose applications using ClusterIP, NodePort, and Ingress routing

Visualizing Multi-Container Pod Patterns

All containers in a Pod share the same network namespace (IP, ports, loopback) and IPC namespace. Volumes can also be shared to bridge distinct storage contexts:

+-------------------------------------------------------------------------------+
| Pod Sandbox Namespace Boundaries                                              |
|                                                                               |
|   +--------------------------+                 +--------------------------+   |
|   |     Main Application     |                 |  Helper/Sidecar/Adapter  |   |
|   |   (e.g., Node.js app)    |                 |   (e.g., Log Forwarder)  |   |
|   |   Port: 3000             |                 |   Tails app.log          |   |
|   +------------+-------------+                 +------------+-------------+   |
|                |                                            |                 |
|                | writes logs                                | reads logs      |
|                v                                            v                 |
|   +------------+--------------------------------------------+------------+   |
|   |                      Shared volume (emptyDir)                         |   |
|   +-----------------------------------------------------------------------+   |
|                                                                               |
|   Note: Both containers bind to 'localhost' and communicate over IPC.          |
+-------------------------------------------------------------------------------+

Visualizing Pod Init & Execution Lifecycle

Init Containers run sequentially to completion before any application containers begin execution:

Pod Scheduled
      │
      ▼
[ Init Container 1 ] ──(Succeeds)──> [ Init Container 2 ] ──(Succeeds)──> [ App Containers & Sidecars ]
      │                                    │                                 │
  (Failure)                            (Failure)                             ▼
      │                                    │                      Kubelet runs Probes:
      v                                    v                      1. Startup Probes
 [ Restart Pod ]                      [ Restart Pod ]             2. Liveness Probes
                                                                  3. Readiness Probes

CKAD Deep-Dive: Multi-Container Patterns, Resource Allocation, and Probes

#### 1. Linux Namespace Sharing & The Infra (Pause) Container

When the Kubelet schedules a Pod, the CRI runtime first deploys a special helper container called the Infra Container (or Pause Container).

• Namespace Isolation: The Pause container's sole job is to hold the namespaces open (Network, IPC, and optionally PID namespaces).
• Shared Network: All subsequently created container processes join the Network namespace of the Pause container via system calls (like setns). This enables containers inside the same Pod to connect via localhost (e.g. an application container communicating with a database ambassador proxy on localhost:5432).
• Volume Mounts: Filesystem layers remain isolated unless sharing paths through K8s volumes (such as an emptyDir mapped to /var/log in container A, and /app/logs in container B).

#### 2. Advanced Multi-Container Pod Design Patterns

• Sidecar Pattern: Extends the main container without changing its source code. For example, a Cloud SQL proxy sidecar allows the main app to talk to a local port while managing TLS and auth to GCP.
• Adapter Pattern: Acts as a translation layer. It transforms heterogeneous outputs from the main application (e.g. custom key-value diagnostic output) into standard formatted endpoints (e.g., Prometheus metrics) so monitoring servers can scrap them uniformly.
• Ambassador Pattern: Connects the main application container to remote external services. The application talks to a static local address, while the ambassador container dynamic-routes requests to external test, staging, or sharded database clusters.

#### 3. Resource Scheduling, Limits, & cgroups v2 Mechanisms

Kubernetes enforces resource policies utilizing Linux Control Groups (cgroups):

• CPU Requests: Translated into cpu.shares (cpu.weight in cgroups v2). This acts as a relative priority weight. If CPU cycles are contested, the CPU scheduler allocates shares proportionally.
• CPU Limits: Enforced using CFS (Completely Fair Scheduler) Bandwidth Control. The limit is converted into quota (cpu.cfs_quota_us) over a period (cpu.cfs_period_us). If a container exceeds its CPU limit, the kernel throttles the container, causing slow response times but not termination.
• Memory Limits: Mapped to memory.max in cgroups v2. Because memory is incompressible, if a container requests more physical memory than its limit, the kernel triggers an Out-Of-Memory (OOM) event. The Linux kernel OOM-killer selects the process for immediate termination, and Kubelet records exit code 137 (128 + SIGKILL).

#### 4. Kubelet Health Probes & Lifecycle Loop

Probes are run periodically by the Kubelet's probe manager.

• Startup Probes: Runs first. Suspends all Liveness and Readiness probes until it succeeds or times out. Ideal for applications with long initialization cycles.
• Liveness Probes: Determines if a container needs to be restarted. If it fails, the Kubelet kills the container and invokes the Pod's restartPolicy.
• Readiness Probes: Determines if a container can serve network traffic. If a readiness probe fails, the Kubelet stops sending its status as Ready, causing the EndpointSlice controller to extract the Pod's IP from the Endpoints list of matching Services, preventing user requests from reaching the unhealthy pod.

Vim & Shell Productivity Tips

• Vim auto-indent: Set up standard auto-indents to prevent spaces errors:

set expandtab ts=2 sw=2

• Delete multiple lines: Go to first line, type dG to delete to bottom, or d5d to delete 5 lines.
• Explain CLI documentation: Use kubectl explain pods.spec.containers.securityContext to check API fields inside the terminal.