Managed Kubernetes #

Membangun dan mengoperasikan kluster Kubernetes secara mandiri (self-managed) di atas infrastruktur bare-metal atau mesin virtual mentah (raw VMs) adalah tugas operasional yang sangat berat. Kita harus bertanggung jawab penuh atas seluruh siklus hidup infrastruktur: merancang kluster etcd berkinerja tinggi yang terdistribusi, memonitor status kesehatan komponen Control Plane (API Server, Controller Manager, Scheduler), mengelola rotasi sertifikat keamanan internal CA secara berkala, serta melakukan peningkatan versi (upgrade) OS pada node tanpa memicu gangguan layanan (downtime). Managed Kubernetes hadir untuk menghilangkan sebagian besar beban operasional administratif ini. Dengan mendelegasikan pengelolaan Control Plane ke penyedia cloud (Cloud Providers), kita dapat mengalihkan fokus 100% pada pengembangan dan pengelolaan aplikasi (workload) bisnis kita. Artikel ini membahas secara mendalam model pembagian tanggung jawab, perbandingan tiga platform raksasa (GKE, EKS, AKS), strategi mencegah penguncian vendor (vendor lock-in), serta praktik terbaik pengelolaan kluster produksi di cloud.

Model Pembagian Tanggung Jawab (Shared Responsibility Model) #

Penting untuk dipahami bahwa beralih ke Managed Kubernetes tidak berarti kita terbebas dari seluruh tanggung jawab infrastruktur. Penyedia cloud menerapkan Shared Responsibility Model yang membagi tugas secara tegas antara provider dan konsumen.

+-----------------------------------------------------------------------+
|                       TANGGUNG JAWAB KONSUMEN                         |
|   - Konfigurasi Workload (Manifest Deployment, Pod, Ingress, Network)  |
|   - Pengaturan Aturan RBAC (Role-Based Access Control) & NetworkPolicy|
|   - Keamanan Citra Kontainer & Aplikasi                               |
|   - Manajemen Kapasitas Node Pool & Skema Autoscaling                 |
|   - Pembaruan Versi Kubelet pada Worker Node (kecuali Serverless)     |
+-----------------------------------------------------------------------+
|                         TANGGUNG JAWAB PROVIDER                       |
|   - Ketersediaan Tinggi (*High Availability*) API Server              |
|   - Penyimpanan Konsisten etcd, Backup Berkala, & Enkripsi Data       |
|   - Rotasi Sertifikat Keamanan Otomatis pada Control Plane            |
|   - Pemantauan Kesehatan & Penggantian Otomatis Komponen Master       |
+-----------------------------------------------------------------------+

Dengan model ini, jika API Server mengalami kegagalan akses, itu adalah kesalahan penyedia cloud (tercakup dalam jaminan SLA mereka). Namun, jika aplikasi kita diretas karena kita membiarkan port database terbuka ke internet publik melalui konfigurasi Service LoadBalancer yang salah, itu adalah sepenuhnya tanggung jawab kita.

Google Kubernetes Engine (GKE) #

Sebagai pelopor yang merilis Kubernetes ke dunia open-source, Google Cloud memiliki layanan GKE yang sering dianggap sebagai standar emas (gold standard) platform Managed Kubernetes dengan integrasi fitur Kubernetes-native paling matang.

1. Mode Autopilot vs Standard #

GKE menawarkan dua mode operasi utama yang menentukan tingkat kontrol infrastruktur kita:

• GKE Autopilot (Zero Node Management): Google mengelola seluruh kluster, termasuk penyediaan (provisioning), penskalaan (scaling), dan pengerasan keamanan (hardening) dari worker node secara otomatis. Kita tidak perlu membuat node pools atau memilih tipe VM (seperti n2-standard-4). Kita hanya perlu mengirimkan manifest aplikasi, dan Google akan mencocokkan kapasitas CPU/RAM node secara dinamis sesuai kebutuhan Pod. Kita hanya dikenakan biaya berdasarkan total resource requests dari Pod yang berjalan, bukan kapasitas Node fisik.
• GKE Standard (Kontrol Penuh): Kita memiliki akses penuh terhadap konfigurasi node pools. Kita dapat masuk ke Node via SSH, memasang DaemonSet pihak ketiga yang mengakses kernel host, serta mendesain arsitektur VM kustom. Namun, kita bertanggung jawab untuk melakukan patching OS node dan mengelola siklus hidup node pools.

