Hire Kubernetes developers

Kubernetes orchestrates containers across machines, and the most valuable thing a candidate can tell you is when not to use it.

What Kubernetes actually is

Kubernetes is an open-source system for running containers across a cluster of machines, originally from Google and now governed by the Cloud Native Computing Foundation. It schedules workloads onto nodes, restarts what fails, routes traffic, manages configuration and secrets, and scales services against demand. It has become the default answer for running containers at scale, and the default answer at scales where it is not warranted.

Its central idea is declarative reconciliation. You describe the state you want and controllers continuously work to make reality match. That is genuinely powerful and it is also why Kubernetes failures are confusing to newcomers: nothing failed in the sense of throwing an error, something simply has not converged, and understanding why means understanding what each controller is trying to do.

The honest commercial assessment is that Kubernetes solves real problems and creates a substantial operational surface in exchange. Networking, storage, upgrades, access control, resource management and cost all become things somebody owns. For an organisation with many services and several teams, that trade is usually worth it. For three services and four engineers, it frequently is not, and a good Kubernetes engineer will say so.

The part that separates seniors from mid-levels

Resource requests and limits are where most production problems originate, and they are the clearest test of real operating experience. Requests determine scheduling; limits determine throttling and termination. Set memory limits too low and the process is killed under load, producing crashes that look like application bugs. Set them too high and you pay for capacity nobody uses. Set CPU limits carelessly and you throttle a service that had plenty of headroom. Candidates who have tuned these on a real cluster describe them very differently from those who have copied examples.

Networking is the second area and the most commonly misunderstood. Services, ingress, network policies and the cluster's own networking implementation determine what can reach what. Without network policies, every pod can talk to every other pod, which is the default and is rarely what anyone intends. Engineers who have implemented policies in a running cluster know that the hard part is discovering what actually communicates, not writing the rules.

Upgrades are the third and the one that separates people who run clusters from people who use them. Kubernetes releases frequently with a relatively short support window, so an estate must be upgraded continuously rather than occasionally. Each upgrade can remove APIs that workloads depend on. An engineer who has taken a production cluster through several version upgrades without downtime has done something genuinely difficult.

Where Kubernetes is used

The label “Kubernetes developer” covers several jobs that share a technology and little else. These are the settings the work usually turns up in, and the one you are hiring into should shape the whole process, because the judgement each demands is different.

Multi-service platforms

Organisations running many services across several teams, which is the situation Kubernetes was designed for.

Regulated and hybrid environments

Where workloads must run across on-premises and cloud infrastructure with consistent tooling.

Platform engineering

Internal platforms giving product teams a way to deploy without needing cluster expertise themselves.

Machine learning infrastructure

Scheduling training and inference workloads, including access to specialised hardware.

Software vendors

Products shipped to customers who run them in their own clusters, where Kubernetes is the distribution format.

Migration from virtual machines

Consolidating workloads onto shared infrastructure with better utilisation.

If a candidate's experience sits in a different row of that list from the work you have, that is not a reason to reject them, but it is the thing to probe. Ask what would be different about their approach in your setting. Someone who can answer that has transferable judgement. Someone who says it would be much the same has probably not thought about it.

Which Kubernetes versions are still supported

Kubernetes releases several times a year with a comparatively short support window per version, which makes continuous upgrading an operational commitment rather than an occasional project.

The table is generated from public release data rather than written by hand, so it states what is supported today rather than what was true when any given article was published. Of the 8 most recent release lines, 4 are still maintained and 4 have passed their published end-of-life date. That distinction is the practical one when you read a job specification: a requirement written against a line that is now out of support tells you the specification is older than the codebase it describes, and it is worth asking which of the two the new developer will actually work in.

Source: endoflife.date public release data, read 2026-09-25.

