Home / Insights / You Don't Own a Kubernetes Platform Until You Own the Layer Beneath It
Platform Engineering 6 min read

You Don't Own a Kubernetes Platform Until You Own the Layer Beneath It

Running self-managed Talos Kubernetes on Nutanix, with no cloud provider under it, changed how I design platforms on managed clouds too. Here's what the layer beneath teaches you.

kubernetestalosnutanixplatform-engineeringprivate-cloudgitops

Most Kubernetes platform teams I meet have never had to think about etcd. Or the OS on the node. Or what happens to a control plane when the hypervisor underneath it loses a host at 3pm on a trading day.

That’s fine. GKE and EKS exist so you don’t have to. But it does mean a lot of “platform ownership” is ownership of the top half of the stack, with a very competent landlord below.

For the last year I’ve owned the whole thing. Self-managed Talos Kubernetes on Nutanix on-premises (with a GCP leg for the same client, a securities brokerage in Indonesia), about 100 applications, no managed control plane anywhere. It changed how I think about platforms, including the managed ones.

What “the layer beneath” actually contains

Cluster lifecycle: upgrades of the OS and the control plane are mine, on a schedule I set, with a rollback I’ve tested. Storage: which class, backed by what, with what failure mode. Networking: the CNI, ingress, and the physical reality behind the load balancers. IAM: who can talk to the API server, from where, with which certificate. Node enrolment: how a new machine becomes a node without a human typing anything.

On a managed service each of those is a checkbox. On bare metal each is a design decision with an on-call consequence.

ConcernManaged (GKE, EKS)Self-managed (Talos on Nutanix)Who gets paged
Control-plane upgradesProvider, on their scheduleYou, on a schedule you rehearseYours either way — the GKE SLA covers availability, not your workload’s behaviour during an upgrade
Node OSProvider image, patched for youDeclared config, node rebuilt to change itYours; Talos has no shell, so “just fix it” is not an option
Node enrolmentManaged node poolsMachine classes; a tagged VM enrols itselfYours, and it is the difference between a fleet and a spreadsheet
Storage failure modesDocumented, abstractedYours to choose and to characteriseYours in both cases, but only visible in one
Ingress and TLS terminationAnnotation on a ServiceExplicit: every hop, every client IPYours, discovered during an incident if you did not draw it first
Disruption budgetsYoursYoursYours — a misconfigured PodDisruptionBudget stalls a node upgrade on any platform

The right-hand column is the point. Several rows are yours on a managed service too; the managed service just makes it easy not to notice until the upgrade stalls.

Three things it forces you to get right

Immutability stops being a slogan. Talos has no shell. You can’t SSH in and “just fix it”. Every node is built from a declared config, and if it’s wrong, you rebuild it. That’s uncomfortable for a week and then it’s the only sane way to run a fleet. We later moved to Omni machine classes: a VM created on Nutanix with the right tags enrols itself into the cluster. Static VMs, gone. Manual node management, gone.

Upgrades are a product feature you ship to yourself. With no provider doing quarterly control-plane bumps for you, you either build a boring, rehearsed upgrade path or you fall three minor versions behind and get stuck. We chose boring.

Traffic management is yours end to end. We migrated the platform from NGINX Ingress to the Kubernetes Gateway API. On a managed cloud that’s often “switch the annotation”. Here it meant understanding exactly which hop terminates TLS, which hop sees the real client IP, and which one you’ll be debugging when a partner’s requests vanish.

The part that transfers back to managed cloud

Once you’ve owned the bottom layer, you read managed offerings differently. You ask what the SLA covers and what it quietly excludes. You notice which failure modes are yours even on GKE (misconfigured PodDisruptionBudgets during a node upgrade, for one). You stop treating “the provider handles it” as an answer and start treating it as a boundary you should be able to draw on a whiteboard.

That’s the whole argument, really. A platform team that has never owned the layer beneath is renting confidence. Renting is often the right call. But know that it’s a rental, and know what’s in the lease.

Common questions

Short, direct answers to what people actually ask about this.

What is the layer beneath a Kubernetes platform?

It is everything a managed service normally handles for you: cluster lifecycle and control- plane upgrades, the node operating system, storage classes and their failure modes, the CNI and ingress path, API-server access control, and how a new machine enrols itself as a node without a human typing anything.

Why run self-managed Talos Kubernetes instead of GKE or EKS?

Regulatory or latency requirements can force workloads on-premises, where no managed control plane exists. Talos was chosen for its immutable, API-driven, shell-less design, which reduces the attack surface in a regulated environment. It is more work than GKE; the trade is control and auditability.

What does owning the bare-metal layer teach you about managed Kubernetes?

You read the SLA differently — asking what it covers and what it quietly excludes. You notice which failure modes stay yours even on GKE, misconfigured PodDisruptionBudgets during a node upgrade being one. The provider handling it stops being an answer and becomes a boundary you can draw.

Discussion