Should you run Kubernetes yourself or use a managed service?
Running Kubernetes yourself means your team owns the control plane: three minor version upgrades a year, certificate renewal, etcd backups and restores, security patches and a high-availability design. A managed service takes that work over for a per-cluster fee, while you keep responsibility for workloads and usually for some of the node work. Self-managed makes sense when you need control the managed offerings do not give you, such as air-gapped sites or a specific distribution; otherwise managed is the default.
What self-managed Kubernetes asks of you
The work is easier to judge as a task list with frequencies than as “operational overhead”.
| Task | How often | Why it cannot be skipped |
|---|---|---|
| Minor version upgrades | About three times a year | Kubernetes ships about three minor releases a year, and each gets roughly one year of patch support. Falling behind means running versions without CVE fixes. |
| Patch upgrades | About monthly | Patch releases ship on a typical monthly cadence with security and bug fixes for the three maintained minor versions. |
| Certificate renewal | At least yearly | Client certificates generated by kubeadm expire after one year. kubeadm renews them during control plane upgrades, so a cluster that skips upgrades for a year loses API access. |
| etcd backups and restore drills | Backups daily or more, drills regularly | etcd holds all cluster state. The etcd recovery guide depends on snapshots you have already taken, and an untested restore procedure fails when you need it. |
| OS and component patching | Continuous | Node operating systems, container runtimes and control plane binaries all receive CVE fixes on their own schedules. |
| High availability design | Once, then maintained | A production control plane runs three or five etcd members across failure domains, plus load-balanced API servers. |
| Add-on upkeep | Each upgrade | The network plugin (CNI), storage drivers (CSI), ingress or Gateway controller, CoreDNS and metrics components each have their own version compatibility with Kubernetes. |
Upgrades are the task that grows over time. Each minor version removes deprecated APIs, so every upgrade needs a check of your manifests and Helm charts, plus a compatible version of every add-on. The steps are covered in how to upgrade a Kubernetes cluster safely.
Tools reduce the effort without removing the responsibility. kubeadm, Kubespray, k3s, Talos and Cluster API automate installation and upgrades, but someone still decides when to upgrade, watches it run and fixes it when it stalls. The Cluster API explainer shows how far that automation goes.
What a managed service takes over
A managed service operates the control plane: the API server, etcd, scheduler and controllers. It handles their high availability, backups, certificates and patches, and it upgrades the control plane on a schedule you influence through release channels or maintenance windows. Depending on the service, it also manages node images, node upgrades or the entire node lifecycle. See what managed Kubernetes is for the levels.
It does not take over your workloads. Manifests, Helm releases, RBAC, network policies, observability, application backups and on-call for your services stay with you on every managed offering.
Trade-offs
| Factor | Self-managed | Managed |
|---|---|---|
| Control | Any distribution, version, flags, network plugin and etcd configuration | The provider’s supported versions, defaults and add-ons |
| Direct cost | No control plane fee; you pay for control plane machines and your team’s time | A per-cluster fee, typically on top of node costs |
| Upgrade pace | You decide, and you carry the risk of falling behind | The provider sets the window and upgrades automatically at end of support |
| Compliance | Full visibility of every component; you produce the evidence | The provider’s certifications cover the control plane; you cover the rest |
| Disconnected sites | Works fully air-gapped | Needs network connectivity from nodes to the provider’s control plane |
| Failure handling | Your team diagnoses control plane failures | The provider does, under its SLA |
Self-managed is the stronger choice when a site has no outbound connectivity, when regulation requires every component to run on infrastructure you operate, or when you need a distribution or configuration no provider offers. It also suits teams that already run Kubernetes platforms as a product. For a lightweight self-managed option, see what k3s is.
Managed is the stronger choice when Kubernetes is a means to run applications rather than the product itself. The control plane is the part where mistakes are hardest to undo: a lost etcd without a backup means rebuilding the cluster.
The middle ground: managed control plane, your own nodes
The two options are not exclusive. Several services run the control plane for you while the nodes stay on infrastructure you choose, including your own servers or a low-cost cloud. Upgrades, certificates and etcd stop being your problem, while node hardware, location and price stay under your control. This setup is common for teams that started with self-managed k3s or kubeadm on providers such as Hetzner and want to drop the control plane work without moving their nodes; the Kubernetes on Hetzner guide compares the self-managed tools used there.
Cloudfleet as a managed control plane for your own nodes
Cloudfleet Kubernetes Engine operates the control plane, including upgrades and data store backups, while nodes run in your cloud accounts or as self-managed nodes on your own Linux servers in the same cluster. The shared responsibility model lists which tasks stay with you, and the Hetzner migration page covers moving from self-managed k3s, Cluster API or Talos.