20 Kubernetes Tools Every CKA Should Know

The 20 Kubernetes tools listed here are the ones that CKA-certified administrators actually use in production. Some of them appear directly on the CKA exam (kubectl, kubeadm, etcdctl). Others are open-source tools that make your daily work faster and less error-prone after you pass the exam and start operating real clusters.

This list is split into three categories: tools you must know for the CKA exam, tools that make cluster operations better, and tools for debugging and troubleshooting.

Kubernetes Tools You Need for the CKA Exam

These tools appear directly on the CKA exam or are required to complete exam tasks. If you are studying for the CKA, master these first.

1. kubectl

The one tool you absolutely cannot avoid.

kubectl is the command-line interface for Kubernetes. Every CKA exam question requires it. Every day working with Kubernetes involves it. It is how you create resources, inspect cluster state, debug problems, and manage configurations.

The difference between passing and failing the CKA often comes down to kubectl speed. Engineers who can generate YAML with --dry-run=client -o yaml, filter output with -o jsonpath, and chain imperative commands together finish questions in 3 to 4 minutes. Engineers who write YAML from scratch spend 8 to 10 minutes on the same question.

Key patterns to memorize:

# Generate YAML templates instead of writing from scratch
kubectl create deployment nginx --image=nginx --replicas=3 --dry-run=client -o yaml > deploy.yaml

# Quick Pod creation
kubectl run test --image=busybox --rm -it --restart=Never -- /bin/sh

# Filter output with jsonpath
kubectl get nodes -o jsonpath='{.items[*].status.addresses[?(@.type=="InternalIP")].address}'

# Sort and filter
kubectl get pods --sort-by=.metadata.creationTimestamp
kubectl get pods -A --field-selector=status.phase!=Running

Exam tip: Set up the alias and autocompletion at the start of every exam session. This saves you from typing kubectl hundreds of times.

alias k=kubectl
source <(kubectl completion bash)
complete -F __start_kubectl k

For a full breakdown of kubectl techniques that help on the exam, see our CKA study guide.

2. kubeadm

The cluster bootstrapping tool tested on the CKA.

kubeadm is how you install, configure, and upgrade Kubernetes clusters. The CKA exam tests cluster installation and upgrade scenarios, which means you need to know kubeadm init, kubeadm join, and kubeadm upgrade.

What you need to know for the CKA:

# Initialize a control plane node
kubeadm init --pod-network-cidr=10.244.0.0/16

# Join a worker node to the cluster
kubeadm join <control-plane-ip>:6443 --token <token> --discovery-token-ca-cert-hash sha256:<hash>

# Upgrade a cluster
kubeadm upgrade plan
kubeadm upgrade apply v1.31.0

# Generate a new join token (when the original expires)
kubeadm token create --print-join-command

kubeadm handles certificate generation, control plane component deployment, and cluster configuration. Understanding what happens behind the scenes (static Pod manifests in /etc/kubernetes/manifests, certificates in /etc/kubernetes/pki) helps you troubleshoot cluster issues on the exam.

3. etcdctl

Required for etcd backup and restore questions.

etcd is the key-value store that holds all Kubernetes cluster state. The CKA exam includes questions about backing up and restoring etcd. etcdctl is the CLI tool for interacting with etcd directly.

The backup command you must know:

ETCDCTL_API=3 etcdctl snapshot save /tmp/etcd-backup.db \
  --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

The restore command:

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

After restoring, you need to update the etcd static Pod manifest to point to the new data directory. This trips up a lot of people on the exam. The manifest lives at /etc/kubernetes/manifests/etcd.yaml, and you need to change the --data-dir flag and the corresponding hostPath volume mount.

4. vim

The text editor you will use for every YAML edit on the exam.

The CKA exam environment has vim (and nano) available. Most CKA candidates use vim because it is faster once you know the basics. You do not need to be a vim expert, but you need to be comfortable enough to edit YAML files without making indentation errors.

Minimum vim skills for the CKA:

• i to enter insert mode, Esc to exit
• :wq to save and quit, :q! to quit without saving
• dd to delete a line, yy to copy a line, p to paste
• /keyword to search, n for next match
• u to undo
• :set number to show line numbers
• Visual mode (V for line select) for block operations

Critical .vimrc settings:

