Ask them what happens to your pods when a node loses power, and wait for a number. Someone who has run a cluster will tell you the pods sit exactly where they are for the better part of six minutes before Kubernetes starts replacing them, because that is what the stock defaults do. Someone who has only built clusters will say Kubernetes self-heals.
That one question sorts most of the field, and it is the cheapest interview you will ever run. Hiring a Kubernetes consultant in Kenya is hard for an ordinary reason: the market is small, every CV says Kubernetes, and the title Kubernetes expert is self-assigned. CloudSpinx runs managed Kubernetes for businesses in Kenya and across East Africa, on EKS, AKS and GKE and on metal in Nairobi facilities, and the most common way that starts is inheriting a cluster somebody else built. Which puts us at the wrong end of this decision. We see what the hiring choice cost, about a year later.
The number, since you should check it rather than take my word: the control plane waits out a 50 second grace period before it marks the node NotReady, and Kubernetes then adds a 300 second toleration to your pods unless you set one yourself. Five minutes fifty, on a default install, before anything moves.
Design, build and run are three different hires
Most of what we get called in to fix is not incompetence. It is that three jobs were bought as one and delivered by whoever was cheapest at the first of them.
Design is days of work and almost none of it is reversible. Pod CIDR, node sizing, how many clusters you are going to have, which storage sits behind your databases: change any of those later and you are rebuilding, not editing. Build is weeks. Run is forever, and it is where the money and the risk actually live.
- upstream still ships fixes
- no fix will ever arrive
kubeadm upgrade renews every certificate as a side effect, which is why teams that upgrade on schedule never learn this deadline exists, and teams that do not meet it at the worst possible moment.
That certificate deadline is the one nobody sees coming. kubeadm generates client certificates that expire after one year, and kubeadm upgrade renews all of them as a side effect. So a cluster built well and then left alone stops working on its own schedule, roughly twelve months in, and whoever inherits it gets to learn Kubernetes and certificate rotation on the same evening. Upstream patch support runs about fourteen months per minor release, twelve standard plus two of maintenance mode, so the two deadlines land close enough together to arrive as one bad week.
Ask which of the three jobs the consultant is actually selling, then ask what happens on the last day of the build. A good answer names the runbooks, the upgrade rehearsal and who holds the pager afterwards. A bad answer is a handover meeting.
What "we support Kubernetes" turns out to cover
Three different kinds of supplier say that sentence, and they mean three different things by it.
The gap is structural rather than anyone behaving badly. A reseller is paid for capacity and a development shop is paid for features, so neither has a commercial reason to hold a pager for etcd.
The middle band is the hire. It is also the one that gets skipped, because the top and the bottom of that stack are easy to buy and the middle is the part nobody wants to own out of hours. If a prospective consultant's answers are all pipelines and deployments, you are talking to the top two layers, which is valuable work and closer to what our CI/CD and delivery practice does than to running a cluster.
A reseller relationship is fine for what it is. It buys capacity and a bill. If the honest answer for your workloads turns out to be a managed cloud rather than a cluster at all, that is a cloud consulting conversation and a much cheaper one.
Three questions that find the real Kubernetes expert
"Which version are you running in production today?" Someone who operates clusters answers with a minor release and an opinion about it. Someone reciting from a course answers with "the latest".
"Show me a cluster you upgraded, not one you built." Building is a weekend. Taking a live cluster with stateful workloads across two minor versions without losing a PersistentVolume is the job you are hiring for.
"What would you refuse to put on Kubernetes?" Anyone who says nothing has not run one in production. A real answer names things: the application that writes to local disk and expects it to survive, the licence pinned to a hardware identifier, the vendor who supports their software on one named operating system and nothing else.
Kubernetes consulting rates, and why the cloud bill is the wrong starting point
The control plane is nearly free. AWS and Google both publish USD 0.10 per cluster per hour for a managed one, about USD 73 a month. That figure is not what a cluster costs. The nodes underneath cost several times more, and the people cost more than the nodes.
So a quote should break along the three jobs rather than into hours: design as a fixed piece of work, the build priced per cluster, and running it as a monthly figure driven by node count, whether anything is stateful, and how many hours a day somebody has to be reachable. Ask for it in that shape. A consultant who cannot split a quote that way is selling you a body rather than a service.
Then look hard at the cheapest quote in the pile. It is nearly always a build quote with the run silently left out, and the run is the expensive half.
Where being in Kenya changes the answer
Two things about the geography are real. Most of the rest is noise.
The first is that AWS, Azure and Google run no region in this country. A managed cluster puts your control plane in Johannesburg or Cape Town and every API call crosses a border. For most workloads that is fine and the paperwork is straightforward.
Where the Data Protection Act, a regulator or a client contract fixes where personal data sits, it is not fine, and the answer becomes a self-managed cluster on hardware in a Nairobi facility or a split estate. Self-managed is the harder hire by some distance, because load balancing and storage stop being checkboxes and become things you own.
The second is that when a disk dies, somebody has to be in the building. Remote-only contractors are excellent right up to the point where the fault is physical. Our own commitment is a one hour P1 response around the clock and same-day on site in Nairobi, and no remote-only contract can write that second half. Ask whoever you are considering what their answer is when the fault is a dead NIC in a rack at 2am.
The reference call, and the one question worth asking on it
Ask for a reference, then ask that reference one thing: what broke after the consultant left, and who fixed it.
Not whether they were happy. Everyone says they were happy. That question tells you whether the handover was real, whether the runbooks existed, and whether the cluster was built to be operated by somebody other than the person who built it. Which is the only kind worth paying for, and it is what we hold ourselves to when we write a design: everything we produce should be executable by any competent engineer, including one who does not work for us.
If you want a second opinion rather than a supplier, that is a piece of work on its own. Send the shape of your workloads and you get a scope and one monthly figure back, with no obligation attached: the scoping form takes a couple of minutes, or WhatsApp +254 713 403 044 if you would rather just describe it.