Managed Kubernetes #

Menjalankan Kubernetes secara self-managed berarti kamu bertanggung jawab atas segalanya: setup control plane, etcd backup, certificate rotation, upgrade kubelet di setiap node, dan semua kerumitan operasional lainnya. Managed Kubernetes dari cloud provider mengambil alih sebagian besar tanggung jawab tersebut, sehingga tim bisa fokus pada workload yang berjalan, bukan infrastruktur Kubernetes itu sendiri.

Pembagian Tanggung Jawab #

Self-managed Kubernetes:
  Kamu kelola: control plane, etcd, worker nodes, networking,
               storage, certificate, upgrade semua komponen

Managed Kubernetes (GKE/EKS/AKS):
  Provider kelola: control plane, etcd backup, API server uptime,
                   certificate rotation control plane
  Kamu tetap kelola: worker nodes (kecuali Fargate/Autopilot),
                     networking konfigurasi, storage class,
                     upgrade worker nodes, aplikasi kamu

Google Kubernetes Engine (GKE) #

GKE adalah managed Kubernetes dari Google Cloud, dan sering dianggap yang paling matang dari sisi fitur Kubernetes native.

Fitur unggulan GKE:

Autopilot mode:
  → Google kelola worker nodes sepenuhnya (sizing, scaling, patching)
  → Bayar per Pod resource request, bukan per node
  → Tidak bisa SSH ke node, tidak bisa DaemonSet arbitrary
  → Cocok untuk tim yang ingin zero node management

Standard mode:
  → Kontrol penuh atas node configuration
  → Bisa pakai DaemonSet, node customization
  → Node patching masih tanggung jawab tim

Release channels:
  → Rapid: versi Kubernetes terbaru, untuk non-production
  → Regular: versi stabil, rekomendasi production (default)
  → Stable: versi paling konservatif, untuk compliance-heavy
  → Auto-upgrade berdasarkan channel yang dipilih

Workload Identity:
  → Bind Kubernetes ServiceAccount ke Google Service Account
  → Tidak perlu credential JSON di cluster
  → IAM fine-grained per service, bukan satu credential untuk semua

Fitur lain:
  → Binary Authorization: hanya allow signed images
  → Config Connector: manage Google Cloud resources via kubectl
  → Dataplane V2 (eBPF): berbasis Cilium, NetworkPolicy canggih
# Buat GKE cluster
gcloud container clusters create production \
  --zone asia-southeast1-a \
  --num-nodes 3 \
  --machine-type n2-standard-4 \
  --release-channel regular \
  --enable-autoscaling --min-nodes 3 --max-nodes 10 \
  --workload-pool=my-project.svc.id.goog \
  --enable-network-policy

# Autopilot cluster
gcloud container clusters create-auto production \
  --region asia-southeast1

Amazon Elastic Kubernetes Service (EKS) #

EKS adalah managed Kubernetes dari AWS, dengan integrasi ekosistem AWS yang dalam.

Fitur unggulan EKS:

IRSA (IAM Roles for Service Accounts):
  → Bind ServiceAccount ke IAM Role
  → Akses AWS services (S3, DynamoDB, Secrets Manager) tanpa credential hardcode
  → Token OIDC diverifikasi oleh AWS STS

Fargate:
  → Jalankan Pod tanpa provision node
  → Bayar per Pod resource
  → Tidak ada akses ke node, tidak bisa DaemonSet

EKS Managed Node Groups:
  → AWS kelola provisioning dan lifecycle node
  → Rolling update node dengan downtime minimal
  → Tapi patching security masih perlu trigger manual

Add-ons:
  → VPC CNI, CoreDNS, kube-proxy via EKS add-on system
  → Managed lifecycle, mudah update ke versi terbaru

EKS Anywhere:
  → Jalankan EKS di on-premise (vSphere, bare metal)
  → Unified management plane untuk hybrid
# Buat EKS cluster dengan eksctl
eksctl create cluster \
  --name production \
  --region ap-southeast-1 \
  --nodegroup-name workers \
  --node-type m5.xlarge \
  --nodes 3 \
  --nodes-min 3 \
  --nodes-max 10 \
  --managed \
  --with-oidc   # aktifkan IRSA

# Update kubeconfig
aws eks update-kubeconfig --name production --region ap-southeast-1

Azure Kubernetes Service (AKS) #

AKS dari Microsoft Azure dengan integrasi Active Directory dan enterprise features.

Fitur unggulan AKS:

Azure AD Integration:
  → RBAC Kubernetes terintegrasi dengan Azure AD
  → Login ke cluster via Azure AD credentials
  → Tidak perlu manage kubeconfig credential terpisah
  → Conditional Access, MFA support

