How do I get the CKA?

What is this certification?

#

The Certified Kubernetes Administrator (CKA) is a Kubernetes certification that focuses primarily on the administration and configuration of a cluster, as well as all the components required to make services accessible from the outside, manage persistent storage, and other areas that will be discussed below.

It consists of 15 to 20 questions of varying lengths and weighting, usually indicated as a percentage. These questions must be completed in less than two hours.

In my case, I had 17 questions, the majority of which were of medium difficulty, though a few were a bit tricky. In terms of timing, I had a good thirty minutes left before the exam ended.

The aim of this article is to outline the exam content by covering the topics involved and to share all the tips and insights that enabled me to pass it, as well as to renew my certification twice.

Domains evaluated

#

The Cloud Native Computing Foundation (CNCF), who is in charge of the certification programme, has open-sourced all the curricula in a GitHub repository.

The latest syllabus, v1.35, includes:

• Cluster Architecture, Installation & Configuration (25%): One of the largest sections of the exam, focusing primarily on using kubeadm to add a node or update a cluster (Control Plane and Workers). This also covers everything related to initialising a cluster, including setting up a CNI (Container Network Interface), CSI (Container Storage Interface) or CRI (Container Runtime Interface) such as Containerd. This also includes managing role-based security with RBAC, cluster high availability (HA), as well as backing up and restoring the critical etcd database.

• Workloads & Scheduling (15%): Setting up Deployments or StatefulSets, and managing the scheduling of Pods on specific nodes by adjusting taints, tolerations, affinity (node and Pod), nodeSelector, as well as defining resources (requests and limits), not forgetting the configuration of applications via ConfigMaps and Secrets. An interesting new feature: the addition of the HorizontalPodAutoscaler (HPA) for automatic scaling.

• Services & Networking (20%): This section assesses your ability to expose your applications and secure their communication flows. It focuses on creating and configuring different types of Service (ClusterIP, NodePort, LoadBalancer), setting up HTTP/HTTPS application routing rules via Ingress (and its controller), as well as configuring network isolation using NetworkPolicy (ingress/egress). Gateway and HTTPRoute are introduced in the exam to complement the Ingress already mentioned.

• Storage (10%): Managing persistent data in Kubernetes – a short section, but one that should not be overlooked. Topics covered include creating PersistentVolumes (PVs) and PersistentVolumeClaims (PVCs), creating and deploying storage configurations using StorageClasses, and knowing how to correctly configure volumes within Pods.

• Troubleshooting (30%): The section carrying the most weight in terms of marks, requiring a methodology for diagnosing and repairing a failed cluster. This involves knowing how to debug a failing system component (such as the API Server, the Scheduler or the Controller Manager), restarting or configuring a crashed kubelet on a node, analysing container logs, assessing connectivity outages (Pods/Services) and monitoring cluster resource utilisation (CPU/Memory), etc.

As you can see, the CKA focuses largely on cluster administration and troubleshooting configuration issues.

Furthermore, knowledge of Linux is a big advantage, particularly when it comes to being comfortable installing packages on Ubuntu (apt-get or dpkg) or using kubeadm via the command line.

As you might have guessed, Ubuntu 24.04 LTS is the reference operating system and kubeadm is the official distribution for the exam.

It is important to bear in mind, however, that the creation of basic objects (Pod, Service, etc.) is required for this certification.

Is it still worth it?

#

Having now gained several years’ experience in the Kubernetes world and the CNCF ecosystem, I found myself wondering whether to renew it for a second time.

Apart from losing my prestigious Kubestronaut title, yes indeed! It’s a fair question… In fact, I no longer really work with pure YAML or run kubectl commands anymore, as GitOps has gained a lot of ground.

Nevertheless, in my view, it’s always good to stay up to date with the basics of Kubernetes. And with good reason: the certification has come a long way compared to the first version I took four years ago.

For me, it’s a sort of technology watch to stay familiar with the basic concepts, but perhaps also to discover or experiment with new ones?

The example is the “real” sidecar container, something I haven’t yet had the chance to try out in a production environment. I’ve been able to get to grips with it through several labs, helping me understand both its benefits and its limitations.

What’s more, some scenarios are quite close to reality: even though my personal and professional Kubernetes clusters aren’t running on Ubuntu or kubeadm, understanding how to troubleshoot and having the right reflexes can always help.

Another example: the migration from Ingress to HTTPRoute; the Gateway API is gaining momentum, and it really shows. A good way to raise awareness of how easy migration is.

As you can see, to me, it’s a definite yes! These practical exams offer real added value that is undeniable in roles where you get your hands dirty.

CKA before the CKAD?

#

Many people ask themselves: should I take the CKA or the CKAD first?

As far as I’m concerned, the choice is clear: it’s better to start with the CKAD.

Why? Quite simply because the CKAD (Certified Kubernetes Application Developer) focuses primarily on creating and managing objects within an existing cluster.

It is much more accessible and easier to grasp at first glance. Basically, if the CKAD teaches you how to drive the car, the CKA requires you to open the bonnet to repair the engine. The CKA covers a large part of the concepts in the CKAD, but adds the entire layer of pure administration: cluster installation, node management, network troubleshooting and system component maintenance.