Two questions follow from this table in an interview. The first is which line the candidate has most recently shipped against, because someone whose last production work was on an unsupported line has not had to deal with the changes since. The second is how they have handled an upgrade. Version migrations are where you see whether a developer reads release notes, writes characterisation tests before changing anything, and knows how to stage a rollout, or whether they upgrade in place on a Friday and hope.

The toolchain around it

Nobody hires for Kubernetes alone. The surrounding tools are where most of the day-to-day work happens, and a gap in any of them costs more time than a gap in the core library. This is the set that turns up most often on real job specifications alongside it.

A managed control plane

EKS, GKE or AKS. Running your own control plane is rarely justified now.

Helm or Kustomize

Packaging and environment-specific configuration of manifests.

Argo CD or Flux

Continuous deployment driven from a repository, which makes cluster state reviewable.

Prometheus and Grafana

Metrics, including the resource usage that drives requests and limits.

An ingress controller

Routing external traffic, with certificate handling.

Network policies

Restricting pod-to-pod communication, which is unrestricted by default.

External Secrets or similar

Pulling credentials from a real secret manager instead of storing them in the cluster.

Cost tooling

Attribution by namespace or team, since a cluster hides who is spending what.

Related skills that frequently appear on the same specification: Go, Microsoft Azure, AWS, DevOps, Terraform.

What to test in an interview

These are the topics that separate candidates in practice. Each one is given with why it discriminates, what a strong answer sounds like, and the response that should make you slow down. None of them requires a whiteboard.

Requests and limits

Where production problems concentrate and where real experience shows.

• Strong answer: Explains scheduling versus throttling, has tuned them from observed usage, and knows what a memory limit breach looks like.
• Warning sign: Copies values from examples, or omits them entirely.

Debugging a pod that will not start

A concrete diagnostic question that cannot be answered from theory.

• Strong answer: Works through the status, events, logs and previous container state methodically, and distinguishes image, scheduling, configuration and health-check causes.
• Warning sign: Deletes the pod and hopes, or restarts the deployment as a first response.

Networking and policies

The default is wide open and most clusters stay that way.

• Strong answer: Understands service types and ingress, has implemented network policies, and knows discovering real traffic is the hard part.
• Warning sign: Has never used a network policy and assumes namespaces provide isolation.

Cluster upgrades

Separates cluster operators from cluster users.

• Strong answer: Has upgraded production across versions, checks for removed APIs in advance, and drains nodes carefully.
• Warning sign: Has only used clusters somebody else upgrades.

Secret handling

Kubernetes secrets are base64-encoded, not encrypted, which surprises people.

• Strong answer: Uses an external secret manager, enables encryption at rest, and restricts access properly.
• Warning sign: Believes Kubernetes secrets are encrypted by default, or commits them to the repository.

When not to use Kubernetes

The single most useful question in this field.

• Strong answer: Can describe workloads and team sizes where a managed container service is the better answer, and has recommended against adoption.
• Warning sign: Treats it as the correct answer everywhere.

An incident on a cluster

Operational judgement is learned during outages.

• Strong answer: Describes diagnosis, mitigation and the change that followed, with specifics about what the cluster was doing.
• Warning sign: Has never operated a cluster under real load.

Warning signs in a Kubernetes codebase

The fastest way to read a candidate is to ask what they have found wrong in code they inherited. These are the patterns that come up most often, what they cost, and what fixing them looks like. A developer who recognises three or four of these from their own experience is worth more than one who can recite the documentation.

Missing resource requests and limits

• What you see: Workloads deployed with no resource specification.
• What it costs: Unpredictable scheduling, noisy neighbours, and pods terminated under memory pressure in ways that look like application crashes.
• The fix: Set requests from observed usage and limits with headroom. Revisit them as the workload changes rather than setting once.

No network policies

• What you see: A cluster where every pod can reach every other pod.
• What it costs: One compromised workload has network access to everything, turning a contained incident into a general one.
• The fix: Default-deny and allow explicitly. Map actual traffic first, because the discovery is the work.