2. Workload Identity: Autentikasi Tanpa Kunci #

Menyimpan berkas kredensial akses Google Service Account berbentuk berkas JSON di dalam Kubernetes Secret sangatlah berbahaya karena rentan bocor. GKE menyelesaikan ini melalui Workload Identity.

flowchart LR
    PodSA["1. Pod dengan Kubernetes ServiceAccount (KSA)"] -->|"Mengirim Token KSA"| GKE_OIDC["2. GKE OIDC Provider (Membaca Identitas)"]
    GKE_OIDC -->|"Memvalidasi & Tukar Token"| GCP_STS["3. GCP Security Token Service (STS)"]
    GCP_STS -->|"Mengembalikan Token GCP Sementara"| GCP_IAM["4. GCP IAM (Google Service Account - GSA)"]
    GCP_IAM -->|"Akses Resource yang Diizinkan"| GCPResources["5. GCP Resources (Cloud Storage, BigQuery)"]

Dengan Workload Identity, KSA di dalam kluster Kubernetes dipetakan langsung (federated) ke GSA di tingkat GCP IAM menggunakan token OIDC yang berumur pendek dan dirotasi otomatis setiap jam oleh Google STS, sehingga tidak ada berkas kunci kredensial permanen yang disimpan di dalam kluster.

# Contoh mendaftarkan pemetaan Workload Identity via gcloud CLI
gcloud iam service-accounts add-iam-policy-binding [email protected] \
  --role roles/iam.workloadIdentityUser \
  --member "serviceAccount:my-project.svc.id.goog[production/billing-ksa]"

Kemudian, di sisi Kubernetes, kita cukup membuat ServiceAccount dengan anotasi yang merujuk pada Google Service Account tersebut:

# File: gke/service-account.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: billing-ksa
  namespace: production
  annotations:
    iam.gke.io/gcp-service-account: "[email protected]"

Amazon Elastic Kubernetes Service (EKS) #

Amazon EKS adalah layanan Managed Kubernetes dari AWS. Mengingat dominasi pasar AWS, EKS adalah platform yang paling banyak digunakan di tingkat perusahaan besar, terutama yang membutuhkan integrasi mendalam dengan ekosistem layanan AWS lainnya.

1. IRSA (IAM Roles for Service Accounts) #

IRSA adalah implementasi federasi identitas di AWS yang setara dengan Workload Identity pada GKE. IRSA mengizinkan kontainer aplikasi di dalam pod Kubernetes untuk melakukan autentikasi langsung ke API AWS (seperti membaca data dari bucket S3 atau menulis ke DynamoDB) tanpa menyimpan berkas kredensial AWS_ACCESS_KEY_ID di dalam Secret.

Saat kita mengaktifkan IRSA, EKS akan bertindak sebagai OpenID Connect (OIDC) identity provider. AWS Security Token Service (STS) akan memverifikasi token akun layanan Kubernetes, lalu memberikan kredensial AWS IAM berumur pendek secara dinamis ke dalam kontainer.

# File: eks/service-account.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: s3-reader-ksa
  namespace: production
  annotations:
    # Mengikat ServiceAccount Kubernetes langsung ke IAM Role AWS
    eks.amazonaws.com/role-arn: "arn:aws:iam::123456789012:role/prod-s3-reader-role"

2. AWS Fargate: Serverless Kubernetes #

Bagi organisasi yang menginginkan pendekatan serverless tanpa perlu mengelola instansi EC2 (Elastic Compute Cloud) sebagai worker node, EKS menyediakan integrasi dengan AWS Fargate.

Setiap kali kita mendeploy Pod ke dalam namespace yang dikonfigurasi menggunakan profil Fargate, AWS akan meluncurkan mesin virtual mikro terisolasi (microVM) khusus untuk menjalankan Pod tersebut. Kita tidak perlu melakukan OS patching pada node, dan kita terhindar dari ancaman keamanan eskalasi hak akses kontainer ke tingkat host kernel karena setiap Pod memiliki batas VM fisiknya sendiri.

Azure Kubernetes Service (AKS) #

Microsoft Azure menyediakan AKS dengan fokus utama pada kecepatan provisioning kluster dan integrasi korporasi (enterprise) yang kuat menggunakan Microsoft Entra ID (dahulu Azure Active Directory).

