EKS vs Your Own kubeadm Cluster#

If you’ve been through my multi-node kubeadm notes, you’ve done it the hard way: Debian VMs on Proxmox, containerd, kubeadm init/join, Cilium as the CNI, and every package upgrade lands on your desk. That cluster is yours - you know every screw.

EKS is the same Kubernetes API with most of the screws hidden. The point of this note is exactly what to compare: what disappears, what changes, and what stays stubbornly identical.

What AWS takes off your plate#

Topickubeadm (your cluster)EKS
Control planeYou install and run kube-apiserver, scheduler, controller-managerAWS runs them across 3 AZs, patches them, gives you an SLA
etcdYou run it (stacked or external), you snapshot it, you defrag itAWS runs it; you never touch it. No etcdctl, no snapshots - AWS backs it up
Node bootstrapKernel modules, swap off, sysctl, containerd, k8s apt packages, kubeadm joinA managed node group: AWS builds the AMI (AL2 / Bottlerocket), joins the nodes for you
Upgradeskubeadm upgrade, one minor at a time, control plane first, your calendarPick a version in the console/CLI; AWS rolls the control plane, you roll the node group AMIs
Endpoint--control-plane-endpoint=<VIP>, your keepalived/nginx LBA regional API endpoint (public and/or private) managed by AWS
CostThe VMs. Nothing else~$0.10/hour for the control plane, plus worker nodes

Not: kubeadm’de --control-plane-endpoint VIP’i ve failover’ı biz kuruyorduk. EKS’te kendi hallediyor - endpoint regional DNS, arkasında AWS’in multi-AZ’li control plane’i var. ha-control-plane notundaki “stable endpoint” bölümünün tamamı AWS’e devredilmiş durumda ~ not my problem - money talk.

What changes but is still yours#

  • CNI: kubeadm’de Cilium kurmuştuk (notlar). EKS varsayılan olarak VPC CNI kullanır - pod IP’leri VPC’nin IP havuzundan gelir. Bu, pod’ların VPC’de “gerçek” IP’lerle dolaşması demek (güzel: VPC SG’leri pod’ları da korur), ama dikkat etmek gerek: private subnet IP’leri (tabi sadece bu iş için cluster’a özel bir VPC oluşturup CIDR bloğunu daha fazla IP adresini kapsayacak şekilde yapılandırmamız daha iyi olur) hızla tükenir. Büyük kümelerde --max-pods, prefix delegation veya Cilium’a geçiş gerekir.
  • IAM ↔ Kubernetes RBAC: kubeadm’de olmayan bir layer. EKS’te AWS IAM ile Kubernetes kimlikleri köprülenir: IRSA (pod bazlı roller) ve EKS Access Entries (aws-auth ConfigMap’inin modern hali). Biz bunu S3 ve RDS kullandık.
  • Node lifecycle: kubectl delete node + VM’yi yakmak yerine managed node group’ları eksctl scale / console ile büyütürsün. Node group bir launch template gibidir - yenisini eklersin, eskisini kapatırsın.
  • Addon’lar: kubeadm’de Cilium/metrics-server‘ı elle kurdun; EKS’te eksctl utils associate-iam-oidc-provider + addon katalogu (VPC CNI, CoreDNS, kube-proxy, eks-pod-identity-agent) tek yerden.

What is literally the same#

This is the part people underestimate. Once your kubeconfig points at EKS:

  • kubectl apply, Deployment, Service, StatefulSet, Job - aynı
  • Taints, tolerations, affinity, topology spread - aynı (EKS’e özgü detaylar için eks-node-affinity-taints)
  • RBAC (Role, ClusterRole, RoleBinding) - aynı
  • CRD’ler, operator’lar, Helm chart’ları - aynı

Kısacası: kubeadm notlarında yaptiklarimiz Kubernetes bilgisi EKS’te birebir geçerli. Kaybedilen şey operasyonel yük, kazanılan(kaybedilen) şey AWS faturası.

Assignment#

Compare your own cluster against EKS - and prove the API really is the same.

  1. Point kubectl at the EKS cluster (eksctl utils write-kubeconfig --cluster patientping-eks), then run the same three commands you run on your homelab cluster:
kubectl get nodes -o wide
kubectl get pods -A
kubectl api-resources | wc -l
  1. On your kubeadm cluster, run kubectl get nodes -o wide too. Note the differences: INTERNAL-IP‘ler EKS’te VPC IP’leri, VERSION‘lar AWS’in yönettiği AMI’lerden geliyor, ROLES sütununda control-plane node’u yok (control plane görünür değil).
  2. List what you’d have to do on kubeadm to get what EKS gave you for free (HA control plane, etcd backups, upgrades) - that list is the real price of “free” Kubernetes.

Sanity check: kubectl version - her iki tarafta da aynı komut, aynı çıktı . API sunucusu kim olursa olsun Kubernetes Kubernetes’tir ~period.