To hire Kubernetes engineers well, accept first that "Kubernetes engineer" is four jobs: someone who runs clusters, someone who builds the platform on top of them, someone who ships applications onto them, and someone who locks them down. Which one you need depends on three things: the exam list you screen against, the version policy you'll have to live with, and whether you run the control plane yourself.
This guide sits in our series Hire developers by tech stack: rates, vetting and interview guides. It covers the Kubernetes layer only, and it has no salary table, because the figures we found were US and UK recruiter numbers with no dated method behind them.
Which Kubernetes engineer do you need?
The Linux Foundation's three hands-on Kubernetes exams, the CKA, CKAD and CKS, map onto three of the four jobs, which makes them a useful way to write the role.
A cluster operator installs, upgrades, troubleshoots and networks clusters. That's the Certified Kubernetes Administrator (CKA) territory. An application engineer writes manifests, configures workloads and debugs their own services in a cluster someone else runs, which is the Certified Kubernetes Application Developer (CKAD). A security engineer hardens clusters, images and runtime behavior, and that's the Certified Kubernetes Security Specialist (CKS). A platform engineer builds the paved road other teams deploy on, and has no exam of their own. In practice that person usually holds operator skills plus enough of the other two to review them.
A team of ten rarely needs four people. It needs one strong operator or platform engineer, and a clear statement of which of the other duties that person also owns.
Ask a harder question before you write the job description: do you need Kubernetes at all? Two services and a managed database often run fine on a simpler platform, and a Kubernetes specialist hired into that setup will either be bored or will build something you then have to maintain. That's our opinion, not a sourced finding, but we'd rather you hear it before the search than after the hire.
If the role is really CI/CD, on-call and tooling, that's a different search, and the DevOps, SRE and platform-engineering split is covered in its own guide, so we won't repeat it.
Managed or self-run: what changes in the hire
The biggest swing in the skill profile is who operates the control plane.
On a managed service (EKS, GKE or AKS) the provider runs the control plane. Your engineer spends their time on workloads, networking inside the cluster, access control, node pools, cost and upgrades scheduled through the provider. Check your provider's documentation for exactly which upgrade steps it handles for you, because that line differs between services.
Self-run clusters add the layers underneath: control plane upgrades, etcd health and backups, certificate rotation and the choice and care of the network plugin. Those skills sit on top of the managed-cluster profile, and an engineer who has only used managed clusters will tell you so if you ask. If you don't have a reason to self-run (a compliance rule, on-premises hardware, a specific networking need), don't write a job description that requires it.
The account-side work around a managed cluster, such as identity, network layout and cost review, belongs to the cloud-account side: IAM, network and cost review. A Kubernetes hire should be able to talk about it, but you may want a separate person to own it.
What CKA, CKAD and CKS prove
All three are performance-based. According to the CNCF certification overview, the candidate works at the command line on live clusters and isn't answering multiple choice. The entry-level KCNA is the multiple-choice one, so don't treat it as equivalent.
Here's how the three compare, using the Linux Foundation's pages for the CKA, the CKAD and the CKS. Prices are the exam-only list prices as of 2 October 2026 and can change.
| Credential | Format | Duration | Validity | Price | Domains and weights |
|---|---|---|---|---|---|
| CKA | Online, proctored, command line | 2 hours | 2 years | $445 | Troubleshooting 30%, Cluster Architecture, Installation and Configuration 25%, Services and Networking 20%, Workloads and Scheduling 15%, Storage 10% |
| CKAD | Online, proctored, command line | 2 hours | 2 years | $445 | Application Design and Build 20%, Application Deployment 20%, Application Observability and Maintenance 15%, Application Environment, Configuration and Security 25%, Services and Networking 20% |
| CKS | Online, proctored, command line | 2 hours | 2 years | $445 | Cluster Setup 15%, Cluster Hardening 15%, System Hardening 10%, Minimize Microservice Vulnerabilities 20%, Supply Chain Security 20%, Monitoring, Logging and Runtime Security 20% |
The CKS requires a passing CKA first, so anyone holding it has cleared both. The CKA page says the exam is based on Kubernetes v1.35 as of this writing, a version still in support as of 2 October 2026.
Three things follow. A two-year validity means the date on the certificate matters: a CKA from three years ago is a history question, not a current credential. Troubleshooting is the heaviest CKA domain at 30%, which is why the hands-on exercise below is a troubleshooting exercise. And in our view none of the three tests judgment under ambiguity. Someone can pass a timed lab and still lack the habit of asking what a change will break.
We haven't included a passing score because we couldn't find one on the pages we read. Ask candidates to share the credential and check the issue date yourself; don't rely on a PDF or a CV line.
Version support window: why it belongs in the job description
Kubernetes releases about three times a year, according to the Kubernetes release cycle, and each minor version has a short support life. According to the Kubernetes releases page, the project maintains release branches for the most recent three minor versions, with roughly a year of patch support for 1.19 and later. As of 2 October 2026 the latest release is 1.37.1, published 15 September 2026. The page lists these end-of-life dates:
- 1.34 on 27 October 2026
- 1.35 on 28 February 2027
- 1.36 on 28 June 2027
- 1.37 on 28 October 2027
A cluster on 1.34 has 25 days of patches left as of today. That's the point for hiring: upgrades aren't a project you do once, they're a standing duty that returns every few months, and whoever you hire owns it. Put it in the job description in those words.
The upgrade rules are strict enough to test. The version skew policy says kubelet can't be newer than kube-apiserver and can be up to three minor versions older (two for versions before 1.25), and kubectl must stay within one minor version of the API server. Upgrades go in order: kube-apiserver first, then controller-manager, scheduler and cloud-controller-manager, then kubelet and kube-proxy. If kubelet or kube-proxy has fallen three minors behind, the same policy says to upgrade them before you touch the control plane. An engineer who's done this knows the order without looking it up.
Minor releases can also carry breaking changes. A recent 1.37 breaking change in the form of removed cAdvisor flags is the kind of thing an upgrade review should catch before it reaches production.
How to hire a Kubernetes engineer
1. Write the job description around one outcome
Name the outcome for the first six months: a cluster moved off a deprecated version, a platform that lets teams deploy without a ticket, a security review closed. Say whether the clusters are managed or self-run, and which of the four jobs you're hiring. State the version policy as a duty: "keep production within the supported window".
2. Screen on a real manifest or cluster write-up
Ask every candidate for a one-page description of a cluster they ran or a manifest set they wrote: what ran where, what broke, what they'd change. Strong candidates name specifics, such as the incident that taught them to set resource limits. Weak ones list tools. Two paragraphs is enough to sort a pile.
3. Run a hands-on troubleshooting exercise
Pick one exercise from the next section and run it in a sandbox cluster. Have them narrate. How they investigate tells you more than whether they fix it.
4. Verify the credential and scope the access
If they list a CKA, CKAD or CKS, check the date against the two-year validity. Then decide the first-week access. A new hire needing cluster-admin on production before shipping anything is a scoping problem. Start with read-only access and a sandbox, and widen it as they deliver.
5. Choose the engagement model
A defined upgrade, a migration to a managed service or a platform build suits a contractor. Once someone must own on-call and the upgrade cadence long term, hire permanently and write that ownership into the offer.
Kubernetes vetting exercises that separate senior from mid-level
A certification can't test judgment. These four can.
Manifest review
Give them a Deployment with no resource requests or limits, no readiness or liveness probes, and a container running as root. Ask what's wrong and what each fix could break.
A strong candidate explains what happens to a node when pods have no limits and one leaks memory, notes that a badly tuned liveness probe can restart a healthy but slow pod in a loop, and asks about the securityContext before dropping root. A weak candidate lists "best practices" and stops.
Broken pod triage
Start a pod stuck in a crash loop or pending state and tell them only that it won't run. Troubleshooting carries 30% of the CKA, so this is the closest exercise to the day job.
Strong candidates go in order: pod status and events, logs from the current and previous container, then scheduling constraints, then node conditions. Weak ones delete the pod and hope. Listen for whether they ask what changed recently.
RBAC and NetworkPolicy review
Hand them a role that grants wildcard verbs on all resources to a service account that only reads one ConfigMap, and a namespace with no network policy. Ask what an attacker who compromises that workload can reach.
The strong answer names the blast radius first, then proposes a narrower role and a default-deny policy, and warns that tightening either can break something that relied on the open access, so they'd check audit data or test in a non-production namespace first.
Upgrade plan
Ask for a written plan to take a cluster from 1.36 to 1.37 with no downtime for users. Strong plans read the release notes for breaking changes, check the skew rules, upgrade the control plane before nodes, drain nodes one at a time, and say how they'd roll back. Weak plans say "run the upgrade command".
Kubernetes interview questions
1. A pod is in CrashLoopBackOff. Walk me through what you check, in order.
Tests triage discipline. Listen for events, previous-container logs, probes, resource limits and recent changes, not a restart.
2. What's the difference between a Deployment, a StatefulSet and a DaemonSet, and when would you not use a Deployment?
Tests whether they pick workload types by need. A strong answer ties StatefulSets to stable identity and storage and DaemonSets to per-node agents.
3. How do resource requests and limits affect scheduling and eviction?
Tests whether they understand that requests drive scheduling and limits drive throttling or termination. Weak answers treat them as the same thing.
4. How would you give a pod access to a cloud resource without storing a credential in the cluster?
Tests identity thinking. Listen for workload identity from the provider's own mechanism instead of long-lived keys in a Secret.
5. In what order do you upgrade the components, and what can't be newer than what?
Tests the skew policy directly: API server first, kubelet never newer than the API server, kubectl within one minor.
6. A node goes NotReady at 3 a.m. What do you do?
Tests on-call sense. Listen for checking node conditions and whether workloads rescheduled, and for knowing when to cordon and drain rather than act on the node blindly.
7. When would you tell a team not to use Kubernetes?
Tests honesty. A senior engineer has an answer, usually about team size, workload shape or operating cost.
Hiring Kubernetes engineers through HighCircl
HighCircl's covered stacks include DevOps, and it hires Kubernetes developers through HighCircl from seven European countries. It doesn't run Kubernetes-specific vetting stages. Candidates go through four stages of engineer-led vetting, and about 1 in 10 applicants pass. HighCircl matches within 72 hours and shortlists 3-5 candidates. The margin is 20%, capped and disclosed, there's no minimum hour commitment, and a replacement guarantee applies if an engagement isn't working.
FAQ
Do Kubernetes engineers need the CKA?
No, but it's a fair first filter for operator roles, because it's a timed hands-on exam rather than multiple choice. Treat it as a reason to ask deeper questions. For application-focused roles the CKAD is the closer match, and for security roles the CKS, which itself requires a CKA.
What's the difference between CKA, CKAD and CKS?
The CKA covers running a cluster, with Troubleshooting the heaviest domain at 30%. The CKAD covers building and configuring applications that run on one. The CKS covers hardening, supply chain and runtime security, and you can't sit it without passing the CKA first. All three are two-hour, performance-based exams valid for two years.
How long is a Kubernetes version supported?
The project maintains the three most recent minor versions, with about a year of patch support for 1.19 and later. As of 2 October 2026, 1.34 reaches end of life on 27 October 2026 and 1.37 on 28 October 2027.
Should we use managed Kubernetes or run it ourselves?
Use a managed service unless you have a specific reason not to, such as a compliance rule or on-premises hardware. That's an opinion based on the hiring cost of the extra skills, not a benchmark. Self-run adds control plane upgrades, etcd and network plugin ownership to the job.
How much does a Kubernetes engineer cost?
There's no sourced, dated figure worth printing here. Published numbers we found are US or UK recruiter figures with no stated method. For HighCircl's general senior engineer range, it's €45-105/hr ($50-115/hr), which isn't a Kubernetes-specific rate.
How long does it take to hire a Kubernetes engineer?
HighCircl matches within 72 hours and shortlists 3-5 candidates for its covered stacks, which include DevOps. A direct hire can take weeks once interviews and notice periods are counted. In our view, a common avoidable delay is a job description that doesn't say whether the clusters are managed or self-run.