1. Integrasi Microsoft Entra ID secara Native #

Salah satu keunggulan terbesar AKS adalah kemampuannya menghubungkan sistem otorisasi RBAC (Role-Based Access Control) Kubernetes secara langsung dengan akun Microsoft Entra ID perusahaan.

# Contoh konfigurasi otorisasi AKS terintegrasi Azure AD
# Kita tidak perlu membuat RoleBinding manual untuk setiap user; 
# kita cukup memetakan Azure AD Group ID langsung ke ClusterRole admin Kubernetes
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: active-directory-admin-binding
subjects:
- kind: Group
  name: "88888888-4444-4444-4444-121212121212" # Azure AD Object Group ID untuk Team Platform
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin

Dengan konfigurasi ini, ketika pengembang ingin berinteraksi dengan kluster menggunakan kubectl, mereka harus melakukan autentikasi login browser menggunakan email resmi perusahaan dan mematuhi aturan keamanan Multi-Factor Authentication (MFA) yang diterapkan di tingkat AD perusahaan.

2. Virtual Nodes (Azure Container Instances - ACI) #

AKS menyediakan fitur unik bernama Virtual Nodes yang memanfaatkan Azure Container Instances (ACI). Fitur ini sangat berguna untuk menangani lonjakan lalu lintas yang tidak terduga (burst traffic).

Ketika mendeteksi antrian Pod yang tinggi akibat keterbatasan kapasitas CPU node pools, AKS Virtual Nodes dapat meluncurkan kontainer baru di ACI dalam hitungan detik untuk menyerap beban lalu lintas instan tersebut, sementara kluster utama menunggu proses auto-scaling node VM fisik yang biasanya membutuhkan waktu 2 hingga 4 menit untuk menyala.

Tabel Perbandingan Platform #

Tabel berikut menyajikan analisis komparatif mendalam antara ketiga platform Managed Kubernetes terbesar di pasar:

Strategi Mencegah Penguncian Vendor (Vendor Lock-in) #

Meskipun Managed Kubernetes mempermudah operasional kluster, penggunaan fitur-fitur eksklusif cloud provider secara tidak terkontrol dapat mengunci (lock-in) sistem kita ke satu vendor tertentu. Jika di kemudian hari terjadi kenaikan biaya sewa infrastruktur yang drastis atau ada kebutuhan migrasi ke cloud provider lain, kita akan terjebak dalam proses migrasi yang mahal dan memakan waktu.

Kita dapat menerapkan strategi berikut untuk meminimalkan ketergantungan pada vendor spesifik:

flowchart TD
    AppManifests["Aplikasi Utama (Deployments, Services, ConfigMaps)"] -->|"Agnostik"| PortableLayer["Agnostik Kubernetes API (Portabel ke Semua Cloud)"]
    
    subgraph CloudSpecificOverlays["Kustomize Overlays per Cloud Vendor"]
        GCPOverlay["Overlay GCP (GKE StorageClass, Ingress Controller Google)"]
        AWSOverlay["Overlay AWS (EKS StorageClass, EBS annotations)"]
        AzureOverlay["Overlay Azure (AKS StorageClass, Azure LoadBalancer annotations)"]
    end
    
    AppManifests -.-> GCPOverlay
    AppManifests -.-> AWSOverlay
    AppManifests -.-> AzureOverlay

1. Gunakan Kustomize Overlays untuk Metadata Cloud-Spesifik #

Pisahkan manifest utama aplikasi kita dari konfigurasi anotasi cloud-spesifik. Letakkan spesifikasi agnostik di dalam direktori base/, lalu gunakan Kustomize overlays/ untuk menyisipkan anotasi penyeimbang beban (LoadBalancer Annotations) atau spesifikasi kelas penyimpanan (StorageClass) yang bervariasi antar cloud provider.

# File: k8s/overlays/aws/service-patch.yaml
# Patch khusus untuk mengaktifkan AWS Network Load Balancer (NLB)
apiVersion: v1
kind: Service
metadata:
  name: payment-service
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-type: "external"
    service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: "ip"

2. Standarisasi Menggunakan Operator Agnostik #

Alih-alih menggunakan operator atau layanan kustom bawaan cloud provider (seperti AWS Controller for Kubernetes atau GCP Config Connector) untuk membuat database SQL, gunakan operator agnostik seperti Crossplane. Crossplane mengabstraksikan sumber daya cloud provider menjadi objek Kubernetes netral yang dapat dipindahkan antar kluster dengan mudah.

