Managed vs self-managed Kubernetes — the fundamental trade-off

Managed vs self-managed Kubernetes is one of the most fundamental architecture decisions. This lesson walks the responsibility split, the trade-offs, the hybrid approach, and the operational discipline.

The responsibility split

flowchart LR
    A[Kubernetes responsibilities] --> B["Managed: EKS/AKS/GKE"]
    A --> C["Self-managed: kubeadm"]
    B --> B1[Control plane]
    B --> B2[etcd]
    B --> B3[Upgrades]
    B --> B4[Patching]
    C --> C1["Control plane: you"]
    C --> C2["etcd: you"]
    C --> C3["Upgrades: you"]
    C --> C4["Patching: you"]

Managed Kubernetes providers (EKS, AKS, GKE, OKE) manage:

• The control plane (API server, scheduler, controller manager).
• etcd (backups, scaling, patching).
• Kubernetes upgrades (typically with a button click or API call).
• Node OS patching.
• The control plane’s networking.

The operator manages:

• Worker nodes (in some providers, the OS is also managed).
• Application workloads.
• Ingress, service mesh, observability.
• Storage, networking at the application level.

Self-managed Kubernetes (kubeadm, K3s, RKE2) gives the operator full control:

• Control plane (provisioning, configuration, upgrades).
• etcd (provisioning, backups, scaling).
• Node OS (provisioning, patching, kernel upgrades).
• Networking (CNI, ingress).
• Storage (CSI drivers).
• All add-ons (cert-manager, Argo CD, etc.).

The trade-offs

flowchart LR
    A[Managed Kubernetes] --> B["Operational burden: low"]
    A --> C["Cost: higher per cluster"]
    A --> D["Control: limited"]
    A --> E["Lock-in: high"]
    F[Self-managed Kubernetes] --> G["Operational burden: high"]
    F --> H["Cost: lower (your own infra)"]
    F --> I["Control: full"]
    F --> J["Lock-in: low"]

The trade-offs:

• Managed. Low operational burden; higher per- cluster cost; limited control over control plane; vendor lock-in.
• Self-managed. High operational burden; lower infrastructure cost; full control; minimal lock-in.

The choice depends on team capacity, requirements, and budget.

The hybrid approach

flowchart LR
    A[Hybrid] --> B[Managed control plane]
    A --> C[Self-managed add-ons]
    A --> D[Self-managed workloads]
    B --> E["EKS / AKS / GKE / OKE"]
    C --> F["cert-manager, Argo CD, Velero"]
    D --> G[Application Deployments]

The hybrid approach: managed control plane plus self-managed add-ons and workloads.

• The provider manages the control plane.
• The operator installs and manages add-ons (cert-manager, Argo CD, Velero, ingress controller).
• The operator manages application workloads.

The hybrid is the most common production pattern: the operational burden of the control plane is outsourced, but the operator retains control over the applications and add-ons.

The decision framework

The framework:

1. Assess team capacity (size, expertise).
2. Assess budget (managed costs vs operational cost).
3. Assess requirements (control, compliance, multi- cloud).
4. Choose based on the intersection.

The operational failure modes

Architecture choices fail for predictable reasons:

• Managed without lock-in assessment. A team adopts EKS and later discovers the lock-in is insurmountable. The migration cost exceeds the operational savings.
• Self-managed without expertise. A team adopts kubeadm without the operational capacity to manage it. The control plane becomes unreliable.
• Hybrid without clear ownership. The control plane is managed; the add-ons are self-managed; nobody owns the integration. Failures are unowned.
• Cost underestimation. The per-cluster fee is not modelled; the bill exceeds the budget.

Quiz

Production discipline

Managed vs self-managed in production rests on five non-negotiable elements:

• Assess team capacity. A small team with limited Kubernetes expertise should choose managed. A large team with expertise can choose self-managed.
• Assess budget. Managed has higher per-cluster cost; self-managed has higher operational cost.
• Assess lock-in. Managed creates lock-in; the discipline is to abstract cloud-specific dependencies.
• Hybrid is the most common. Managed control plane plus self-managed add-ons and workloads.
• Document the choice and rationale. The decision and the drivers must be in the runbook.

Managed vs self-managed is an architecture decision. The discipline is to make the decision based on drivers, not on convenience, and to review it regularly.