Secrets treated as encrypted

• What you see: Credentials in Kubernetes secret objects with no external manager and no encryption at rest.
• What it costs: Anyone with read access to the namespace has the credentials, and base64 is encoding rather than protection.
• The fix: Use an external secret manager, enable encryption at rest, and scope read access deliberately.

Latest image tags

• What you see: Deployments referencing a mutable tag.
• What it costs: Nobody can say what is running, rollbacks do not work, and a restart can silently change the version.
• The fix: Deploy immutable digests or version tags. Make the running version a fact rather than an assumption.

Adopting Kubernetes too early

• What you see: A cluster running a handful of services for a small team.
• What it costs: An operational surface larger than the application, maintained by people whose job is meant to be the product.
• The fix: Use a managed container service until a specific requirement forces the move. The migration later is easier than the operational debt now.

Cluster state changed by hand

• What you see: Resources applied directly rather than through a repository.
• What it costs: Nobody knows what is deployed, and the next automated sync reverts the fix.
• The fix: Drive the cluster from a repository so its state is reviewable and reproducible.

What each level can own

Job titles are not comparable between companies, so it is more useful to describe levels by what a person can be left to own without supervision. These are the boundaries we use when we assess a Kubernetes engineer.

Junior

Deploys workloads into an existing cluster using established manifests. Needs review on resources and health checks.

Mid-level

Owns the deployment and operation of services on the cluster, including monitoring and resource tuning.

Senior

Owns cluster architecture, networking, security posture, upgrade strategy and cost attribution. Can diagnose a control-plane-level problem.

Staff

Owns the platform contract with product teams, the multi-cluster strategy, and the judgement about which workloads belong on Kubernetes at all.

How the work is usually scoped

Team shape follows the kind of work, not the headcount you happen to have budget for. These are the shapes that come up most often and the constraint that actually governs each one.

Cluster setup

• Usual team: One senior engineer.
• What governs it: Managed control planes make this quick. Networking, access control and cost attribution are the decisions that matter.

Migration onto Kubernetes

• Usual team: Two engineers plus application owners.
• What governs it: Scoped by how cleanly applications containerise. Stateful workloads are the hard cases and often should stay managed.

Cluster upgrade programme

• Usual team: One senior engineer, recurring.
• What governs it: Not optional given the release cadence. Scoped by workload count and by deprecated API usage.

Security hardening

• Usual team: One senior engineer.
• What governs it: Network policies, secret handling and access control. Mapping real traffic is the slow part.

Cost attribution and reduction

• Usual team: One engineer.
• What governs it: Clusters obscure who spends what. Usually finds substantial over-provisioning in requests.

Migration work you may actually be hiring for

A large share of Kubernetes work is not new development. It is moving an existing system from one state to another while it stays in service. These are the migrations that come up most often, and each one asks for a different kind of experience from the person you hire.

Virtual machines to Kubernetes

• Why teams do it: Better utilisation, consistent deployment and independent scaling per service.
• What to watch: Stateless services first. Anything depending on host state, local storage or fixed addressing needs rework, and databases usually belong on a managed service rather than in the cluster.

A self-managed control plane to a managed one

• Why teams do it: Removing the hardest operational work for a modest cost.
• What to watch: Workload migration is straightforward; identity integration and networking usually are not. Run both and move namespaces gradually rather than switching in one step.

Manual manifest application to repository-driven deployment

• Why teams do it: Cluster state becomes reviewable, reproducible and auditable.
• What to watch: Reconcile what is actually deployed into the repository first, because the first sync will otherwise revert changes nobody recorded. Expect that reconciliation to surface surprises.

An unsupported Kubernetes version to current

• Why teams do it: Security patches and continued support from the managed platform.
• What to watch: Check for removed APIs before each step and upgrade one minor version at a time. Skipping versions is not supported and is where these upgrades go wrong.

