CKA: Certified Kubernetes Administrator

The CKA Exam Format

The Certified Kubernetes Administrator (CKA) is a highly respected, 100% practical, hands-on exam containing 15-20 scenarios to solve in 2 hours.

You will be given multiple cluster contexts and terminal access to solve real-world system administration problems.

CKA Exam Domains

1. Troubleshooting (30%)

- Diagnose node failures (kubelet crash, docker down, systemd faults)

- Diagnose networking issues (CNI issues, CoreDNS failures)

- Fix failing applications (logs, describe, crash loops)

1. Cluster Architecture, Installation & Configuration (25%)

- Upgrade control plane and worker nodes with kubeadm

- Back up and restore the etcd database

- Securely manage RBAC (ServiceAccounts, Roles, RoleBindings, ClusterRoles)

1. Services & Networking (20%)

- Config Ingress routes, Services, DNS names, and CNI configurations

- Set up NetworkPolicies to isolate namespace traffic

1. Workloads & Scheduling (15%)

- Configure Deployments, replica scaling, rolling updates

- Use NodeSelectors, Affinity rules, Taints and Tolerations

1. Storage (10%)

- Provision PVs, PVCs, StorageClasses, and configure pod volumes

Visualizing Node Health & Diagnostics Flow

The Kubelet continuously checks underlying subsystems. If any health boundary is breached, the lease update reflects pressure conditions or a flat 'NotReady' status:

+-----------------------------------------------------------------+
|                       Kubelet Node Agent                        |
+--------+--------------------+------------------+--------+--------+
         |                    |                  |        |
         v                    v                  v        v
  [ CRI Socket Ping ]   [ Eviction Manager ]  [ systemd ] [ Lease API ]
  - Is containerd active? - Memory Pressure    - Active?   - Every 10s
  - OCI runc responsive?  - Disk Pressure      - Configs?  - Keep-alive
  - gRPC ping OK?         - PID Pressure       - Logs OK?  - Heartbeat

Visualizing etcd Backup and Restore Mechanics

Because etcd is the single source of truth for cluster state, operations must use authentic client certificates:

Backup Phase:
[ Admin CLI ] ---> (etcdctl snapshot save --cacert=... --cert=... --key=...) ---> [ Port 2379 ] ---> [ etcd DB ] ---> Writes [ snapshot.db ]

Restore Phase:
1. Stop API server (Move /etc/kubernetes/manifests/* to safety)
2. Run restore command:
   [ etcdctl snapshot restore /srv/data/etcd-snapshot.db --data-dir=/var/lib/etcd-new ]
3. Update etcd static pod manifest to point to the new data-dir
4. Restore API server manifest to resume control plane loop

CKA Deep-Dive: Node Troubleshooting, etcd, & Networking Internals

#### 1. Node Ready Diagnostics & Kubelet Eviction Manager

A node's transition to NotReady is orchestrated by the Kubelet Eviction Manager. The Kubelet monitors system resource thresholds against configured eviction parameters (e.g., memory.available < 100Mi, nodefs.available < 10%). If a threshold is breached, the Kubelet:

1. Sets Node Conditions (e.g., MemoryPressure = True, DiskPressure = True).
2. Rejects incoming Pods and schedules active Pods for eviction according to QoS class priority (BestEffort → Burstable → Guaranteed).
3. Transmits heartbeat leases to the API server in the kube-node-lease namespace every 10 seconds. If the Kubelet crashes or loses connection to the container runtime, these heartbeat leases time out, causing the kube-controller-manager's Node LifeCycle Controller mark the node as NotReady or Unknown.

#### 2. Kubelet Swap Space Restrictions

Historically, the Kubelet required disabling swap space on host nodes (swapoff -a).

• Resource Predictability: The Kubernetes scheduler selects nodes based on available CPU/memory requests. If a node swaps memory to disk, the OS scheduler bypasses the limits. A container could exceed memory request/limits without being terminated, leading to node performance degradation.
• Cgroups Isolation: Linux Control Groups (cgroups v1) did not natively separate swap space allocation per-container. Under cgroups v2, swap limits can be configured, allowing modern Kubernetes releases (v1.28+) to support swap space with explicit failSwapOn: false configuration, although disabling swap remains the safest path for CKA exam consistency.

#### 3. etcd Raft Consensus & PKI Maintenance

The etcd datastore uses the Raft consensus algorithm to ensure state consistency across control plane members. Raft requires a majority quorum ($Q = lfloor N/2 floor + 1$) to validate state changes and write transactions.

• Ports: etcd listens on port 2379 for client requests (from the API server) and port 2380 for peer-to-peer raft synchronization.
• TLS Authentication: etcd is secured with mutual TLS (mTLS). Admin actions require pointing etcdctl to the certificate authority (ca.crt), client certificate (server.crt or peer.crt), and client key (server.key).
• Restoration Mechanics: To perform a clean etcd restore, you must halt all write traffic. In a standard kubeadm cluster, moving static pod manifests out of /etc/kubernetes/manifests causes the Kubelet to terminate the local kube-apiserver and etcd pods. You can then run etcdctl snapshot restore into a fresh directory, update the etcd manifest path, and restore the control plane.

#### 4. NetworkPolicies: Under-the-Hood Implementation

NetworkPolicies are declarative rules targeting Pod groups. Kubernetes does not enforce NetworkPolicies itself; it delegates enforcement to the installed CNI (Container Network Interface) plugin.

• iptables Engine: Plugins like Calico convert NetworkPolicy selectors into Linux iptables chains and rules, utilizing ipset for matching multiple pod IPs dynamically without scaling latency.
• eBPF Engine: Modern CNIs like Cilium compile rules directly into eBPF (Extended Berkeley Packet Filter) bytecodes, attaching them directly to the veth interfaces of the containers. This avoids iptables packet routing overhead and yields near-native throughput.

High-Speed Imperative Commands Cheat Sheet

Time is your primary enemy in the CKA. NEVER write YAML from scratch. Use imperative commands to generate blueprints:

• Create a Deployment:

kubectl create deployment my-dep --image=nginx:alpine --replicas=3 --dry-run=client -o yaml > dep.yaml

• Expose a Pod/Deployment:

kubectl expose deployment my-dep --port=80 --target-port=80 --type=ClusterIP --name=my-svc --dry-run=client -o yaml > svc.yaml

• Set Up a Quick Role:

kubectl create role my-role --verb=get,list,watch --resource=pods,deployments --dry-run=client -o yaml

• Temporary debug container:

kubectl run debug-pod --image=busybox --restart=Never --rm -it -- sh

CKA Vim Tuning

Add these lines to your ~/.vimrc immediately at the start of the exam to speed up editing YAML files:

set ts=2 sw=2 expandtab
syntax on
set number