Nevertheless, the advantage of starting with the CKA is that once you’ve passed it, the CKAD will be a mere formality. It is therefore entirely possible for more experienced candidates—those who already have solid experience with Kubernetes and its ecosystem—to attempt the CKA first.

It is up to each individual to decide how to approach things based on their own profile.

Now let’s look at the resources needed to pass this certification.

Resources used

#

To learn and cover all areas of the CKA, I recommend Mumshad Mannambeth’s Udemy course. It comes with interactive labs on his KodeKloud platform, allowing you to practise each chapter straight away. I recommend doing the labs over and over again: this is where you’ll start to memorise the kubectl commands and learn how to diagnose problems.

Once you’ve completed this course and purchased your certification on the Linux Foundation website, you’ll be entitled to two free attempts at the killer.sh simulator.

It is known to be much more difficult, longer and more stressful than the final exam (expect around 20 very dense questions).

If you manage to score over 66% on your own, you can feel really confident about your exam.

However, don’t panic if you fail your first attempt; each killer.sh session remains active for 36 hours from the moment it starts.

Once your session is over and your score has been assessed, make the most of the remaining time: study the detailed answers provided by the site, then do and redo the exercises given via the simulator to work on your weak points and improve your speed.

Topics to be aware of

#

This section contains links to the official documentation, essential commands and best practices to follow to make the most of your time on exam day.

To complement these tips, I strongly recommend reading the article on the CKAD, as much of the basic information is not repeated here.

A golden rule before touching the cluster configuration: always make a back up the original files. A mistake involving a critical component can quickly block or break the entire environment.

Example of the kubelet:

cp /etc/default/kubelet ~/kubelet.bak
# Or for the configuration file
cp /var/lib/kubelet/config.yaml ~/kubelet-config.yaml.bak

Updating a cluster with Kubeadm

#

This is the main part of the exam – there’s no getting round it!

You need to update the Control Plane and then the Workers, one by one. The documentation details each step.

For this step, two Linux commands will be a huge help:

• apt-cache madison: This lists all exact versions of a package available in the repositories. It is a reliable way to obtain the precise version tag (such as 1.35.0-1.1) required by the apt-get install command;

• apt-mark hold / unhold: For security reasons, it is preferable to block Kubernetes versions so that they are not included in system updates; this is what hold does. As for unhold, it allows the package to be updated.

On the Control Plane node:

# Unhold packages for the update
apt-mark unhold kubeadm

# Find the exact version of the package available (e.g. 1.35.0-1.1)
apt-cache madison kubeadm | grep 1.35

# Update kubeadm with the selected version
apt-get update
apt-get install -y kubeadm=1.35.0-1.1

# Check the upgrade plan and apply it
kubeadm upgrade plan
kubeadm upgrade apply v1.35.0

# Update kubectl and kubelet
apt-mark unhold kubelet kubectl
apt-get install -y kubelet=1.35.0-1.1 kubectl=1.35.0-1.1
apt-mark hold kubeadm kubelet kubectl

# Restart the kubelet
systemctl daemon-reload
systemctl restart kubelet

On the Worker nodes:

# From the Control Plane, drain the node
kubectl drain node01 --ignore-daemonsets --delete-emptydir-data

# On the worker (node01), update kubeadm and launch the upgrade
apt-mark unhold kubeadm
apt-get update
apt-get install -y kubeadm=1.35.0-1.1
kubeadm upgrade node

# Update the kubelet and restart
apt-mark unhold kubelet
apt-get install -y kubelet=1.35.0-1.1
apt-mark hold kubeadm kubelet
systemctl daemon-reload
systemctl restart kubelet

# From the control plane, make the node available again
kubectl uncordon node01

Backing up and restoring etcd

#

Etcd, the cluster’s database, is a critical component of the Kubernetes infrastructure. A number of commands can be executed using etcdctl. In the CKA, the focus is primarily on backing up or restoring data.

The documentation provides the exact arguments. The first step is to retrieve the path to the certificates and the etcd port from /etc/kubernetes/manifests/kube-apiserver.yaml.

Once you have this information, to take a snapshot:

ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key \
  snapshot save /tmp/etcd-backup.db # Or the requested path...

Another point: restoration. This is often carried out in a separate folder so as not to overwrite the existing data in the event of an error:

ETCDCTL_API=3 etcdctl --data-dir=/var/lib/etcd-backup \
  snapshot restore /tmp/etcd-backup.db

Next, edit the --data-dir setting and the associated hostPath volume in /etc/kubernetes/manifests/etcd.yaml. This will cause the kubelet to automatically reload the static Pod.

User management and RBAC

#

You will be asked to restrict access using Role, ClusterRole, RoleBinding and ClusterRoleBinding. It is best to use the imperative mode to generate your files quickly without opening the documentation.

Here are a few examples…

Create a Role and its Binding in a namespace:

kubectl -n namespace create role pod-reader --verb=get,list,watch --resource=pods
kubectl -n namespace create rolebinding admin-user-binding --role=pod-reader --user=[email protected]