3. Gunakan cert-manager dan external-dns #

Jangan mengandalkan mekanisme DNS otomatis bawaan cloud provider yang menyatu dengan kontrol Ingress mereka. Gunakan perkakas open-source seperti cert-manager (untuk sertifikat TLS) dan external-dns (untuk sinkronisasi nama DNS ke Route53, Cloud DNS, atau Azure DNS secara otomatis dari objek Ingress netral).

Praktik Terbaik untuk Managed Kubernetes Produksi #

Terapkan panduan konfigurasi berikut untuk memastikan kluster produksi Anda di cloud berjalan secara aman, efisien, dan memiliki toleransi kesalahan yang tinggi:

1. Aktifkan Private Cluster (Isolasi Jaringan) #

Jangan pernah membiarkan endpoint API Server Kubernetes kluster produksi Anda dapat diakses secara terbuka dari internet publik. Aktifkan fitur Private Cluster.

• API Server hanya memiliki IP internal di dalam VPC.
• Akses administratif dari laptop engineer harus melalui jalur VPN kantor, AWS Client VPN, Bastion Host, atau menggunakan interkoneksi Cloud NAT / Private Service Connect.
• Worker node diletakkan di dalam subnet privat tanpa alamat IP publik eksternal.

2. Rancang Multi-Availability Zone (Multi-AZ) Node Pools #

Untuk melindungi sistem dari kegagalan pusat data fisik di satu wilayah, sebarkan (spread) worker node kluster Anda di minimal tiga Availability Zone yang berbeda. Gunakan properti topologySpreadConstraints pada manifest Pod untuk memastikan Kubernetes membagi replika kontainer secara merata di seluruh zona tersebut.

# File: app/deployment.yaml (Potongan kode topologi sebaran)
spec:
  template:
    spec:
      topologySpreadConstraints:
      - maxSkew: 1
        topologyKey: "topology.kubernetes.io/zone"
        whenUnsatisfiable: DoNotSchedule
        labelSelector:
          matchLabels:
            app: payment-api

3. Pisahkan Node Pools Berdasarkan Peran Workload #

Jangan menggabungkan seluruh aplikasi dan layanan kluster ke dalam satu node pool umum yang besar. Buat beberapa node pool khusus berdasarkan karakteristik beban kerja:

• System Node Pool: Khusus untuk menjalankan komponen internal kluster (CoreDNS, metrics-server, Ingress Controller). Pool ini harus memiliki toleransi kegagalan tinggi dan menggunakan VM berbayar penuh (on-demand VM).
• Application Node Pool: Untuk menjalankan kode aplikasi mikroservis bisnis kita.
• Spot / Preemptible Node Pool: Node pool yang menggunakan VM sisa berbiaya murah (hemat hingga 70-80% biaya cloud). Pool ini sangat cocok untuk menjalankan aplikasi pengujian (dev/staging) atau batch processing jobs yang tidak sensitif terhadap proses penghentian mendadak.

Anti-Pattern dalam Praktik Managed Kubernetes #

Hindari kesalahan operasional berikut untuk mencegah pemborosan biaya cloud dan celah keamanan kluster:

1. Menyimpan Kunci Kredensial Permanen di dalam Kluster #

# ANTI-PATTERN: Menyimpan kunci JSON Google Service Account permanen di dalam Kubernetes Secret
apiVersion: v1
kind: Secret
metadata:
  name: gcp-sa-key
type: Opaque
data:
  key.json: "ewogICJ0eXBlIjogInNlcnZpY2VfYWNjb3VudCIsCiAgIC..." # JANGAN: Risiko kebocoran kunci!

Risiko Kebocoran Keamanan:
- Jika seseorang berhasil meretas satu Pod dan mendapatkan akses baca Secret, ia dapat mengambil kunci JSON tersebut dan menggunakannya di luar kluster untuk menghapus data berharga di cloud storage perusahaan.
✓ SOLUSI: Selalu gunakan federasi identitas native cloud provider (GKE Workload Identity / EKS IRSA / Azure Workload Identity) yang tidak memerlukan penyimpanan berkas kunci permanen sama sekali di kluster.

2. Menjalankan Cluster Tanpa Limitasi Autoscaler (Cost Ballooning) #