cat <<EOF >> ~/.vimrc
set tabstop=2
set shiftwidth=2
set expandtab
EOF

These settings prevent the most common YAML error on the CKA: tabs instead of spaces. Kubernetes rejects YAML files with tab characters, and debugging invisible whitespace errors under time pressure is brutal.

5. systemctl and journalctl

Linux tools used in every cluster troubleshooting scenario.

These are not Kubernetes-specific tools, but you will use them on the CKA exam. kubelet runs as a systemd service on every node, and troubleshooting a broken node almost always starts with checking kubelet status.

# Check kubelet status
systemctl status kubelet

# Restart kubelet
systemctl restart kubelet

# Enable kubelet to start on boot
systemctl enable kubelet

# Read kubelet logs
journalctl -u kubelet -f

# Read kubelet logs from the last 10 minutes
journalctl -u kubelet --since "10 minutes ago"

The CKA troubleshooting domain is worth 30% of the exam. Many troubleshooting questions involve a node that is NotReady, and the fix usually involves diagnosing a kubelet issue with systemctl and journalctl. This is where strong Linux skills pay off directly.

Kubernetes Tools for Daily Cluster Operations

These tools are not on the CKA exam, but every experienced Kubernetes administrator uses them. Learn these after you pass the CKA.

6. Helm

The package manager for Kubernetes.

Helm lets you install, upgrade, and manage applications on Kubernetes using charts (pre-configured templates). Instead of managing dozens of individual YAML files, you install an application with one command and configure it with values files.

# Add a chart repository
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts

# Install a chart
helm install monitoring prometheus-community/kube-prometheus-stack -n monitoring

# Upgrade a release
helm upgrade monitoring prometheus-community/kube-prometheus-stack -n monitoring -f values.yaml

# List installed releases
helm list -A

# Roll back to a previous version
helm rollback monitoring 1

Helm is tested on the CKAD but not the CKA. However, you will use it constantly in production. Most open-source Kubernetes tools (Prometheus, cert-manager, ingress controllers) distribute their installations as Helm charts.

7. k9s

A terminal UI for Kubernetes that is genuinely useful.

k9s provides a real-time, interactive terminal interface for your Kubernetes cluster. Instead of running kubectl get pods repeatedly, you see a live-updating view of your resources. You can filter, sort, describe, log, exec into pods, and delete resources all from a single interface.

# Launch k9s
k9s

# Launch in a specific namespace
k9s -n kube-system

# Launch in a specific context
k9s --context production

Why it matters: k9s cuts the time for routine cluster inspection in half. During an incident, being able to watch Pod status changes in real-time while simultaneously tailing logs is significantly faster than running separate kubectl commands in multiple terminals.

k9s is free and open-source. Install it from https://k9scli.io.

8. kubectx and kubens

Context and namespace switching without the typing.

If you work with multiple clusters and namespaces (and you will), kubectx and kubens save you from typing long kubectl config use-context and -n namespace commands.

# List contexts
kubectx

# Switch context
kubectx production

# Switch to previous context
kubectx -

# List namespaces
kubens

# Switch default namespace
kubens kube-system

These are small tools, but they compound. Switching contexts and namespaces happens dozens of times per day. Saving 5 seconds each time adds up fast.

9. kind (Kubernetes IN Docker)

Disposable local clusters for testing and learning.

kind runs Kubernetes clusters inside Docker containers. You can spin up a cluster in under a minute and destroy it when you are done. This makes it perfect for CKA exam practice, testing configurations, and running local integration tests.

# Create a simple cluster
kind create cluster

# Create a multi-node cluster
kind create cluster --config kind-config.yaml

# Delete a cluster
kind delete cluster

# Load a local Docker image into the cluster
kind load docker-image my-app:latest

kind vs minikube: kind is lighter and faster for multi-node setups. minikube is better if you need a single-node cluster with additional features like dashboards and addons. For CKA exam practice, kind is ideal because you can create multi-node clusters that match the exam environment more closely.

10. minikube

Single-node local Kubernetes with batteries included.

minikube creates a single-node Kubernetes cluster with built-in addons for metrics-server, dashboard, ingress, and more. It supports multiple drivers (Docker, VirtualBox, HyperKit) and is the most popular tool for local Kubernetes development.

# Start a cluster
minikube start

# Enable addons
minikube addons enable metrics-server
minikube addons enable ingress