Workload Identity:
  → Serupa dengan IRSA di EKS
  → Bind ServiceAccount ke Azure Managed Identity
  → Akses Azure resources tanpa credential

Virtual Nodes (ACI):
  → Scale out ke Azure Container Instances untuk burst traffic
  → Tidak perlu provision node baru untuk spike mendadak

KEDA Integration:
  → Kubernetes Event-Driven Autoscaling
  → Scale berdasarkan Azure Service Bus, Event Hub, dll

Container Insights:
  → Monitoring bawaan yang terintegrasi dengan Azure Monitor
  → Log Analytics workspace otomatis tersedia

Perbandingan Tiga Platform #

                    GKE           EKS           AKS
──────────────────────────────────────────────────────
Control plane SLA   99.95%        99.95%        99.95%
Autopilot/Fargate   Autopilot     Fargate       Virtual Nodes
IAM integration     Workload ID   IRSA          Workload Identity
Node upgrade        Auto (channel)Manual+Managed Auto
Ecosystem fit       Google Cloud  AWS           Azure AD/MS
Kubernetes version  Paling baru   Sedikit lag   Sedikit lag
Harga control plane Gratis*       $0.10/jam     Gratis*
                    (*untuk zonal)

*Gratis: GKE dan AKS tidak charge untuk control plane
 EKS: $0.10 per jam per cluster = ~$72/bulan

Praktik Terbaik untuk Managed Kubernetes #

1. Aktifkan auto-upgrade untuk node
   → Patch security node harus diterapkan, jangan tunda
   → Gunakan maintenance window agar tidak disruptif

2. Gunakan Workload Identity / IRSA
   → Tidak ada secret AWS/GCP/Azure di dalam cluster
   → IAM fine-grained per service account

3. Multi-AZ node pools
   → Spread node di beberapa availability zone
   → Cluster tetap available jika satu AZ down

4. Pisahkan node pool per workload type
   → General purpose: workload standar
   → High memory: database, ML inference
   → Spot/Preemptible: batch jobs, dev environments
   → System: hanya untuk add-ons (CoreDNS, metrics-server)

5. Aktifkan cluster autoscaler
   → Scale node sesuai demand Pod
   → Lebih hemat dari fixed node count besar

6. Private cluster
   → API server tidak accessible dari internet publik
   → Worker nodes di private subnet
   → Akses via VPN atau bastion host

Pertimbangan Vendor Lock-in #

Hal yang portable (tidak lock-in):
  → Manifest Kubernetes standard
  → Helm charts
  → Container images di registry apa pun
  → NetworkPolicy, RBAC, PodSecurity

Hal yang provider-specific (berpotensi lock-in):
  → Workload Identity / IRSA — berbeda per provider
  → Storage class (gp3, pd-ssd, managed-premium)
  → Load balancer annotations
  → Managed add-ons (VPC CNI, Azure CNI)
  → Cloud-specific Operators (Config Connector, ACK)

Strategi mengurangi lock-in:
  → Abstraksi cloud-specific config di Kustomize overlay
  → Gunakan external-dns, cert-manager untuk abstraksi DNS/TLS
  → Crossplane untuk cloud resources yang portable
  → Hindari terlalu banyak cloud-specific CRD di manifests utama

Ringkasan #

  • Managed Kubernetes menghilangkan beban control plane — upgrade, etcd backup, API server HA dikelola provider; fokus tim bisa ke workload, bukan infrastruktur Kubernetes.
  • Workload Identity / IRSA wajib — tidak ada alasan menyimpan cloud credential di Secret Kubernetes; semua cloud provider sudah mendukung identity federation dengan ServiceAccount.
  • Multi-AZ untuk production — spread node di minimal dua availability zone; availability berkurang drastis jika cluster hanya di satu AZ.
  • Autopilot (GKE) dan Fargate (EKS) untuk zero node management — bayar per Pod, tidak perlu provision node; cocok jika tim tidak ingin pusing dengan node sizing.
  • Pilih provider berdasarkan ekosistem yang sudah ada — jika sudah pakai AWS, EKS memudahkan integrasi dengan IAM, S3, RDS; jika Azure, AKS + Azure AD lebih natural.
  • Private cluster dengan akses via bastion atau VPN — API server yang accessible dari internet adalah risiko keamanan; aktifkan private cluster di production.

← Sebelumnya: Operator Pattern   Berikutnya: Anti-Pattern Ecosystem & Tooling →

About | Author | Content Scope | Editorial Policy | Privacy Policy | Disclaimer | Contact