Mengaktifkan fitur Cluster Autoscaler dengan membiarkan parameter kapasitas maksimum node tidak terbatas atau disetel terlalu tinggi tanpa pemantauan biaya.

# ANTI-PATTERN: Menyetel max-nodes terlalu besar tanpa kalkulasi batas anggaran perusahaan
eksctl create cluster --name prod --nodes-min 3 --nodes-max 100 # JANGAN: Potensi tagihan cloud bengkak!

Jika aplikasi kita mengalami serangan denial-of-service (DDoS) atau memiliki bug kebocoran memori (memory leak loop) yang memicu HPA untuk terus menambah Pod, Cluster Autoscaler akan terus meluncurkan instansi VM baru hingga batas maksimal 100 node. Hal ini akan memicu pembengkakan biaya tagihan cloud (cost ballooning) hingga ribuan dolar dalam satu malam.

✓ SOLUSI:
Batasi kapasitas maksimal node pools secara rasional berdasarkan anggaran bulanan dan kapasitas fisik target (misalnya menyetel max-nodes ke 15). Aktifkan juga sistem peringatan anggaran (Cloud Billing Alerts) untuk memberi notifikasi instan jika terjadi lonjakan konsumsi biaya infrastruktur.

Checklist Audit Managed Kubernetes #

Gunakan checklist berikut sebelum merilis kluster Managed Kubernetes Anda ke tahap produksi:

HARDENING JARINGAN & KONEKTIVITAS:
  □ Kluster dikonfigurasi sebagai Private Cluster (API Server tidak terekspos ke internet publik).
  □ Endpoint API Server dilindungi menggunakan aturan batasan IP (Authorized Networks / AWS Security Groups).
  □ Worker node ditempatkan di dalam subnet privat tanpa IP publik eksternal.
  □ Lalu lintas lalu-lalang pod dibatasi menggunakan aturan NetworkPolicy.

INTEGRASI IDENTITAS DAN KEAMANAN IAM:
  □ Tidak ada berkas kunci kredensial permanen (seperti JSON keys atau AWS Access Keys) yang disimpan di kluster.
  □ Fitur federasi identitas (Workload Identity / IRSA) aktif dan digunakan oleh semua pod yang butuh akses ke cloud resources.
  □ Hak akses IAM Role dibatasi menggunakan prinsip least privilege untuk masing-masing ServiceAccount.
  □ Enkripsi data rahasia (Secrets) di etcd menggunakan KMS bawaan cloud provider (AWS KMS / GCP KMS / Azure Key Vault).

TOLERANSI KESALAHAN & BIAYA:
  □ Worker node disebar di minimal tiga Availability Zone (Multi-AZ) yang berbeda.
  □ Node pools dipisahkan antara System Pool (On-Demand) dan Application/Batch Pool (opsi Spot VM).
  □ Parameter minimal dan maksimal Cluster Autoscaler dikonfigurasi secara rasional untuk membatasi pengeluaran.
  □ Kebijakan pemeliharaan (Maintenance Windows) dikonfigurasi pada jam-jam sepi lalu lintas pengguna.

Ringkasan #

• Delegasikan Master Plane — Gunakan Managed Kubernetes untuk memindahkan tanggung jawab administratif Control Plane (etcd, API Server, CA rotation) ke cloud provider demi efisiensi tim.
• Integrasikan Identitas Native — Tinggalkan penyimpanan kunci statis di dalam kluster; wajib gunakan Workload Identity (GKE) atau IRSA (EKS) untuk autentikasi aman tanpa kunci.
• Implementasikan Private Cluster — Tutup akses API Server dari internet publik untuk meminimalkan luas permukaan serangan siber pada kluster produksi.
• Sebarkan Node Lintas AZ — Pastikan kluster Anda memiliki toleransi bencana tingkat regional dengan menyebarkan node pools di minimal tiga Availability Zone yang terpisah.
• Minimalkan Lock-in Sejak Awal — Abstraksikan metadata spesifik cloud provider menggunakan Kustomize overlays agar manifest utama Anda tetap agnostik dan mudah dipindahkan.
• Kendalikan Penskalaan Otomatis — Konfigurasikan batas atas kapasitas maksimum Cluster Autoscaler secara rasional untuk mencegah lonjakan tagihan cloud yang tidak terduga akibat serangan DDoS atau bug aplikasi.

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