# Access the dashboard
minikube dashboard

# SSH into the node
minikube ssh

minikube is excellent for beginners learning Kubernetes concepts. For CKA exam practice specifically, kind gives you a more realistic multi-node setup. But for day-to-day development and testing, minikube's addon system is convenient.

11. kustomize

Template-free YAML customization built into kubectl.

kustomize lets you customize Kubernetes manifests without templating (unlike Helm). It uses overlays and patches to modify base configurations for different environments. Since Kubernetes 1.14, kustomize is built directly into kubectl via kubectl apply -k.

# Apply a kustomization
kubectl apply -k overlays/production/

# Preview what will be applied
kubectl kustomize overlays/production/

kustomize is popular in GitOps workflows where you want to maintain different configurations for dev, staging, and production without duplicating YAML files. It is lighter than Helm and does not require a separate binary.

12. stern

Multi-pod log tailing that actually works.

stern lets you tail logs from multiple Pods simultaneously with color-coded output. Instead of running kubectl logs on each Pod individually, stern matches Pods by name pattern and streams all their logs together.

# Tail logs from all Pods matching a pattern
stern api-server

# Tail logs from a specific namespace
stern -n production payment

# Show timestamps
stern --timestamps api-server

# Filter by container name
stern api-server -c nginx

When you are debugging an issue across a Deployment with 10 replicas, stern is dramatically faster than checking each Pod individually.

13. crictl

Container runtime debugging tool.

crictl is the CLI for CRI-compatible container runtimes (containerd, CRI-O). Since Docker is no longer the default runtime in Kubernetes, crictl is what you use to inspect containers at the runtime level.

# List containers
crictl ps

# List pods
crictl pods

# Inspect a container
crictl inspect <container-id>

# Check container logs
crictl logs <container-id>

# Pull an image
crictl pull nginx:latest

You are unlikely to need crictl on the CKA exam, but it is essential for production troubleshooting when the issue is below the Kubernetes API level.

Kubernetes Tools for Debugging and Troubleshooting

14. kubectl debug

Ephemeral debug containers for running Pods.

kubectl debug lets you attach a debugging container to a running Pod without modifying the Pod spec. This is invaluable when a container does not have a shell or debugging tools installed (which is most production containers in 2026, since everyone uses distroless or scratch base images).

# Attach a debug container to a running Pod
kubectl debug -it my-pod --image=busybox --target=my-container

# Debug a node
kubectl debug node/my-node -it --image=ubuntu

This feature requires Kubernetes 1.25+ and ephemeral containers support. It solves the "I need to debug a Pod but there is no shell inside it" problem that comes up constantly in production.

15. kubectl top

Quick resource usage check.

kubectl top shows CPU and memory usage for nodes and Pods. It requires metrics-server to be installed in the cluster.

# Node resource usage
kubectl top nodes

# Pod resource usage (all namespaces)
kubectl top pods -A

# Pod resource usage sorted by CPU
kubectl top pods --sort-by=cpu

# Container-level resource usage
kubectl top pods --containers

This is useful on the CKA exam for questions about resource management and identifying Pods that are consuming unexpected amounts of resources.

16. kubectl diff

Preview changes before applying them.

kubectl diff shows you what will change when you apply a manifest, without actually making the change. It compares your local file against the live cluster state.

kubectl diff -f deployment.yaml

In production, always diff before you apply. It prevents the "I accidentally changed something I didn't mean to" scenario that has caused countless incidents.

17. jsonpath and jq

Extracting specific data from kubectl output.

jsonpath is built into kubectl and lets you extract specific fields from resource output. jq is a standalone JSON processor that handles more complex queries.

# Get all node IPs with jsonpath
kubectl get nodes -o jsonpath='{.items[*].status.addresses[?(@.type=="InternalIP")].address}'

# Get Pod names and their node assignments
kubectl get pods -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.nodeName}{"\n"}{end}'

# Using jq for complex filtering
kubectl get pods -o json | jq '.items[] | select(.status.phase != "Running") | .metadata.name'

jsonpath appears on the CKA exam. You will get questions that ask you to write specific data to a file, and knowing jsonpath syntax is the fastest way to extract it.

18. kubectl explain

The built-in API documentation you can use on the exam.

