You have multiple control-plane nodes, spread-out workloads, and backups in another region.
But every complicated production problem still ends with the same message: "Ask the engineer who set up Kubernetes."
That's a single point of failure too. It just doesn't show up in kubectl get nodes.
Infrastructure redundancy is not operational redundancy
Kubernetes can reschedule workloads automatically. It cannot automatically explain why the ingress configuration has a strange exception, which secrets are rotated manually, or how to rebuild an identity integration after a major outage.
When important operational knowledge exists only in someone's head, the company depends on that person for incident recovery, changes, and even basic access.
The engineer doesn't have to leave the company for this to matter. They may be asleep, unavailable, in another time zone, or working on a more urgent incident.
The five questions I'd ask the team
- Can a second engineer deploy and roll back a production service without private instructions?
- Can someone other than the cluster creator recover administrative access through an audited, approved process?
- Is there a tested procedure for cluster upgrades and emergency certificate rotation?
- Can the team restore one stateful application without improvising?
- Is the actual platform configuration reproducible, or does it depend on historic manual changes?
If the answer is "we think so," treat it as untested.
Fix the dependency without creating a documentation graveyard
Start with the five operations you most need during an incident: deploy, roll back, investigate a major outage, restore data, and recover access. For each, write a short runbook with preconditions, commands or dashboards, expected results, and escalation contacts.
Then ask a second engineer to execute it in a non-production environment. Anything they have to ask the original owner is missing documentation.
Make infrastructure reproducible through reviewed infrastructure-as-code and GitOps, but remember: a Git repository without maintained credentials, access procedures, and recovery instructions is not a complete handover.
A useful test: the two-week absence drill
Pretend the platform's main owner is unavailable for two weeks. No private messages, no special exceptions. Can the rest of the team deploy, respond to incidents, handle access requests, and operate the cluster?
You don't need to actually exclude anyone from an active incident. Run the exercise with safe boundaries and document what breaks.
The goal isn't to make everyone a Kubernetes specialist. It's to make the platform operable without a hero.
Discussion: Is the biggest operational risk in your company a failed component—or knowledge concentrated in one person?
If you're inheriting a cluster or preparing a handover, Kubernetes consulting can help turn undocumented infrastructure into a system the team can operate. Request a discovery call.