Kubernetes is open source, and running your own cluster is a legitimate choice. What is worth examining in real detail is what a production cluster asks of you on an ongoing basis — using the Kubernetes project’s own documentation and release policy as the source, not marketing claims.
Every Kubernetes version has an expiry date
The Kubernetes project maintains release branches for the three most recent minor releases. Each minor release gets roughly fourteen months of patch support: twelve months of standard support, then a two-month maintenance period, after which the series reaches end of life and stops receiving fixes.
As of September 2026, the actively maintained minor releases are 1.37, 1.36 and 1.35. Version 1.34 is in its final maintenance window and reaches end of life on 27 October 2026. Version 1.33 already reached end of life on 28 June 2026.
Falling behind is expensive, because upgrades cannot skip minor versions. The version-skew policy requires kube-apiserver to move one minor version at a time, even in single-instance clusters. A cluster still on 1.33 therefore needs four sequential control-plane upgrades — 1.34, 1.35, 1.36 and 1.37 — to become current, and each one needs its own preparation, such as confirming that your admission webhooks can handle the API versions the new server sends them.
Nodes add work of their own. In-place minor-version kubelet upgrades are not supported: each node has to be drained first. A kubelet may lag the API server by up to three minor versions, but the documentation warns that a cluster with kubelets persistently three versions behind must upgrade them before the control plane can move at all.
High availability is a design you own
A single control-plane node is a single point of failure. kubeadm’s high-availability guide describes two topologies. In the default stacked topology, every control-plane node also runs an etcd member, so losing one node loses both a control-plane instance and an etcd member; the documentation says to run at least three stacked control-plane nodes. The alternative, external etcd, separates the two but needs a minimum of three control-plane hosts plus three etcd hosts.
etcd needs a quorum — a majority of its members — to accept changes. A three-member cluster tolerates one failed member and a five-member cluster tolerates two, while adding a fourth member buys no extra fault tolerance. The Kubernetes documentation recommends an odd number of members and a five-member cluster for production.
etcd is also sensitive to the environment it runs in:
- Disk and network. etcd performance depends on disk and network I/O. Resource starvation can cause heartbeat timeouts and leave the cluster without a leader — and a cluster without a leader cannot change state, which means no new pods can be scheduled.
- Dedicated resources. The documentation advises running etcd on dedicated machines or isolated environments so its resource requirements are guaranteed, and etcd’s own FAQ highly recommends SSDs.
- Access equals root. Access to etcd is equivalent to root permission in the cluster, so ideally only the API server can reach it, protected with x509 TLS certificates.
A backup only counts once you have restored from it
The Kubernetes documentation is direct: if your cluster uses etcd as its backing store, make sure you have a backup plan for the data. In practice that means scheduled snapshots taken with etcdctl, stored somewhere that does not share a failure domain with the cluster, and a restore procedure using etcdutl that someone has actually rehearsed.
Snapshots also need careful handling, because they contain everything the API server knows. By default the API server stores resources in etcd as plain text, with no encryption at rest, unless you configure it. A snapshot of an unencrypted cluster can therefore carry your Secrets with it.
Certificates expire on a schedule
Client certificates generated by kubeadm expire after one year. kubeadm renews them automatically when you run a control-plane upgrade, so a cluster upgraded at least once a year is looked after — and a cluster that goes more than a year without an upgrade is not. You can check expiry with kubeadm certs check-expiration and renew manually with kubeadm certs renew all, which on a replicated control plane has to be run on every control-plane node.
The add-ons are separate projects with separate lifecycles
A cluster is more than its control plane. Networking, ingress or Gateway API, storage drivers, certificate management, metrics and monitoring are separate projects, each with its own release cycle, versions and end-of-life dates. On a self-hosted cluster, tracking all of them is your job.
In November 2025 the Kubernetes project announced the retirement of Ingress NGINX, one of the most widely used ingress controllers. Best-effort maintenance ended in March 2026: there are no further releases, bug fixes or security updates. Existing deployments keep working and the artifacts stay available, but any vulnerability discovered later will not be patched. In January 2026 the Kubernetes Steering and Security Response Committees described it as critical infrastructure for about half of cloud native environments and urged migration to Gateway API or another controller.
The project’s own migration guide adds a warning: Ingress NGINX has implicit behaviors, and a translation that looks correct can still cause outages. None of this is a flaw in Kubernetes. It is the normal life of a large open-source ecosystem — and exactly the work a self-hosted cluster moves onto your team.
Side by side
| Category | Self-Hosted | Kube-DC Managed Cluster |
|---|---|---|
| Version lifecycle | You track release and end-of-life dates and upgrade one minor version at a time, with about fourteen months of support per minor release | Staged, tenant-controlled upgrades: the control plane and the worker pools move separately, in steps. You still choose the target version and the timing |
| Control plane | Three or more control-plane nodes to design, secure and patch yourself | Hosted control planes run as managed pods on the platform: you get your own Kubernetes API and per-cluster PKI without operating masters |
| etcd | Quorum sizing, dedicated disks, TLS, defragmentation and monitoring are yours | A dedicated or shared datastore managed by the platform, with control-plane and etcd vertical autoscaling on by default |
| Backups | You design the snapshot schedule, the storage and the restore drills | Scheduled etcd snapshots, configured per cluster, with optional envelope encryption, and restore — self-service for single-replica datastores, assisted for multi-replica. Snapshots are stored in project S3 storage on the platform, so keep your own off-platform copy if you need one outside the platform’s storage failure domain |
| Certificates | One-year kubeadm certificates, renewed on upgrade or by you | Per-cluster PKI and etcd TLS certificates provisioned automatically with the cluster |
| Worker nodes | You provision, image, patch and replace nodes | Worker pools sized per pool (CPU, memory, disk, image), with autoscaling bounds per pool |
| Metrics API | You install and maintain metrics-server | Pre-installed and working in our own August 2026 end-to-end test |
| Time to first cluster | Hours to days of setup, plus ongoing maintenance | Created from a project in the portal or with a single manifest; the platform documentation describes provisioning in minutes |
| On-call | Your team | 24/7 email and ticket support with a 4-hour resolution target (MTTR), included in the price |
| What stays yours | Everything, from hardware to workloads | Your workloads, access control and the add-ons you install inside your cluster — it is a full, tenant-administered Kubernetes cluster |
When self-hosting is the right call
If your team already runs etcd in production, follows Kubernetes and add-on release notes, rehearses restores and has on-call cover, self-hosting is a reasonable extension of existing practice. It is also the right choice when you need control that a managed service cannot give, such as custom control-plane configuration or a fully isolated environment. For a team without that capability already in place, every section above becomes new, continuing work.
Sources
- Kubernetes releases and patch support policy
- Kubernetes patch releases: support period
- Kubernetes version skew policy
- kubeadm: options for highly available topology
- Operating etcd clusters for Kubernetes
- etcd FAQ: cluster size and failure tolerance
- Encrypting confidential data at rest
- Certificate management with kubeadm
- Ingress NGINX retirement: what you need to know
- Ingress NGINX: statement from the Steering and Security Response Committees
- Kube-DC platform datasheet
See the platform
Cloud Acropolis Kube-DC gives you your own tenant-administered Kubernetes clusters — hosted control planes, worker pools and staged upgrades — on dedicated vCPU, Ceph-backed NVMe storage, a dedicated public IPv4 and S3-compatible object storage. You order and manage everything in a self-service portal, with 24/7 email and ticket support and a 4-hour resolution target included. Every package includes nested Kubernetes clusters, and shared GPU is available as an option.
Explore Kube-DC Kubernetes