kubeadm vs EKS — the operational comparison

kubeadm and EKS represent the two ends of the managed-self-managed spectrum. This lesson walks the responsibility split, the cost comparison, the lock-in assessment, and the operational discipline.

The responsibility split

flowchart LR
    A[kubeadm] --> A1["Control plane: you"]
    A --> A2["etcd: you"]
    A --> A3["Upgrades: you"]
    A --> A4["Networking: you"]
    A --> A5["Storage: you"]
    B[EKS] --> B1["Control plane: AWS"]
    B --> B2["etcd: AWS"]
    B --> B3["Upgrades: AWS"]
    B --> B4["Networking: AWS VPC CNI"]
    B --> B5["Storage: EBS CSI driver"]

The split:

The cost comparison

flowchart LR
    A[kubeadm cost] --> A1["Infrastructure: 3 control-plane nodes, N worker nodes"]
    A --> A2["Operational: SRE team time for etcd, upgrades, patching"]
    B[EKS cost] --> B1["Control plane: $0.10/hour per cluster"]
    B --> B2["Infrastructure: N worker nodes"]
    B --> B3["Operational: less SRE time"]

The cost components:

kubeadm:

• Infrastructure: 3 control-plane nodes (HA), N worker nodes. Cost depends on instance types.
• Operational: SRE team time for etcd backups, upgrades, patching, monitoring, debugging. This is the hidden cost.
• Total: infrastructure + (SRE time × hourly rate).

EKS:

• Control plane fee: $0.10/hour per cluster ($73/month).
• Infrastructure: N worker nodes (no control plane nodes).
• Operational: less SRE time for control plane.
• Total: control plane fee + infrastructure + (less SRE time).

The break-even depends on the SRE team’s hourly rate and the cluster count. For a small team with high SRE costs, EKS is cheaper; for a large team with low SRE costs, kubeadm is cheaper.

The lock-in assessment

flowchart LR
    A[EKS lock-in] --> A1["VPC CNI: AWS-specific"]
    A --> A2["EBS CSI driver: AWS-specific"]
    A --> A3["IAM for service accounts: AWS-specific"]
    A --> A4["ALB ingress controller: AWS-specific"]
    A --> A5["AWS-specific add-ons: eksctl, AWS LB Controller"]
    B[kubeadm lock-in] --> B1[Kubernetes APIs only]
    B --> B2["Cloud-agnostic add-ons: cert-manager, Argo CD, Velero"]

EKS lock-in:

• VPC CNI — AWS-specific; every Pod gets a VPC IP.
• EBS CSI driver — AWS-specific.
• IAM for service accounts (IRSA) — AWS-specific; uses OIDC + IAM roles.
• AWS Load Balancer Controller — AWS-specific; manages ALBs and NLBs.
• EKS add-ons — managed by AWS (kube-proxy, CoreDNS, VPC CNI).

Migrating from EKS to AKS or GKE requires replacing all of these with provider-specific equivalents. The migration cost is high.

kubeadm lock-in:

• Kubernetes APIs only — the cluster is a vanilla Kubernetes cluster.
• Cloud-agnostic add-ons — cert-manager, Argo CD, Velero work on any cluster.

Migrating a kubeadm cluster to EKS or AKS is easier because the add-ons are portable.

The operational trade-offs

flowchart LR
    A[kubeadm operational] --> A1["etcd backup, restore, scaling"]
    A --> A2[kubeadm upgrade procedure]
    A --> A3[node OS patching]
    A --> A4[CNI configuration]
    B[EKS operational] --> B1[Click to upgrade]
    B --> B2[Managed node groups for OS patching]
    B --> B3[AWS VPC CNI configuration]
    B --> B4[EKS troubleshooting]

The operational trade-offs:

kubeadm:

• Pros: Full control; cloud-agnostic; lower infrastructure cost.
• Cons: High operational burden; SRE team must manage etcd, upgrades, patching.

EKS:

• Pros: Lower operational burden; managed control plane; managed upgrades.
• Cons: Higher per-cluster cost; AWS lock-in; less control over control plane configuration.

The decision framework

The discipline:

1. Assess team size and expertise.
2. Assess AWS commitment.
3. Assess lock-in tolerance.
4. Choose the architecture that matches.

The operational failure modes

Architecture choices fail for predictable reasons:

• EKS chosen without lock-in assessment. The migration cost is high when lock-in is discovered later.
• kubeadm chosen without operational capacity. The control plane becomes unreliable when SRE team is small.
• Hybrid without clear ownership. EKS handles the control plane; the operator handles add-ons; nobody owns the integration.
• Cost underestimation. EKS control plane fee plus worker node cost exceeds the budget.

Quiz

Production discipline

kubeadm vs EKS in production rests on five non-negotiable elements:

• Assess team capacity. Small team → EKS; large team → kubeadm.
• Assess lock-in tolerance. Low tolerance → kubeadm or abstracted cloud-agnostic add-ons.
• Model total cost. Control plane fee + operational cost + lock-in cost.
• Document the choice. The decision and the drivers must be in the runbook.
• Plan for migration. Even if EKS is chosen, abstract cloud-specific dependencies to enable future migration.

The choice between kubeadm and EKS is consequential. The discipline is to make it based on drivers and to plan for change.