kubectl explain shows the documentation for any Kubernetes resource field. This is allowed on the CKA exam and saves you from switching to the browser documentation.

# Explain a resource type
kubectl explain pod

# Explain a specific field
kubectl explain pod.spec.containers.resources

# Show the full field tree recursively
kubectl explain pod.spec --recursive

When you forget the exact field name for a SecurityContext or a resource limit, kubectl explain gives you the answer in 2 seconds.

19. openssl

Certificate inspection and management.

Kubernetes uses TLS certificates extensively. The CKA exam may include questions about certificate expiration, certificate renewal, or troubleshooting TLS-related issues.

# Check certificate expiration
openssl x509 -in /etc/kubernetes/pki/apiserver.crt -noout -dates

# View certificate details
openssl x509 -in /etc/kubernetes/pki/apiserver.crt -noout -text

# Check which CA signed a certificate
openssl x509 -in /etc/kubernetes/pki/apiserver.crt -noout -issuer

# Verify a certificate against its CA
openssl verify -CAfile /etc/kubernetes/pki/ca.crt /etc/kubernetes/pki/apiserver.crt

The Cluster Architecture domain (25% of the CKA) includes certificate management topics. Knowing how to inspect certificates with openssl is a skill that comes up on the exam and in production.

20. kubectl-convert

API version migration tool.

kubectl-convert helps you migrate manifests between Kubernetes API versions. When a Kubernetes upgrade deprecates or removes an API version, kubectl-convert updates your manifests to use the new API version.

# Convert a manifest to a newer API version
kubectl convert -f old-ingress.yaml --output-version networking.k8s.io/v1

This is relevant for CKA exam questions about API deprecations and cluster upgrades. In production, it is essential during version upgrades when deprecated APIs are removed.

Which Kubernetes Tools to Learn First

If you are preparing for the CKA exam, here is the priority order:

Week 1 to 2: kubectl (commands, flags, jsonpath, dry-run patterns), vim basics Week 3 to 4: kubeadm (init, join, upgrade), etcdctl (backup/restore), systemctl/journalctl Week 5 to 6: kubectl explain, kubectl debug, kubectl top, openssl

After passing the CKA, add these to your toolkit: Month 1: k9s, kubectx/kubens, stern Month 2: Helm, kustomize Ongoing: kind or minikube for practice, crictl for runtime debugging

The CKA study guide maps these tools to specific exam domains and practice exercises. Our CKA exam mistakes guide covers the most common tool-related errors people make under exam pressure.

FAQ

Which Kubernetes tools are available on the CKA exam?

The CKA exam environment includes kubectl, kubeadm, etcdctl, vim, nano, systemctl, journalctl, openssl, and standard Linux utilities. You also have access to the official Kubernetes documentation at kubernetes.io. Tools like Helm, k9s, and stern are not available during the exam.

What is the most important Kubernetes tool to learn?

kubectl, without question. It is the primary interface for every Kubernetes operation. If you can only learn one tool well, make it kubectl. Master the imperative commands (create, run, expose), the --dry-run=client -o yaml pattern, jsonpath output formatting, and resource inspection commands (describe, logs, exec).

Should I learn Helm before or after the CKA?

After. Helm is not tested on the CKA exam (it is tested on the CKAD). Focus on kubectl, kubeadm, and etcdctl for the CKA. After passing, Helm should be one of the first tools you add. It is used in nearly every production Kubernetes environment.

Is k9s better than kubectl?

k9s does not replace kubectl. It is a visual layer on top of it. k9s is better for monitoring and navigating cluster state interactively. kubectl is better for scripting, automation, and one-off commands. Most experienced administrators use both: k9s for daily cluster monitoring and kubectl for everything else.

Do I need to know Docker for the CKA?

You need to understand container concepts (images, containers, registries, Dockerfiles), but you do not need Docker-specific CLI knowledge. Modern Kubernetes uses containerd as its container runtime, not Docker. The CKA tests container concepts through Kubernetes primitives (Pod specs, image pull policies, container resource limits) rather than through Docker commands.

What is the best way to practice with these tools?

Set up a local cluster with kind or minikube and practice daily. Create resources with kubectl, break things on purpose, then fix them. Back up and restore etcd. Upgrade a cluster with kubeadm. The more you practice in a terminal, the faster you will be on exam day. Our certification tips guide covers practice strategies in detail.