Don’t forget to use auth can-i to check your settings:

kubectl -n namespace auth can-i get pods --as=axinorm

Placing Pods (Taints, Tolerations, Affinity, etc.)

#

The Scheduler is responsible for deciding where to place Pods. However, there are ways to override its behaviour and ensure that your Pods are deployed to the desired nodes:

kubectl taint nodes node01 key1=value1:NoSchedule
kubectl taint nodes node01 key1=value1:NoSchedule- # The minus sign at the end removes the taint

Whether you’re adding a toleration, a nodeSelector or an affinity, make sure to generate the pod’s YAML and complete the spec section based on the documentation.

Example of an affinity based on node labels:

spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: topology.kubernetes.io/region
            operator: In
            values:
            - switzerland

NetworkPolicy

#

The NetworkPolicy is an essential object for securing communications between your Pods. The documentation provides a good, ready-to-use template for the object.

Example of isolating a backend so it only receives traffic from the frontend on port 80:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend
  namespace: backend
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 80

Persistent storage

#

Oh, storage… so many resources to create and elements to add to a Pod.

An important point: the elements of a PersistentVolumeClaim (PVC) must match the criteria of the PersistentVolume (PV) (capacity, access mode, StorageClass) in order to transition to the Bound state.

This section of the documentation will help you retrieve all the objects you need to create, not forgetting to mount your volume in a Pod:

spec:
  volumes:
    - name: html
      persistentVolumeClaim:
        claimName: nginx-html
  containers:
    - name: nginx
      image: nginx
      volumeMounts:
        - name: html
          mountPath: "/usr/share/nginx/html"

Troubleshooting

#

If a node enters the NotReady state, the problem is often caused by the kubelet service. The aim is to identify the cause using an initial set of commands once you have connected via ssh:

systemctl status kubelet # View service status
journalctl -u kubelet    # View the logs

If the service fails to start, check the configuration in /var/lib/kubelet/config.yaml or the file within systemd.

If a Control Plane component (such as the API Server) is down, inspect the container logs on the target node directly using the crictl command:

crictl ps -a
crictl logs [Container ID]

On another topic, if your Pods can no longer communicate with your Services via their names, the problem is likely down to internal DNS resolution.

Check that the CoreDNS Pods are running correctly:

kubectl get pods -n kube-system -l k8s-app=kube-dns

Then test the resolution from a test pod:

kubectl run -it --rm busybox --image=busybox --restart=Never -- /bin/sh -c "nslookup kubernetes.default"

If the command fails, check the Service associated with CoreDNS and its Corefile configuration stored in the ConfigMap within the kube-system namespace.

Helm

#

The exam requires you to know how to manage packages using Helm. There’s no need to edit YAML here; most of the work is done via the command line to install, update or list releases within a specific namespace.

Some essential commands:

# Add a chart repository and update it
helm repo add traefik https://traefik.github.io/charts
helm repo update

# Search for available charts
helm search repo traefik

# Install or update a release in a namespace
helm -n web install my-traefik traefik/traefik
helm -n web upgrade my-traefik traefik/traefik

# List existing releases (history or status)
helm -n web list
helm -n web history my-traefik

# Uninstall a release and clean up resources
helm -n web uninstall my-traefik

Gateway API (HTTPRoute)

#

The Gateway API represents the future of network routing in Kubernetes and is increasingly becoming a key part of the exam syllabus, either replacing or complementing traditional Ingress objects. The documentation is full of examples showing how to link a Gateway to HTTPRoute objects.

The key point is to ensure that the HTTPRoute object targets the correct service and the correct Gateway via the parentRefs section.

Example of simple HTTP routing to a backend service:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: api-route
  namespace: web-app
spec:
  parentRefs:
  - name: prod-gateway # Name of the target gateway
    namespace: infrastructure
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /api
    backendRefs:
    - name: backend-service
      port: 8080

PriorityClass and Pod Priority

#

To manage Pod evictions and scheduling when the cluster is running low on resources, Kubernetes uses the priority mechanism. The documentation explains how to define the importance of a workload.

The first step is to create a PriorityClass object with a numerical value (the higher the value, the higher the Pod’s priority):

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority-apps
value: 1000000
globalDefault: false
description: "Priority class for critical production components"

Once the object has been created within the cluster, simply assign this priority in your Pod’s configuration by completing the spec section:

spec:
  priorityClassName: high-priority-apps
  containers:
  - name: nginx
    image: nginx

If the cluster crashes due to a lack of CPU or memory, the Scheduler will terminate (preempt) Pods with a lower priority to make room for it.

And finally, is it an easy certification to obtain or not?

#

I find the difficulty of CKA doesn’t lie in the time needed to complete all the questions, as with CKAD, but rather in the very (very) broad scope of this certification.

Indeed, it covers a wide range of topics, and if you’re new to the world of Kubernetes, you may find this certification difficult to grasp. That is why you might want to consider starting with an easier approach certification: the CKAD.

As you may have noticed, the target audience is different too; here it is about administration concepts: knowledge of installation, updating machines, how the network works, and certificates.

Good luck to everyone hoping to take this certification!