Stage 7 · Master

CKAD — Certified Kubernetes Application Developer

Observability & Maintenance (15%)

Probes, logging, debugging, and API deprecations — seeing and fixing application issues.

8 min readExams & CertificationsMaster

Health Probes

Health probes tell Kubernetes whether your application is running, ready, and healthy. Proper probe configuration is critical for zero-downtime deployments and self-healing.

Probe	Purpose	Failure Action
livenessProbe	Is the container alive?	Restart the container
readinessProbe	Is the container ready for traffic?	Remove from Service endpoints
startupProbe	Has the container finished starting?	Block other probes until success

Probe configuration


spec:
  containers:
  - name: app
    image: my-app
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
      initialDelaySeconds: 15
      periodSeconds: 10
      failureThreshold: 3
    readinessProbe:
      httpGet:
        path: /ready
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 5
    startupProbe:
      httpGet:
        path: /healthz
        port: 8080
      failureThreshold: 30
      periodSeconds: 10

startupProbe runs first. Until it succeeds, liveness and readiness probes are disabled. This prevents slow-starting containers from being killed prematurely.

Probe timing strategy

Set initialDelaySeconds high enough for your application to start. Set periodSeconds low enough to detect failures quickly. Set failureThreshold high enough to avoid false positives. For startupProbe, set failureThreshold high to allow slow startups.

Application Logging

Kubernetes expects applications to log to stdout and stderr. The kubelet captures these logs and stores them on the node. Use kubectl logs to access container logs.

Log commands


# View logs
kubectl logs my-pod
kubectl logs my-pod --tail=100
kubectl logs my-pod --since=1h
kubectl logs my-pod -f              # Follow logs

# Previous container logs (after restart)
kubectl logs my-pod --previous

# Multi-container Pod logs
kubectl logs my-pod -c my-container

# All containers in a Pod
kubectl logs my-pod --all-containers=true

# Logs from a selector
kubectl logs -l app=my-app --all-containers=true

The --previous flag shows logs from a crashed container. The -c flag selects a specific container. The --all-containers flag shows logs from all containers in a Pod.

Debugging Applications

When a Pod is not working correctly, systematic debugging helps you find the root cause. Start with Pod status, then check events, logs, and configuration.

Debugging workflow


# Step 1: Check pod status
kubectl get pods
kubectl describe pod my-pod

# Step 2: Check events
kubectl get events --field-selector involvedObject.name=my-pod --sort-by=.lastTimestamp

# Step 3: Check logs
kubectl logs my-pod --previous

# Step 4: Debug with exec
kubectl exec -it my-pod -- /bin/sh

# Step 5: Debug with ephemeral container
kubectl debug my-pod -it --image=busybox

# Step 6: Check resource usage
kubectl top pod my-pod

The kubectl debug command creates an ephemeral container in the Pod for debugging. This is useful when the main container does not have a shell or debugging tools.

API Deprecations

Kubernetes deprecates APIs over time. The CKAD tests your knowledge of which API versions are current and which are deprecated. Always use the latest stable API version.

Resource	Deprecated	Current
Deployment	extensions/v1beta1, apps/v1beta1	apps/v1
DaemonSet	extensions/v1beta1	apps/v1
StatefulSet	apps/v1beta1	apps/v1
NetworkPolicy	extensions/v1beta1	networking.k8s.io/v1
Ingress	extensions/v1beta1	networking.k8s.io/v1

Use current API versions

On the CKAD exam, always use the latest stable API version. Using deprecated versions may work but will eventually break. Check kubectl api-resources to see available versions.

Resource Monitoring

Resource monitoring commands


# Check resource usage
kubectl top pods
kubectl top nodes

# Check resource quotas
kubectl describe resourcequota -n my-namespace

# Check limit ranges
kubectl describe limitrange -n my-namespace

# Check node capacity
kubectl describe node my-node | grep -A 5 "Allocated resources"

The kubectl top commands require Metrics Server. If Metrics Server is not installed, use kubectl describe node to see allocated resources.

Key Commands

Observability commands


kubectl logs my-pod --previous
kubectl logs my-pod -c my-container
kubectl exec -it my-pod -- /bin/sh
kubectl debug my-pod -it --image=busybox
kubectl get events --sort-by=.lastTimestamp
kubectl top pods
kubectl top nodes
kubectl api-resources
kubectl api-versions

These commands are your toolkit for debugging and observability. Practice them until they are automatic.

Mark this lesson complete to store local progress and unlock a cleaner resume path the next time you visit.