Hire Kubernetes Developers in India
Hire Kubernetes developers in India who have carried a pager for a cluster they built, not only passed an exam about one. You get an engineer who joins your rotation, owns your upgrade calendar and works an overlap window agreed in writing before day one.
What Does a Kubernetes Engineer Actually Do All Week?
Very little of it is writing YAML. That is the part everyone pictures, and it is maybe a tenth of the job. The rest is judgement about a distributed system that will keep running whether or not anyone is paying attention to it.
A normal week for a Kubernetes engineer on a mid-sized platform looks roughly like this. Monday, an application team files a ticket because their pods are being killed and restarted overnight. It turns out to be an OOMKill, exit code 137, because the memory limit was copied from another service two years ago and this one now caches more. Tuesday, a node group upgrade is planned, and half the day goes on checking which workloads have PodDisruptionBudgets that will block a drain. Wednesday, someone in finance asks why the cloud bill grew by a fifth and the answer is three dev namespaces nobody deleted plus a load balancer per service. Thursday, a new team wants to onboard and the real work is deciding what they are allowed to do without asking. Friday is usually documentation, or the incident review from whatever went wrong on Wednesday night.
If you want one sentence for the job description: this person keeps the platform boring so your product engineers can be interesting.
Keeping workloads healthy
Right-sizing requests and limits so pods stop getting evicted and nodes stop sitting half empty. Reading kubelet eviction events. Deciding when a CrashLoopBackOff is the application team's problem and when the platform caused it. Chasing CPU throttling that only shows up under load because someone set a limit that the CFS quota enforces harder than they expected.
Owning the upgrade calendar
Kubernetes ships minor releases several times a year and each one is supported with patches for a limited window, so a cluster that is never upgraded eventually falls off the end of support and starts costing more or stops getting fixes. Someone has to own that calendar, test API removals ahead of time, and drain nodes without taking the product down.
Being on the other end of the alert
Writing alerts that fire on symptoms your users would notice rather than on every CPU spike. Deleting the alerts that page people at 3am and get acknowledged without action, because those are the ones that train a team to ignore the pager. Then writing the runbook so the next person does not have to reconstruct the reasoning.
The Gap Between a Tutorial and a Cluster That Has Been Live for Three Years
Kubernetes is unusual in how easy it is to look competent. A weekend with kind or minikube gets you deployments, services, an ingress and a working demo. Everything in that demo behaves. Nothing has been running long enough to accumulate the problems that make the job hard.
What separates the two is exposure to time and to failure. A cluster that has been live for three years has certificates that expired once, an etcd database that grew until someone had to defragment it, a node pool that was created by hand before Terraform existed in the org and has drifted ever since, at least one namespace stuck in Terminating because a finalizer points at a controller that was deleted, and a CRD from a tool the team stopped using but never uninstalled. None of that appears in a tutorial.
There is a second gap that matters more for hiring: the difference between someone who deploys onto a cluster and someone who runs one. An application developer who writes a Deployment manifest and a Helm values file is not a Kubernetes engineer, and asking them to own a control plane usually ends with a very bad month for everyone. The person you want has debugged the layer underneath: CNI behaviour, kube-proxy, scheduling, storage attachment, admission control, the API server itself.
You can hear the difference in about ten minutes. Ask what happens when a pod stays in Pending. Someone who has read about it says the scheduler could not place it. Someone who has lived with it starts listing causes in the order they would check them: no node with enough allocatable CPU or memory, a taint with no matching toleration, a nodeSelector or affinity rule that matches nothing, a PersistentVolumeClaim that cannot bind because the volume lives in a different availability zone from every candidate node, or the cluster autoscaler being unable to add capacity because the instance type is out of stock in that zone. Then they tell you they would read the Events on the pod first, because the scheduler usually says exactly why.
How Do You Screen a Kubernetes Engineer in One Hour?
Not with trivia. Anyone can memorise the fields of a StatefulSet. These are the questions we use, what the shallow answer sounds like, and what the answer from someone who has actually operated a cluster sounds like.
Tell me about an upgrade that went wrong
The single most useful question on the list. Weak answers stay abstract and describe the documented upgrade procedure. Strong answers have a shape: what version they were coming from, what they missed in the release notes, and how they found out. Good candidates mention checking for removed API versions with something like kubent or pluto before touching anything, and they know that a PodDisruptionBudget set to minAvailable equal to the replica count will block a node drain indefinitely while looking like a hung command.
A pod is stuck in Pending. Walk me through it
Listen for order of operations, not completeness. Events on the pod, then node allocatable against the pod's requests, then taints and tolerations, then affinity and topology spread constraints, then the PVC. The detail that separates operators from readers is the storage case: an EBS volume can only attach to a node in its own availability zone, so a pod with an existing PVC cannot be scheduled anywhere else, and no amount of adding nodes in other zones will help.
You get paged at 3am for OOMKilled. What now?
The weak answer is raise the memory limit. It works, so it is tempting. The better answer asks whether the container has a genuine leak, whether the limit was ever based on measurement, whether the JVM or Node heap is configured to respect the cgroup limit rather than the host's memory, and whether the correct immediate action at 3am is to restore service and investigate in daylight. A candidate who says they would bump the limit to stop the paging and open a ticket to find the real cause is being sensible, not lazy, and should say so out loud.
A namespace has been Terminating for two hours
This is a small question that reveals a lot. The cause is almost always a finalizer on a resource inside the namespace, waiting on a controller that no longer exists, often left behind by an uninstalled operator. The answer you want includes finding which resource holds the finalizer rather than immediately editing the namespace object to strip finalizers, because force-removing it can orphan cloud resources such as load balancers that then keep billing you quietly.
Where did the money go?
Cost is where a lot of Kubernetes engineers are thin, and it is often the reason you are hiring. Good candidates talk about the gap between requests and actual usage, idle node capacity caused by requests nobody revisited, one cloud load balancer per Service instead of shared ingress, cross availability zone traffic charges between chatty services, log volume, and orphaned PersistentVolumes left after a namespace was deleted. Naming OpenCost or Kubecost is a fine signal. Explaining what they changed after looking at the numbers is a better one.
What would you refuse to run in a cluster?
An opinion question, and the point is that they have one. Plenty of experienced engineers will not run the primary transactional database inside Kubernetes without a strong reason, even with a mature operator, because the failure modes are unforgiving and managed database services exist. Others will happily do it and can explain their backup and failover story. Either is acceptable. Having no view at all, after several years in the job, is not.
Explain a decision you got wrong
Not a culture-fit softball. Someone who chose a service mesh they later ripped out, or wrote a custom operator that a Helm chart would have covered, has been close enough to consequences to learn something. We ask what the symptom was that made them change their mind. An engineer who has never regretted an architectural choice has usually never had to live with one.
Show me something you have written for humans
A runbook, a post-incident write-up, an internal RFC arguing for or against something. Cluster work is written work. If your engineer sits eight and a half hours ahead of you, the quality of their writing decides how much of your day is spent asking follow-up questions. We read a sample before anyone is put forward.
Junior, Mid, Senior, Staff: What the Ladder Means for This Skill
Titles travel badly between companies, so here is what we mean when we put someone in front of you. Kubernetes seniority tracks blast radius more than years. The question is how much can go wrong when this person acts alone.
Junior
Comfortable with kubectl, can read a Deployment and a Service, can follow a runbook and raise a hand when reality does not match it. Deploys under review. Does not touch cluster-scoped resources, RBAC or node pools without a second pair of eyes. Genuinely useful for a platform team that has too much toil and not enough hands, and a bad idea as your only infrastructure person.
Mid
Owns a workload end to end, writes and reviews Helm charts or Kustomize overlays, debugs most application-level pod failures alone, and can run a node group upgrade with a plan someone senior has read. Usually still learning the networking layer properly. This is the level where people know what a NetworkPolicy is and have not yet found out how differently Calico and Cilium behave when you write a sloppy one.
Senior
Can be handed a cluster they have never seen and produce a defensible assessment in a week. Owns the upgrade path, the CNI choice, the ingress strategy, RBAC design and the alerting model. Debugs across layers, so a slow request gets traced from the client through ingress, mesh, kube-proxy and the pod rather than being handed back to the application team. This is the level most teams actually need and often try to save money on.
Staff or principal
Decides whether you should be on Kubernetes at all, and for which workloads. Sets the multi-cluster and multi-region shape, the tenancy model, and the boundary between what the platform provides and what product teams own. Writes the standards other engineers work inside. You need this level less often than vendors suggest, and when you do need it, a few hours a week of it goes a long way.
One practical note on the ladder. The most common staffing mistake we see is hiring two mid-level engineers instead of one senior because the headcount maths looks better. For cluster work that usually backfires, because the failures you are trying to prevent are exactly the ones that require judgement rather than throughput. Two people who both need review do not add up to one person who can give it.
The Skills That Travel With Kubernetes
Nobody is only a Kubernetes engineer, and a CV that lists nothing else is a warning sign rather than focus. Kubernetes sits on top of Linux and networking and underneath everything your product does, so the surrounding skills decide how useful the hire is in practice. Here is what we check for and why it matters to you.
Linux, properly
Containers are Linux processes with namespaces and cgroups around them. An engineer who understands cgroup v2 memory accounting, file descriptor limits, conntrack table exhaustion and how the kernel decides what to kill under memory pressure will solve problems that look like Kubernetes bugs and are not. This is the skill that most reliably predicts whether someone can debug the weird stuff.
Networking
Pod networking, service routing through kube-proxy in its iptables or IPVS modes, DNS resolution through CoreDNS and its search domain behaviour, and how your CNI allocates addresses. On EKS the VPC CNI hands pods real VPC addresses, which is elegant until a subnet runs out of them or an instance type caps how many network interfaces it can attach. That is a networking problem wearing a Kubernetes costume.
Infrastructure as code
Terraform or OpenTofu for the cluster and everything around it, plus a clear position on what belongs in code and what belongs in the cluster's own controllers. Ask a candidate what they do about drift. Ask whether they have ever had a state file conflict take down a deploy. The answers tell you whether their infrastructure is reproducible or merely documented.
Observability
Prometheus and its query language, Grafana, log aggregation with something like Loki or an existing vendor, distributed tracing through OpenTelemetry, and the discipline to alert on user-visible symptoms rather than every metric that has a threshold. The clusters that hurt least are the ones where the engineer knows which four dashboards actually get opened during an incident.
GitOps and delivery
Argo CD or Flux, Helm and Kustomize, and a view on which to use where. Helm's templating gets ugly at scale and Kustomize struggles with third-party charts, so most mature setups use both and are deliberate about the split. If a candidate is dogmatic about one, ask what they do when a vendor ships only a chart.
Go, sometimes
Not required for most roles, and essential for a few. If you need custom controllers, an operator for an in-house stateful service, admission webhooks or contributions upstream, you want someone who writes Go rather than someone who reads it. If you do not need those, do not filter on it and shrink your pool for nothing. Where the need is real, our Go developers in India and the Kubernetes side of the team usually overlap.
Security deserves its own line rather than a card. Kubernetes defaults are permissive by design, and a competent engineer knows the specific gaps: Secrets are base64 encoded in etcd rather than encrypted unless you turn encryption at rest on, RBAC bindings accumulate until someone audits them, PodSecurityPolicy was removed and replaced by Pod Security Admission so older clusters often have nothing enforcing pod hardening at all, and container images pulled from public registries deserve scanning before they run. Policy engines such as Kyverno or OPA Gatekeeper are the usual answer, image scanning with Trivy the usual companion. Ask a candidate which of those they have actually enforced in production rather than installed.
Kubernetes Engineer, DevOps Engineer, SRE or Platform Engineer?
These four titles overlap enough that job adverts use them interchangeably, which is how teams end up hiring the wrong one. The distinction that matters is not the tooling. It is what the person is accountable for.
A Kubernetes engineer is accountable for the cluster: it runs, it upgrades, it schedules work correctly, it does not cost more than it should. Hire this role when the cluster itself is generating your incidents and your CI pipeline is fine.
A DevOps engineer is accountable for the path from a commit to production. Build pipelines, artefact registries, environment promotion, release process, secrets delivery. Plenty of DevOps engineers know Kubernetes well, but their centre of gravity is delivery, not the runtime. If your problem is that deploys are slow and flaky rather than that pods are dying, this is your hire, and our DevOps developers in India page covers that role directly.
An SRE is accountable for reliability as a measured thing: service level objectives, error budgets, incident response, and the argument about whether to ship a feature or spend the sprint on stability. The role came out of Google's operations practice and works best when there is enough traffic for the numbers to mean something. If your team has no SLOs and no agreed definition of what "down" means, an SRE hire is often more valuable than another pair of hands on the cluster. Our SRE guide unpacks how the practice actually runs.
A platform engineer is accountable for the internal product that other engineers use: the golden path, the templates, the self-service tooling, the docs. Success is measured by how rarely a product team needs to ask them anything. This is the right hire when you have five or more teams deploying and each one has invented its own conventions.
In a small company one person covers all four and it works fine. Past roughly forty engineers it stops working, and the usual symptom is that the person who owns the cluster spends their week unblocking other teams and never gets to the upgrade. If that is your situation, the answer is not a more senior single hire. It is a second person and a clear split of what each owns.
Which Cluster Are You Actually Running?
The right hire changes depending on where your cluster lives. These are the shapes we see most often and what each one demands from the engineer.
Amazon EKS
The most common by a distance, and the one with the most footguns that are not really Kubernetes. IAM Roles for Service Accounts or the newer pod identity mechanism, the VPC CNI and its address consumption, node group upgrade ordering, EBS volumes tied to one availability zone, and the fact that a managed control plane does not upgrade your nodes for you. Once a version falls out of standard support AWS moves it into extended support at a higher cluster fee, so an unmaintained cluster becomes a line item as well as a risk. An EKS-heavy hire should also be fluent in AWS generally, which is why this role and our AWS developers in India often draw on the same skill set.
Google GKE
Generally the smoothest managed experience, with Autopilot removing node management entirely at the cost of some control and some flexibility about what you can run. Release channels do a lot of the upgrade thinking for you. Where GKE teams get caught is Workload Identity configuration, the difference between the standard and Autopilot resource models, and the assumption that because upgrades are automatic they are also trouble-free. They are automatic. The API removals still break your manifests.
Azure AKS
Common in organisations already committed to Microsoft identity and networking. The specifics that matter are the CNI choice between kubenet and Azure CNI and what each does to your address space, integration with Entra ID for cluster access, node image versus Kubernetes version upgrades being separate concerns, and Azure Policy as the enforcement layer. An engineer who has only run EKS will be productive here in a fortnight, but do not pretend the first fortnight is free.
OpenShift, bare metal and the edge
OpenShift is Kubernetes with opinions, a different security context default that breaks charts written for vanilla clusters, and its own routing layer. Bare metal means you own etcd, load balancing, storage and the control plane, which is a materially different and harder job. Lightweight distributions such as k3s show up in edge and on-premise deployments where the cluster runs somewhere nobody visits. Each of these narrows the candidate pool sharply, so tell us early if it applies to you.
One trend worth knowing about when you write the brief: the Gateway API is gradually taking over from Ingress for traffic routing, and service meshes have moved away from injecting a sidecar into every pod. If your cluster was built three or four years ago, some of what your incoming engineer knows will be newer than what you are running, and part of their first quarter is deciding what is worth changing and what is fine as it is.
Three Situations Where People Call Us
The team drowning in pager noise
A payments company with about thirty engineers had four people sharing an on-call rotation and every one of them was tired. The alerts fired constantly. Most were acknowledged and closed without action, because everyone had learned which ones meant nothing. The dangerous part is not the tiredness. It is that a rotation trained to ignore alerts will also ignore the real one.
The hire here is not another pair of hands to absorb pages. It is someone senior enough to delete alerts and defend the decision. The first month is inventory: every alert, how often it fired in the last ninety days, how often it led to an action. Alerts that never led to an action get removed or turned into a dashboard. What remains gets tied to something a customer would notice. Then the noisy underlying causes get fixed one at a time, usually starting with memory limits set by copy and paste and a HorizontalPodAutoscaler reacting to a metric that lags the load. Rotations that go through this usually come out with a quarter of the alerts and a team that trusts them again.
A migration to EKS with nobody to own it
A B2B software company decided to move from virtual machines to EKS. The decision was sound. The staffing was not: the migration was handed to two application developers alongside their normal work, on the basis that they had both used Docker. Nine months later they had a cluster, some workloads on it, some still on the old machines, Terraform that no longer matched reality because of manual fixes made during incidents, and no appetite to finish.
Half-finished migrations are the most expensive state to sit in, because you pay for both platforms and get the operational complexity of both. The engineer you want here has done the crossing before and will say out loud which workloads should never move. The first task is usually to reconcile Terraform with what is actually deployed, because until that is true nobody can change anything safely. Then the remaining workloads move in order of how boring they are, and the old platform gets switched off in full rather than left running because somebody might still need it.
The cluster nobody has upgraded in eighteen months
This is the most common call we get, and it is rarely negligence. The person who built the cluster left, nobody replaced them, and the cluster kept working, which is exactly the problem. Kubernetes does not fail loudly when you neglect it. It fails on the day you finally need to change something.
By eighteen months you are several minor versions behind, and you cannot skip minors on the control plane, so it is not one upgrade, it is a sequence of them. Deprecated APIs that were removed along the way are still in your manifests and in the charts of tools you installed and forgot. The node images are old enough to have accumulated kernel patches you have not taken. And the cluster autoscaler, ingress controller and CSI drivers all have their own compatibility matrices with the control plane version.
The work is methodical rather than clever. Inventory the deprecated API usage before touching anything. Upgrade a non-production cluster first, and if there is no non-production cluster then creating one is the first task. Move one minor version at a time, control plane then nodes, checking the add-ons at each step. Fix the PodDisruptionBudgets that will otherwise block every drain. Expect it to take weeks rather than days, and expect the honest estimate to be uncomfortable. Anyone who quotes you a weekend for this has not done it.
Dedicated, Embedded or Fractional
Three shapes, and the right one depends on how much of the work is ongoing and how much is a project with an end.
Full time on your platform
One engineer whose entire week is your cluster. They join your rotation, own the upgrade calendar, and are the named person when something breaks. This is the right shape when the platform needs continuous attention rather than a fix, and when you want someone who accumulates context about your particular mess.
Inside your existing team
The engineer works in your repos, your ticket tracker, your standups and your review process, reporting to your engineering manager rather than to us. Best when you already have a platform team and need to add capability to it rather than replace it. It also transfers knowledge in both directions, which matters if you intend to bring the role in-house later.
Senior time, part of a week
A few hours a week of someone senior, for teams that do not need a full-time cluster owner but do need better decisions than they are currently making alone. Typical use is reviewing an architecture before it is built, sitting in on incident reviews, and being the person your mid-level engineer can ask before they do something irreversible.
If what you want is an outcome rather than a person, that is a different conversation and a different page. Cluster builds, migrations and upgrade programmes run as scoped engagements through our Kubernetes services in India. Hiring makes sense when the work does not end.
The Timezone Arithmetic, Without the Sales Version
India runs on IST, which is UTC+5:30. That is a fixed offset with no daylight saving, so the maths is at least stable. Here is what a standard Indian working day of 09:30 to 18:30 IST actually gives you.
| Your location | Overlap with a standard IST day | What that means in practice |
|---|---|---|
| London | About five hours, roughly 09:00 to 14:00 your time | Comfortable. A morning standup and a full afternoon of overlap without anyone shifting hours. |
| US Eastern | Effectively none. 18:30 IST is around 09:00 in New York. | The Indian day ends as yours begins. Any live collaboration needs a shifted schedule. |
| US Pacific | None on a standard day | 18:30 IST is around 06:00 in San Francisco. A shifted evening schedule is the only way to get real overlap. |
| Sydney | Around three and a half hours in the Indian morning | Your afternoon is their morning. Workable with a standing early-afternoon call. |
If you are in the US and want three hours of live overlap with your morning, the engineer works until roughly 21:30 IST. That is a real cost borne by a real person, and it should be agreed in writing before anyone starts rather than assumed. Nobody sustains a shifted schedule they did not consent to, and pretending otherwise is how offshore engagements quietly fall apart in month four.
Where the offset genuinely helps: on-call
This is the part of the timezone story that is actually good news, and it is specific to infrastructure work. Cluster incidents do not respect business hours. The shift everyone hates is the overnight one.
US Eastern overnight, 22:00 to 06:00, lands at roughly 07:30 to 15:30 IST. US Pacific overnight lands at roughly 10:30 to 18:30 IST. In both cases your worst shift is an ordinary Indian working day. The engineer taking that page is awake, caffeinated, at a desk, with colleagues nearby to ask. Compare that to a local engineer woken at 3am who is alone, half asleep, and about to make a decision about your production cluster.
This is the one place where a follow-the-sun arrangement is honest rather than marketing. It does not give you round the clock coverage on its own, because someone still has to cover the Indian night, and that is a second person and a proper rotation rather than a free benefit. What it gives you is the ability to staff the hardest shift with someone who is not being woken up. We agree who is on the rotation, how handover is written up, and what the escalation path looks like as part of setting up the engagement, and the specifics get written into the agreement rather than assumed.
What to Settle Before Anyone Gets Cluster Credentials
A Kubernetes engineer needs more access than most contractors, which makes the access conversation a real one rather than a formality. These are the points worth deciding before day one instead of during the first incident.
Scope of access. Read-only to start is normal and sensible, and a good engineer will ask for it rather than resist it. Cluster-admin should be scoped, time-bounded where your tooling supports it, and tied to a named identity in your own identity provider rather than a shared credential. If you are on EKS or AKS, tie cluster access to your existing SSO and let group membership do the work.
Production change process. Decide who approves a change to a live cluster, whether that differs at 3am, and how an emergency change gets recorded afterwards. Teams that skip this end up with an undocumented fix that nobody can reverse and nobody remembers making.
Data and jurisdiction. If your workloads touch personal data, health data or payment data, the questions about where data may be processed, who may see logs, and which regulatory regime applies are questions for your counsel and your compliance team, not for a vendor page. Bring them into the first call so the answers shape the engagement rather than interrupt it later. What we can do is work inside whatever access model and data handling rules you set, and record them in the agreement before work starts.
Devices and secrets. Agree whether the engineer works on your hardware or theirs, how secrets reach a workstation, and what happens to access when the engagement ends. Secrets management inside the cluster is a separate question with real answers such as the External Secrets Operator pulling from your existing vault, and it is worth deciding early because retrofitting it is tedious.
What Goes Wrong With This Hire, and What We Do About It
Worth being direct about the failure modes, because they are predictable and most of them are avoidable.
The context problem. A Kubernetes engineer is only as good as their understanding of what your workloads do. Someone who does not know that a particular Deployment is the batch job finance depends on every month end will make a technically correct decision at the worst possible moment. We mitigate this by front-loading a documented walk through the workloads in week one, and by insisting the engineer writes down what they learn rather than keeping it in their head.
The bus factor you just recreated. Hiring one person to own the cluster solves your immediate problem and rebuilds the exact dependency that caused it. The counter is boring and effective: runbooks written as the work happens, infrastructure changes in version control rather than in a terminal, and at least one person on your side who reviews cluster changes even if they could not have written them.
Silent divergence. Working eight and a half hours apart means a wrong assumption can run for a full day before anyone catches it. Written-first working is the fix. Decisions in pull requests and documents rather than in calls, a daily written handover at the end of the Indian day, and a standing rule that anything irreversible waits for the overlap window.
Scope drift into application work. A capable infrastructure engineer gets pulled into fixing application code, because they are competent and available and the ticket is right there. It feels efficient and it means the upgrade slips again. Agree what is in scope and revisit it monthly.
If it does not work out. Handover expectations, notice arrangements and how knowledge transfer happens at the end are set in the agreement before work starts, alongside the overlap window and the access model. We would rather negotiate that with you specifically than publish a promise on a web page that may not match what you actually need. The part we will state here: losing a match does not mean losing your cluster context twice, because a different engineer is proposed within 48 hours and you are picking from a shortlist rather than accepting one name.
The Costs That Do Not Show Up in the Rate
Whatever the engineer costs, that is not what the hire costs you in the first quarter. Being honest about the rest makes your planning better.
Access provisioning is the most underestimated line. Getting a new person into your identity provider, your cloud account, your repositories, your VPN and your alerting tool routinely takes longer than anyone plans, and every day of it is paid time where the engineer cannot do the job. Teams that prepare this before the start date get a genuinely productive first week instead of a first week of tickets to IT.
Then there is the ramp. A senior engineer can assess an unfamiliar cluster in about a week, but knowing your cluster well enough to make confident changes to production takes longer, and the length depends almost entirely on how much of your setup is written down. Undocumented infrastructure is a cost you pay every time anyone joins.
There is also your own time. A remote infrastructure hire needs someone on your side who answers questions, makes decisions about trade-offs, and approves production changes. Budget a few hours a week of a senior person for the first month or two. Engagements that go badly are almost always ones where nobody on the client side had time to be the counterpart, and no amount of seniority on our end substitutes for that.
How Hiring a Kubernetes Developer in India Works With Us
Tell us what the cluster looks like
Which distribution and version, managed or self-hosted, how many workloads, whether anything stateful runs inside it, and what is currently going wrong. If your honest answer to the version question is that nobody knows, say that. It is a common answer and it changes who we put forward.
Meet candidates who match the shape
We put forward engineers whose production experience matches your situation rather than whose CV matches your keywords. Each comes with the writing sample we screened on and a summary of what they have actually broken and fixed.
Run your own technical conversation
Use the questions from this page if they help. We would rather you interrogate the candidate properly than take our word for it, and a candidate who cannot hold up under your questions should not be on your cluster.
Read-only week, then real work
The first week is inventory and questions with read access, ending in a written assessment you can disagree with. Cluster-changing work starts after that, smallest and most reversible change first, through your normal review process.
Frequently Asked Questions
Do we need a Kubernetes engineer, or would a DevOps generalist cover it?
If your clusters are managed, your workloads are stateless and your deploy pipeline already works, a DevOps generalist is usually enough. You need a Kubernetes specialist when the cluster itself has become the problem: upgrades keep stalling, pods get evicted for reasons nobody can explain, autoscaling behaves oddly, or you are running databases and queues inside the cluster. The tell is whether your incidents are about your application or about the platform underneath it.
Is a CKA or CKS certificate worth anything when screening?
More than most certificates, because the CKA and CKS are hands-on exams in a live terminal rather than multiple choice. Someone who passed the CKA can drive kubectl under time pressure and knows where things live. It still tells you nothing about whether they have handled a failed upgrade or an outage at 3am. Treat it as evidence of fluency, then screen separately for production judgement.
Can an engineer in India realistically carry the pager for a US product?
For overnight coverage the arithmetic is unusually good. US Eastern hours of 22:00 to 06:00 land at roughly 07:30 to 15:30 IST, and US Pacific overnight lands mid-morning to early evening IST. So the shift your local team hates most is an ordinary working day in India, with people awake around the on-call engineer. Daytime US coverage is the harder half and needs a shifted schedule agreed before anyone starts.
How do you check that someone has actually run a production cluster?
We ask about failures rather than concepts. Describe an upgrade that did not go to plan. Walk through the last time a pod stayed Pending and what you checked in order. Tell me about a cost line that surprised you. Candidates who have only studied answer these in the abstract and reach for definitions. Candidates who have operated a cluster give you a timeline, a wrong first hypothesis, and what they changed afterwards.
We are on EKS and nobody owns it. Where does a new engineer start?
Read-only access and an inventory first. Which version is the control plane on, how far behind are the node groups, which deprecated APIs are still in use, what has drifted from Terraform, and which alerts fire regularly and get ignored. That inventory usually takes a week and produces a ranked list you can argue with. Only after that does anyone change a live cluster, and the first change should be small and reversible.
What if we are not on Kubernetes yet and are not sure we should be?
Then say so in the first call, because the honest answer is sometimes no. A handful of services with steady traffic on managed containers rarely justifies a cluster and the operational weight that comes with it. Kubernetes earns its keep when you have many services, several teams deploying independently, spiky load, or a portability requirement. We would rather tell you that than staff a migration you will regret.