Migration work rewards a different temperament from greenfield work. The useful question in an interview is not whether someone has done the specific migration you face, but whether they have ever run one incrementally: behind a flag, with both paths live, and with a way back. Developers who have only done big-bang cutovers tend to propose them again.

What a good brief for this role contains

Most of the time lost in hiring a Kubernetes engineer is lost before anyone is interviewed, in the gap between what the brief says and what the team actually needs. These are the points that, for this technology specifically, change who the right candidate is. A brief that answers them can be matched in days. One that does not produces a shortlist that looks reasonable and converts badly.

• Whether the control plane is managed or self-hosted, since these are different levels of responsibility.
• How many services and teams use the cluster, because this determines whether adoption was justified.
• How workloads are deployed: manifests applied by hand, Helm, or a repository-driven tool.
• What the current version is and how far behind support that leaves you.
• Whether network policies and external secret management exist.
• Whether the person will be on call for the cluster or only deploy onto it.

If you cannot answer some of these yet, that is normal and it is still worth writing down which ones are open. An unknown that is named can be worked around. An unknown that is papered over in a job specification turns into a rejected shortlist and a restart four weeks later.

What the US market pays for this work

Kubernetes work is counted by the US Bureau of Labor Statistics under Network and Computer Systems Administrators. That classification is broader than the technology itself, so treat the figures as the shape of the market a Kubernetes engineer is hired into rather than as a rate card for the skill. Across the United States the Bureau counts 314,340 people in this occupation, with a median annual wage of $99,130.

The spread matters more than the midpoint. The 90th percentile is about 2.5 times the 10th, which is a wide band for a single occupation and tells you that the title on its own carries very little pricing information. Two people described as a Kubernetes engineer can sit at $62,640 and $155,050 in the same national dataset. When a budget is set from a median without asking which end of that range the work actually needs, the hire that follows is usually the wrong one in one direction or the other.

Related classifications are worth reading alongside it, because teams hiring for Kubernetes frequently end up recruiting against these titles too:

Source: BLS Occupational Employment and Wage Statistics, May 2025. Figures cover all US employers and are not FuturByte rates.

These are employer-side wage figures for people on a US payroll. They exclude employer taxes, benefits, recruitment cost and the months a seat sits empty, all of which are real and none of which appear in a salary line. The useful way to read the table is as the cost of the alternative you are comparing against, not as a number to match.

How US metro markets compare for this role

The same job is priced very differently across the country. Ranked by median annual wage for Network and Computer Systems Administrators, the gap between the highest and lowest of the 28 metro areas covered here is a factor of about 1.7. San Jose sits at the top with a median of $133,360; Pittsburgh sits at the bottom with $80,440. A budget built from a national median will be wrong in both of those markets, in opposite directions.

Location quotient compares how concentrated this occupation is in the metro against the national average. A value above 1 means the metro has more of this work than its size would predict.

The location quotient column is the more useful one for hiring. A high median tells you what a role costs; a high quotient tells you whether the people exist. Washington, D.C., Baltimore, Austin, Raleigh, Tampa, Charlotte each have a quotient of 1.5 or above, meaning the work is concentrated there well beyond what the size of the local economy would predict. Those are the markets where a search is likely to be quick and competitive at the same time, and where a counter-offer is most likely to take a candidate off the table late in the process.

The opposite case is worth planning for too. In a metro with a low quotient, the total pool is small even when wages look reasonable, so the realistic options are to widen the search radius, accept a longer time to hire, or bring the capability in from outside the local market entirely. That last option is what most teams are weighing when they come to us.

Hiring risks worth naming

Every one of these has produced a bad hire somewhere. They are written down so that the process tests for them deliberately rather than discovering them in month three.

Cluster user presented as cluster operator. Ask whether they have upgraded a production cluster. Deploying into one is a different job from running one.

Enthusiasm over judgement. Ask when they would not use it. Someone with no answer will build something your team cannot sustain.

