PEBD6027 · RPS minggu 12 · 2x50 menit
Kubernetes Container Orchestration · Pod · Deployment · Service · EKS Managed Hari ini kita masuk Kubernetes — container orchestration de-facto. Setelah container Docker P4 dan IaC Terraform P10, sekarang bagaimana mengelola ratusan container dalam produksi. Kubernetes solve: scaling, self-healing, load balancing, rolling update, declarative config. Konteks Indonesia: Gojek dan Tokopedia run ribuan container di Kubernetes untuk microservice. AWS EKS, Google GKE, Azure AKS adalah managed offering. Buku pegangan: Burns Kubernetes Up and Running edisi ke-3. Peta Pembelajaran Hari Ini Sub-CPMK 11: menjalankan container di Kubernetes. Empat indikator capaian.
Mengapa Kubernetes: masalah orchestration Pod, Deployment, Service anatomi kubectl dasar: get, apply, logs AWS EKS managed K8s Helm package manager Studi kasus Gojek K8s migration Posisi 14P: setelah IaC Terraform P10, hari ini Kubernetes. P12 DevOps CI/CD.
Empat indikator: jelaskan konsep orchestration, tulis manifest Deployment sederhana, jalankan kubectl, pilih strategi deployment. Kubernetes adalah skill wajib DevOps engineer modern. CNCF Cloud Native Computing Foundation 2023 menunjukkan K8s adalah project paling populer dengan 80 persen perusahaan Fortune 100 menggunakannya. Sulit learning curve tapi ROI tinggi untuk skala besar. Gojek migrasi dari Mesos ke Kubernetes untuk skala driver 2 juta. Mengapa Kubernetes? Container solving deployment, TAPI tidak solving orchestration ratusan container dalam produksi. Kubernetes jawab.
Pengguna K8s Fortune 100
~80%
CNCF Survey 2023 — K8s dominant enterprise container orchestrator
Adopsi RI Enterprise
70%+
Survei Indonesia Cloud 2023 (dihedge) — bank digital & startup besar
Container Docker saja tidak cukup untuk produksi: siapa restart bila mati? siapa scale? siapa load balance? K8s solve semua ini.
Container solving deployment, TAPI tidak solving orchestration ratusan container dalam produksi. Kubernetes jawab. CNCF Survey 2023 menunjukkan K8s adalah project paling populer dengan 80 persen perusahaan Fortune 100 menggunakannya. Adopsi RI Enterprise 70 persen plus berdasarkan survei Indonesia Cloud 2023 dihedge — bank digital dan startup besar seperti Gojek Tokopedia Traveloka semuanya pakai. Container Docker saja tidak cukup untuk produksi: siapa restart bila mati, siapa scale, siapa load balance, siapa rolling update tanpa downtime. K8s solve semua ini dengan declarative config dan control plane otomatis. Bagian 1 · 1/4
K8s Anatomi
Diskusi: bila startup punya 10 microservice, masing-masing butuh 3-5 replica, bagaimana orkestrasi?
Jawaban: Kubernetes. Tanpa K8s, Anda butuh load balancer manual, restart script, scaling script, deployment script per service — chaos. K8s declarative: define Pod dan Deployment dalam YAML, K8s control plane jaga desired state. 10 service × 5 replica = 50 container yang dikelola otomatis. Self-healing bila container mati. Rolling update tanpa downtime. Auto-scale berdasar CPU atau custom metric. Brikman Burns bab 2 mendalami. Pod, Deployment, Service Tiga objek fundamental K8s. Pahami sebelum tulis manifest YAML.
Unit terkecil K8s Wrap 1+ container Ephemeral IP & lifecycle Tidak direstart langsung, recreate Manage replica Pod Desired state vs actual Rolling update strategy Self-healing bila Pod mati Stable network endpoint Load balance antar Pod Type: ClusterIP, NodePort, LoadBalancer Route traffic via label selector Analogi: Pod = pekerja, Deployment = manajer jaga pekerja tetap ada, Service = nomor telepon tetap padahal pekerja ganti.
Tiga objek fundamental K8s. Pod adalah unit terkecil K8s, wrap 1 atau lebih container sharing network dan storage, ephemeral IP dan lifecycle, tidak direstart langsung tapi recreate. Deployment manage replica Pod, desired state vs actual, rolling update strategy, self-healing bila Pod mati. Service adalah stable network endpoint, load balance antar Pod, type ClusterIP NodePort LoadBalancer, route traffic via label selector. Analogi: Pod sama dengan pekerja, Deployment sama dengan manajer jaga pekerja tetap ada, Service sama dengan nomor telepon tetap padahal pekerja ganti. Ini triad yang harus dipahami sebelum tulis manifest YAML apapun. Manifest YAML Anatomi Manifest = deklarasi desired state K8s. YAML structured dengan apiVersion, kind, metadata, spec.
apiVersion: apps/v1
kind: Deployment
metadata:
name: web-app
spec:
replicas: 3
selector:
matchLabels: { app: web }
template:
metadata:
labels: { app: web }
spec:
containers:
- name: nginx
image: nginx:1.25
ports: [{ containerPort: 80 }] apiVersion: apps/v1 (kind-specific) kind: Deployment, Pod, Service metadata.name: unik dalam namespace spec: konfigurasi objek Label konsisten: app, env, version Resource request & limit wajib Liveness & readiness probe Image tag spesifik, jangan latest Anti-pattern: image: latest di produksi. Pin tag spesifik untuk reproducibility dan rollback.
Manifest adalah deklarasi desired state K8s. YAML structured dengan apiVersion kind metadata spec. Field wajib: apiVersion apps/v1 kind-specific, kind Deployment Pod Service, metadata.name unik dalam namespace, spec konfigurasi objek. Best practice: label konsisten app env version, resource request dan limit wajib untuk scheduling, liveness dan readiness probe untuk health check, image tag spesifik jangan latest. Anti-pattern berbahaya: image latest di produksi — pin tag spesifik untuk reproducibility dan rollback. Contoh manifest menunjukkan Deployment web-app dengan 3 replica nginx 1.25 expose port 80. Studi Kasus: Gojek Migrasi ke K8s Gojek migrasi microservice dari Apache Mesos ke Kubernetes untuk skala 2 juta driver.
Public case study Gojek & AWS: pra-K8s (Mesos Marathon) kompleks, scaling manual, rolling update mahal. Pasca-K8s (EKS multi-cluster multi-region): declarative deployment, auto-scaling HPA, multi-region failover Singapore-Jakarta. Hasil (dihedge): deployment frequency 4x lebih sering, MTTR 60% lebih cepat, infra cost turun 30% via better bin-packing.
Scaling manual per service Rolling update berhari Multi-region failover sulit Resource waste ~40% HPA auto-scaling CPU/metric Rolling update menit Multi-region via federation Bin-packing hemat 30% Pelajaran Bisdig: K8s bukan teknis semata. Time-to-market cepat = keunggulan kompetitif Gojek.
Gojek migrasi microservice dari Apache Mesos ke Kubernetes untuk skala 2 juta driver. Public case study Gojek dan AWS: pra-K8s Mesos Marathon kompleks, scaling manual, rolling update mahal. Pasca-K8s EKS multi-cluster multi-region: declarative deployment, auto-scaling HPA Horizontal Pod Autoscaler, multi-region failover Singapore-Jakarta. Hasil dihedge: deployment frequency 4 kali lebih sering, MTTR Mean Time To Recovery 60 persen lebih cepat, infra cost turun 30 persen via better bin-packing resource. Pra-K8s: scaling manual per service, rolling update berhari, multi-region failover sulit, resource waste 40 persen. Pasca-K8s: HPA auto-scaling CPU atau metric, rolling update menit, multi-region via federation, bin-packing hemat 30 persen. Pelajaran Bisdig: K8s bukan teknis semata — time-to-market cepat sama dengan keunggulan kompetitif Gojek. Hitung dari Nol: ROI K8s untuk Microservice Startup punya 10 microservice, 5 replica each. Manual vs K8s: berapa saving engineer time?
Aktivitas Manual/script K8s Restart Pod mati Manual 5-10 mnt/Pod Otomatis <30 dtk Scale up traffic spike Provision instance 15-30 mnt HPA <1 mnt otomatis Rolling update Downtime atau script rumit Zero downtime native Health check Manual cron script Liveness probe native Multi-region failover DNS + manual Service mesh otomatis Total engineer jam/minggu ~20-40 jam ~5-10 jam Saving FTE — ~0,5-1 FTE ($50K/tahun)
K8s hemat 0,5-1 FTE per 10 microservice. Untuk 50 microservice (enterprise), hemat 2-5 FTE.
Mari hitung ROI K8s untuk startup dengan 10 microservice, 5 replica each. Manual vs K8s: restart Pod mati manual 5-10 menit per Pod vs K8s otomatis di bawah 30 detik. Scale up traffic spike provision instance 15-30 menit vs HPA di bawah 1 menit otomatis. Rolling update downtime atau script rumit vs K8s zero downtime native. Health check manual cron script vs K8s liveness probe native. Multi-region failover DNS plus manual vs K8s service mesh otomatis. Total engineer jam per minggu manual 20-40 jam vs K8s 5-10 jam. Saving FTE sekitar 0,5-1 FTE setara 50 ribu dolar per tahun. K8s hemat 0,5-1 FTE per 10 microservice. Untuk 50 microservice enterprise, hemat 2-5 FTE. Learning curve awal 2-3 bulan, tapi ROI setelah itu jelas. Bagian 2 · 2/4
kubectl & Operasional
Diskusi: bila Pod CrashLoopBackOff di produksi, bagaimana debugging step?
Jawaban: kubectl get pods lihat status, kubectl describe pod NAME lihat event, kubectl logs NAME lihat stdout container, kubectl logs NAME --previous bila container restart. Bila image pull error: cek image name dan registry credential. Bila OOMKilled: cek memory limit dan naikkan. Bila CrashLoop: cek config atau env var missing. Workflow debugging ini wajib kuasai sebelum produksi. kubectl Command Cheat Sheet Command-line tool untuk interact dengan K8s cluster. Wajib kuasai dasar.
Command Fungsi Frekuensi Pakai kubectl get pods List Pod dengan status Sangat sering kubectl get all List semua resource namespace Sering kubectl describe pod NAME Detail event & spec Pod Debug kubectl logs NAME Stdout container Debug kubectl apply -f FILE Apply manifest YAML Deploy kubectl delete -f FILE Hapus resource dari manifest Cleanup kubectl exec -it NAME -- sh Shell interaktif Pod Debug advanced kubectl scale deploy NAME --replicas=5 Manual scale Deployment Ops kubectl rollout restart deploy NAME Trigger rolling update Deploy kubectl port-forward svc/NAME 8080:80 Akses Service lokal Debug lokal
Hafal 10 command ini. 80% operasional K8s sehari-hari pakai command ini.
kubectl adalah command-line tool untuk interact dengan K8s cluster. Wajib kuasai dasar. Cheat sheet: kubectl get pods untuk list Pod dengan status, sangat sering dipakai. kubectl get all untuk list semua resource namespace, sering. kubectl describe pod NAME untuk detail event dan spec Pod, untuk debugging. kubectl logs NAME untuk stdout container, debugging. kubectl apply -f FILE untuk apply manifest YAML, untuk deploy. kubectl delete -f FILE untuk hapus resource dari manifest, untuk cleanup. kubectl exec -it NAME -- sh untuk shell interaktif Pod, debug advanced. kubectl scale deploy NAME --replicas=5 untuk manual scale Deployment, ops. kubectl rollout restart deploy NAME untuk trigger rolling update, deploy. kubectl port-forward svc/NAME 8080:80 untuk akses Service lokal, debug lokal. Hafal 10 command ini. 80 persen operasional K8s sehari-hari pakai command ini. Namespace & Resource Quota Namespace = virtual cluster dalam 1 K8s cluster. Resource quota = limit per namespace.
Isolasi tim atau env Contoh: dev, staging, prod RBAC scope per namespace Network policy isolate traffic Limit CPU/memory per namespace Cegah tim nakal hog resource Hard cap untuk cost control Alert bila mendekati limit Multi-tenant cluster: 1 namespace per tim + resource quota + RBAC + network policy. Pola enterprise.
Namespace adalah virtual cluster dalam 1 K8s cluster. Resource quota adalah limit per namespace. Namespace: isolasi tim atau env, contoh dev staging prod, RBAC scope per namespace, network policy isolate traffic. Resource Quota: limit CPU memory per namespace, cegah tim nakal hog resource, hard cap untuk cost control, alert bila mendekati limit. Multi-tenant cluster standard enterprise: 1 namespace per tim plus resource quota plus RBAC plus network policy. Tanpa ini, 1 tim bisa crash cluster dengan resource hog atau security breach lateral ke service lain. Untuk isolasi maksimal, multi-cluster per env atau per team — Trade-off complexity vs isolation. ConfigMap & Secret ConfigMap untuk config non-sensitif, Secret untuk sensitif (password, key). Decouple dari image.
Simpan config non-sensitif Database URL, log level Mount sebagai env var atau file Update tanpa rebuild image Simpan data sensitif Password, API key, cert Base64 encoded (bukan encryption) Encrypt at-rest via etcd encryption Secret base64 bukan encryption. Wajib enable etcd encryption at-rest. AWS Secrets Manager via CSI driver untuk production.
ConfigMap dan Secret adalah dua objek untuk decouple config dari image. ConfigMap untuk config non-sensitif seperti database URL log level, mount sebagai env var atau file, update tanpa rebuild image. Secret untuk data sensitif seperti password API key cert, base64 encoded bukan encryption, encrypt at-rest via etcd encryption. Penting: Secret base64 bukan encryption — siapapun dengan kubectl access bisa decode. Wajib enable etcd encryption at-rest. Untuk production enterprise, gunakan AWS Secrets Manager via CSI driver Secrets Store atau External Secrets Operator untuk sync secret dari vault external seperti HashiCorp Vault. Brikman bab 7 mendalami. Bagian 3 · 3/4
EKS & Helm
Diskusi: bila startup RI baru mau pakai K8s, pilih self-managed atau EKS managed?
Jawaban: EKS managed untuk sebagian besar kasus. Self-managed K8s butuh 1-2 FTE dedicated untuk operasional: upgrade, patching, etcd backup, monitoring. EKS managed: AWS handle control plane, Anda fokus workload. Cost EKS 73 dolar per cluster per bulan plus worker nodes. ROI: hemat 1-2 FTE operasional. Exception: bila butuh kontrol penuh (compliance ketat, custom plugin), self-managed feasible. GKE dan AKS alternatif multi-cloud. AWS EKS Managed Kubernetes EKS = managed Kubernetes di AWS. AWS handle control plane, Anda fokus worker node & workload.
Control plane HA multi-AZ Kubernetes version upgrade etcd backup & restore API server scaling Worker node (EC2, Fargate) Pod scheduling & resource Ingress controller Monitoring & logging EKS cost: $0,10/jam per cluster (~$73/bln) + worker node. Fargate serverless: bayar per Pod.
AWS EKS adalah managed Kubernetes di AWS. AWS handle control plane, Anda fokus worker node dan workload. Yang AWS handle: control plane HA multi-AZ, Kubernetes version upgrade, etcd backup dan restore, API server scaling. Yang Anda handle: worker node EC2 atau Fargate, Pod scheduling dan resource, Ingress controller, monitoring dan logging. EKS cost: 0,10 dolar per jam per cluster setara 73 dolar per bulan plus worker node. Fargate serverless: bayar per Pod, cocok untuk intermittent workload. EKS Anywhere untuk on-prem dan Outposts untuk hybrid. Gojek dan Bank Jago pakai EKS multi-cluster multi-region. Terraform EKS module terraform-aws-modules slash eks untuk provision. Helm Package Manager Helm = NPM/Yum untuk Kubernetes. Package aplikasi sebagai Chart reusable.
Chart = package K8s app values.yaml untuk konfigurasi Template YAML dengan variable Repo publik: hub.helm.sh Reuse aplikasi complex Version & rollback mudah Customize via values.yaml Share ke tim / community Helm solve DRY untuk K8s manifest. Deploy aplikasi 1 command: helm install my-app ./chart.
Helm adalah NPM atau Yum untuk Kubernetes. Package aplikasi sebagai Chart reusable. Konsep: Chart sama dengan package K8s app, values.yaml untuk konfigurasi per env, template YAML dengan variable Go template, repo publik hub.helm.sh untuk community chart. Manfaat: reuse aplikasi complex, version dan rollback mudah, customize via values.yaml, share ke tim atau community. Helm solve DRY don't repeat yourself untuk K8s manifest. Deploy aplikasi 1 command helm install my-app dot slash chart. Bitnami chart populer untuk database. Helm 3 adalah versi terbaru tanpa Tiller, lebih aman. Argo CD dan Flux GitOps untuk Helm continuous deployment. Ingress & Load Balancing Ingress = entry point HTTP/HTTPS ke service K8s. AWS Load Balancer Controller untuk EKS.
Nginx Ingress (populer) AWS Load Balancer Controller (ALB) Traefik, HAProxy alternatif TLS termination via cert-manager Route domain ke Service Path-based routing Host-based multi-tenant Annotation control behavior EKS: AWS Load Balancer Controller auto-provision ALB/NLB bila Ingress dibuat. Integrasi native dengan AWS.
Ingress adalah entry point HTTP HTTPS ke service K8s. AWS Load Balancer Controller untuk EKS. Ingress Controller: Nginx Ingress populer open-source, AWS Load Balancer Controller untuk ALB integration native, Traefik dan HAProxy alternatif, TLS termination via cert-manager untuk HTTPS auto. Ingress Resource: route domain ke Service, path-based routing misalnya slash api ke API service slash static ke web, host-based multi-tenant misalnya app1.com dan app2.com ke service berbeda, annotation control behavior seperti timeout rewrite. EKS AWS Load Balancer Controller auto-provision ALB atau NLB bila Ingress dibuat, integrasi native dengan AWS. Tanpa Ingress, akses Pod hanya via NodePort atau LoadBalancer Service type yang kurang fleksibel. Bagian 4 · 4/4
Best Practice & Penutup
Diskusi: bila startup baru, kapan harus pindah dari docker-compose ke Kubernetes?
Jawaban: ketika tim engineering tumbuh >5 orang atau microservice >5 atau butuh multi-region. Sebelum itu, docker-compose cukup. K8s premature optimization bila hanya 1-2 service dan tim kecil. Cost: learning curve 2-3 bulan, operasional complexity, talent expensive. Rule of thumb: mulai K8s bila rasa sakit manual ops lebih besar dari cost learning K8s. Gojek mulai dengan Mesos lalu K8s saat skala 100+ microservice. Bank Jago langsung K8s dari awal karena tim experienced. K8s Best Practice Production Standard emas production K8s. Checklist wajib sebelum live.
Aspek Best Practice Image Pin tag spesifik, scan vulnerability (Trivy) Resource request & limit CPU/memory wajib Health Liveness & readiness probe Config ConfigMap & Secret (jangan hardcoded) Security RBAC, network policy, non-root user Logging Centralized (Fluent Bit + CloudWatch/Loki) Monitoring Prometheus + Grafana atau CloudWatch Container Insights Backup etcd backup, Velero untuk PV Multi-AZ Pod anti-affinity untuk HA Auto-scaling HPA (CPU) + Cluster Autoscaler
Tanpa resource request/limit, 1 Pod nakal bisa crash cluster. Tanpa probe, K8s tidak tahu Pod healthy.
Standard emas production K8s. Checklist wajib sebelum live. Image: pin tag spesifik bukan latest, scan vulnerability dengan Trivy atau Snyk. Resource: request dan limit CPU memory wajib untuk scheduling dan cegah hog. Health: liveness dan readiness probe untuk self-healing. Config: ConfigMap dan Secret jangan hardcoded. Security: RBAC, network policy, non-root user untuk pod security. Logging: centralized dengan Fluent Bit plus CloudWatch atau Loki. Monitoring: Prometheus plus Grafana atau CloudWatch Container Insights. Backup: etcd backup, Velero untuk persistent volume. Multi-AZ: Pod anti-affinity untuk HA. Auto-scaling: HPA CPU plus Cluster Autoscaler untuk node. Tanpa resource request limit, 1 Pod nakal bisa crash cluster. Tanpa probe, K8s tidak tahu Pod healthy atau tidak. Service Mesh: Istio & Linkerd Service mesh = layer untuk manage service-to-service communication. Maturity tinggi.
mTLS antar service otomatis Traffic splitting (canary) Retry & circuit breaker Observability distributed tracing Complexity tambahan Latency overhead ~1-5 ms Learning curve tinggi Untuk microservice >20 Istio paling populer. Linkerd lebih ringan. Consul Connect alternatif. Belum wajib untuk startup kecil.
Service mesh adalah layer untuk manage service-to-service communication. Maturity tinggi. Fitur: mTLS antar service otomatis untuk security, traffic splitting untuk canary deployment, retry dan circuit breaker untuk resilience, observability distributed tracing untuk debugging. Trade-off: complexity tambahan, latency overhead 1 sampai 5 milidetik, learning curve tinggi, umumnya untuk microservice lebih dari 20. Istio paling populer dengan fitur lengkap. Linkerd lebih ringan dan mudah. Consul Connect alternatif dari HashiCorp. Belum wajib untuk startup kecil dengan 5-10 microservice. Untuk enterprise dengan 50+ service dan requirement mTLS ketat seperti bank, service mesh menjadi wajib. Ringkasan Kunci Pertemuan 11 Hari ini Anda menguasai Kubernetes: Pod, Deployment, Service, kubectl, EKS, Helm.
Triad Fundamental
Pod (unit) + Deployment (replica manager) + Service (network).
Operasional
kubectl dasar. Namespace + Resource Quota untuk multi-tenant.
Ekosistem
EKS managed, Helm package, Ingress LB, Service Mesh.
Tiga lensa P11: declarative desired state · self-healing · auto-scaling.
Persiapan P12: DevOps CI/CD. Baca Brikman bab 4 (CDK) & kimrafik DevOps Handbook. Kuis 5 menit soal Pod vs Deployment.
Tiga pesan kunci: triad fundamental Pod Deployment Service dengan Pod unit Deployment replica manager Service network. Operasional kubectl dasar Namespace plus Resource Quota untuk multi-tenant. Ekosistem EKS managed Helm package Ingress LB Service Mesh. Tiga lensa P11: declarative desired state, self-healing, auto-scaling. P12 kita masuk DevOps CI/CD — baca Brikman bab 4 CDK dan DevOps Handbook. Kuis 5 menit Pod vs Deployment di awal P12. Sampai jumpa.