Belajar Cloud Architect - Container & Kubernetes Architecture

#Pendahuluan

Di episode 4 kita memilih container sebagai compute, di episode 11 membangun IaC, dan di episode 12-13 merancang pola workload. Sekarang waktunya platform yang menyatukannya: Kubernetes (K8s). Ia adalah standar de facto untuk menjalankan container dalam skala — scheduling, scaling, self-healing, service discovery — semua otomatis.

Tetapi Kubernetes adalah keputusan arsitektur yang besar: ia membawa kompleksitas operasional nyata. Episode ini tidak menjual K8s kepada kalian — ia mengajarkan kapan K8s masuk akal, bagaimana mendesain cluster yang benar, dan kapan lebih baik memakai jalan lain.

#Kapan Kubernetes Masuk Akal (dan Kapan Tidak)

#Desain Cluster yang Benar

#Prinsip Desain

• Cluster untuk environment, bukan per aplikasi — satu cluster production, satu staging, satu dev. Bukan satu cluster per service.
• Control plane di-manage provider (EKS/GKE/AKS) — mengoperasikan control plane sendiri adalah beban tanpa benefit bagi mayoritas organisasi.
• Node pool dengan peran jelas — pool untuk workload umum, pool khusus GPU (episode 17), pool spot untuk batch.
• Namespace untuk isolasi — pisahkan per tim/applikasi dalam satu cluster, dengan quota.

apiVersion: v1
kind: Namespace
metadata:
  name: payments
---
apiVersion: v1
kind: ResourceQuota
metadata:
  name: payments-quota
  namespace: payments
spec:
  hard:
    requests.cpu: "4"
    requests.memory: 8Gi
    limits.cpu: "8"
    limits.memory: 16Gi

ResourceQuota mencegah satu tim menghabiskan seluruh cluster — kontrol yang harus ada sejak awal, bukan setelah insiden.

#Petakan Sumber Daya dengan Benar

Arsitek wajib menyiapkan requests vs limits sejak awal. Request = sumber daya yang dijamin; limit = maksimum yang boleh dipakai. Salah set keduanya menyebabkan pemborosan (over-provision) atau eviction (under-provision).

#Pola Networking di Kubernetes

Memahami tiga lapisan jaringan K8s:

Pola umum: satu Ingress controller menerima semua traffic HTTP, merutekan ke service berdasarkan path. Ini titik tunggal yang juga menjadi tempat meletakkan WAF, rate limiting, dan TLS termination (episode 19).

#GitOps sebagai Model Pengelolaan

Setelah desain cluster, pertanyaan berikutnya: bagaimana perubahan dikelola? Jawaban dari episode 11 — GitOps — paling pas untuk K8s. Argo CD atau Flux menyinkronkan cluster dengan repo git:

Install Argo CD

kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: payments
  namespace: argocd
spec:
  destination:
    server: https://kubernetes.default.svc
    namespace: payments
  source:
    repoURL: https://github.com/company/payments-gitops.git
    path: overlays/prod
    targetRevision: main
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

Efek selfHeal: true: jika ada yang mengubah cluster secara manual, Argo CD mengembalikannya ke state git. Siapa pun tidak bisa "menyelinap" mengubah produksi — persis prinsip yang kita bangun di episode 11.

#Multi-Cluster: Kapan dan Bagaimana

#Kapan Layak

• Multi-region — setiap region punya cluster sendiri untuk isolation dan latency (episode 15).
• Isolasi beban — memisahkan workload yang rawan kegagalan dari yang kritikal.
• Tenant separation — cluster terpisah untuk kepatuhan tertentu.
• Eksperimen — cluster khusus untuk menguji platform baru.

#Kapan Tidak Perlu

Multi-cluster menggandakan biaya operasional. Jika alasan kalian hanya "biar rapi", lebih baik satu cluster dengan namespace + RBAC yang benar.

Pola pengelolaan multi-cluster modern: Argo CD ApplicationSet — mendeklarasikan "deploy aplikasi ini ke semua cluster yang punya label X". Satu definisi, banyak cluster.

#Praktik: Mendesain Platform K8s

Kerangka desain platform K8s production:

1. Managed control plane (EKS/GKE/AKS) dengan node pool per peran.
2. Namespace + ResourceQuota per tim; RBAC ketat (episode 18).
3. Networking: satu Ingress controller + WAF + TLS termination.
4. GitOps (Argo CD/Flux) dengan self-heal untuk semua perubahan.
5. Observability penuh: metrics, logs, traces (episode 10).
6. Backup & recovery untuk stateful workload (episode 8).

Dokumentasikan desain cluster di diagram dan ADR — platform ini akan dipakai bertahun-tahun.

#Penutup

Inti yang harus dibawa pulang:

• Kubernetes untuk scale yang nyata; managed container untuk sisanya.
• Satu cluster per environment; namespace + quota untuk isolasi.
• Requests vs limits harus direncanakan, bukan dibiarkan default.
• GitOps (Argo CD/Flux) menjadikan git sebagai source of truth cluster.
• Multi-cluster untuk isolasi/region; ApplicationSet untuk mengelolanya.

Di episode 15 selanjutnya kita akan membahas multi-region & data residency — active-active vs active-passive, kedaulatan data, dan kepatuhan regional. Sampai jumpa di episode 15!