No security posture. Ask about network policies and secrets. Both defaults are permissive and most clusters never change them.

No cost awareness. Over-provisioned requests are the most common source of cluster waste and are invisible without attribution.

Hiring Kubernetes developers by metro area

Wages for this occupation vary more between US metro areas than most budget models assume. Each page below sets out the published employment and wage figures for that market, how it compares with the national picture, and what the local industry mix means for the kind of Kubernetes engineer who will be available.

• New York, NY $119,390 median
• Seattle, WA $104,440 median
• San Jose, CA $133,360 median
• Washington, D.C. $125,430 median
• San Francisco, CA $129,680 median
• Dallas-Fort Worth, TX $103,260 median
• Los Angeles, CA $106,290 median
• Boston, MA $116,770 median
• Chicago, IL $103,170 median
• Atlanta, GA $101,000 median
• Austin, TX $104,520 median
• Phoenix, AZ $93,730 median
• Philadelphia, PA $100,460 median
• Minneapolis-St. Paul, MN $102,790 median
• Denver, CO $105,090 median
• Detroit, MI $96,400 median
• Houston, TX $101,430 median
• Charlotte, NC $89,990 median
• San Diego, CA $105,170 median
• Salt Lake City, UT $99,110 median
• Miami, FL $97,180 median
• Portland, OR $102,950 median
• Baltimore, MD $122,950 median
• Tampa, FL $101,560 median
• Orlando, FL $91,800 median
• Raleigh, NC $103,380 median
• Kansas City, MO $91,980 median
• Pittsburgh, PA $80,440 median

Frequently asked questions

Do we need Kubernetes?

Probably not if you run a handful of services with a small team, because a managed container service will do the job with a fraction of the operational surface. It becomes worth it when you have many services, several teams needing to deploy independently, hybrid or multi-cloud requirements, or workloads that genuinely need sophisticated scheduling. The question that settles it is who will operate the cluster at three in the morning.

Should we run our own control plane?

Almost certainly not. Managed control planes from the major cloud providers remove the hardest operational work for a modest cost, and running your own is justified only by specific regulatory or infrastructure constraints. Teams that do it without such a reason spend a great deal of engineering time on something that is available as a product.

Why do our pods keep restarting?

The two most common causes are memory limits set too low, so the process is terminated under load, and health checks that are too aggressive, so a slow-starting service is killed before it is ready. Both present as application instability and neither is an application bug. Checking the previous container's exit reason usually identifies which.

Are Kubernetes secrets secure?

Not by default, and this surprises people regularly. They are base64-encoded rather than encrypted, and anyone with read access to the namespace can read them. Enable encryption at rest, restrict access properly, and for anything genuinely sensitive pull from an external secret manager at runtime rather than storing it in the cluster.

How often do we have to upgrade?

Several times a year, because the support window for each version is short. This is a real ongoing commitment and one of the honest costs of adoption. Estates that fall behind face upgrades that cross multiple versions with removed APIs, which is considerably harder than staying current.

Why is our cluster so expensive?

Usually over-provisioned resource requests, because requests reserve capacity whether or not it is used. A cluster full of workloads requesting far more than they consume pays for idle capacity on every node. Comparing requested against actual usage per workload is typically the single highest-return exercise available on a cluster nobody has reviewed.

Can our developers deploy without learning Kubernetes?

They should be able to, and if they cannot then the platform work is unfinished. The point of platform engineering is to give product teams a simple path to deploy and observe their services without needing cluster expertise. If every deployment requires a specialist, the cluster has become a bottleneck rather than an enabler.

Should stateful workloads run on Kubernetes?

They can, and for databases specifically the honest answer is usually to use a managed service instead. Running a database on Kubernetes means owning storage, backup, failover and upgrades yourself, which is exactly the work a managed database removes. Do it when there is a specific reason, not for architectural symmetry.