Kubernetes di Production: Panduan Container Orchestration untuk Tim DevOps Indonesia | Blog

Dari Docker ke Kubernetes: Kapan Tim Anda Siap?

Container telah mengubah cara kita membangun dan mendistribusikan software. Docker membuat packaging aplikasi menjadi konsisten dan portable. Namun ketika jumlah container bertambah dari puluhan menjadi ratusan, pertanyaan besar muncul: siapa yang mengatur semuanya?

Kubernetes (K8s) hadir sebagai jawaban — platform open-source untuk automasi deployment, scaling, dan management containerized applications. Tapi adopsi Kubernetes bukan keputusan ringan. Artikel ini membahas kapan, bagaimana, dan apa yang perlu dipersiapkan oleh tim DevOps Indonesia untuk menjalankan Kubernetes di production.

Mengapa Kubernetes? Memahami Value Proposition

Kubernetes bukan satu-satunya container orchestrator, tapi ia telah menjadi standar de facto industri. Beberapa alasan utama:

Self-Healing dan High Availability

Kubernetes secara otomatis mendeteksi container yang gagal dan me-restart atau me-replace mereka. Health checks (liveness dan readiness probes) memastikan traffic hanya diarahkan ke container yang sehat. Ini memberikan level resilience yang sulit dicapai dengan deployment manual.

Horizontal Auto-Scaling

Horizontal Pod Autoscaler (HPA) secara otomatis menambah atau mengurangi jumlah pod berdasarkan CPU utilization, memory usage, atau custom metrics. Saat traffic peak (misalnya flash sale atau akhir bulan untuk aplikasi perbankan), sistem scale up otomatis. Saat idle, scale down untuk menghemat biaya.

Declarative Configuration

Semua konfigurasi infrastruktur dideklarasikan dalam YAML manifests yang bisa di-version control dengan Git. Ini berarti infrastructure menjadi reproducible, auditable, dan reviewable melalui pull request — fondasi dari GitOps workflow.

Portabilitas Multi-Cloud

Aplikasi yang berjalan di Kubernetes bisa dipindahkan antar cloud provider dengan perubahan minimal. Ini mengurangi vendor lock-in dan memberikan flexibility dalam strategi cloud.

Arsitektur Kubernetes Cluster: Komponen Utama

Memahami arsitektur cluster adalah fondasi sebelum deploy ke production.

Control Plane

Otak dari cluster Kubernetes yang mengelola state desired. Terdiri dari:

API Server: Gateway untuk semua operasi cluster. Kubectl, CI/CD tools, dan monitoring systems berinteraksi melalui API Server.
etcd: Distributed key-value store yang menyimpan seluruh state cluster. Backup etcd adalah lifeline — kehilangan etcd berarti kehilangan cluster.
Scheduler: Menentukan di node mana pod akan dijalankan berdasarkan resource requirements, affinity rules, dan constraints.
Controller Manager: Menjalankan control loops yang memastikan actual state sesuai dengan desired state — ReplicaSet controller, Deployment controller, dan lainnya.

Worker Nodes

Mesin (VM atau bare metal) tempat workload berjalan. Setiap node menjalankan:

Kubelet: Agent yang berkomunikasi dengan control plane dan memastikan container berjalan sesuai pod spec.
Container Runtime: Engine yang menjalankan container — containerd atau CRI-O (Docker runtime sudah deprecated di K8s 1.24+).
Kube-proxy: Mengelola network rules untuk service discovery dan load balancing internal.

Networking Model

Kubernetes mengadopsi flat network model — setiap pod mendapat IP address sendiri dan bisa berkomunikasi dengan pod lain tanpa NAT. Implementasinya melalui CNI (Container Network Interface) plugins seperti Calico, Cilium, atau Flannel.

Managed vs Self-Hosted: Keputusan Kritis

Ini adalah keputusan arsitektural terpenting yang harus dibuat tim DevOps.

Managed Kubernetes (EKS, GKE, AKS)

Keuntungan:

Control plane dikelola provider — upgrade, patching, dan HA otomatis
Integrasi native dengan layanan cloud (IAM, load balancer, storage, monitoring)
Mengurangi operational burden tim DevOps
SLA dari provider (99.95% uptime untuk control plane)

Kekurangan:

Biaya management fee per cluster (rata-rata $73/bulan untuk EKS)
Kurang fleksibel untuk customization control plane
Vendor lock-in pada beberapa fitur spesifik

Self-Hosted (kubeadm, k3s, RKE)

Keuntungan:

Full control atas seluruh komponen cluster
Tidak ada management fee
Cocok untuk on-premise, edge computing, atau hybrid deployment
Flexibility penuh dalam memilih komponen (CNI, CSI, ingress controller)

Kekurangan:

Tim bertanggung jawab penuh atas upgrade, patching, backup, dan HA
Memerlukan deep expertise Kubernetes
Operational overhead signifikan

Rekomendasi untuk Tim Indonesia

Untuk sebagian besar enterprise Indonesia yang baru memulai, managed Kubernetes adalah pilihan yang lebih pragmatis. Fokuskan energi tim pada application layer dan developer experience, bukan pada maintenance control plane. Pertimbangkan self-hosted hanya jika ada requirement spesifik (on-premise, airgapped, atau edge deployment).

Production Readiness Checklist

Sebelum deploy workload ke production, pastikan cluster memenuhi checklist berikut:

Security

RBAC (Role-Based Access Control): Terapkan principle of least privilege. Jangan gunakan cluster-admin untuk semua user.
Network Policies: Batasi komunikasi antar pod. Default deny, explicit allow.
Pod Security Standards: Enforce restricted profile — no root containers, no privilege escalation, read-only root filesystem.
Secret Management: Gunakan external secret management (HashiCorp Vault, AWS Secrets Manager) — jangan simpan secrets di YAML plain text.
Image Security: Scan container images untuk vulnerabilities (Trivy, Snyk). Enforce image signing dan trusted registries.

Observability

Metrics: Prometheus + Grafana untuk cluster dan application metrics. Monitor CPU, memory, disk, network per node dan per pod.
Logging: Centralized logging dengan EFK stack (Elasticsearch, Fluentd, Kibana) atau Loki + Grafana.
Tracing: Distributed tracing dengan Jaeger atau OpenTelemetry untuk troubleshoot latency issues.
Alerting: Configure meaningful alerts — bukan alert fatigue. Focus pada SLO-based alerting.

Reliability

Pod Disruption Budgets (PDB): Pastikan minimum number of pods tetap running saat maintenance.
Resource Requests dan Limits: Set untuk setiap container — prevent noisy neighbor dan OOM kills.
Multi-AZ Deployment: Spread pods across availability zones untuk high availability.
Backup Strategy: Regular backup etcd. Gunakan Velero untuk backup namespaces dan persistent volumes.

CI/CD Integration

GitOps Workflow: Gunakan ArgoCD atau Flux untuk declarative, Git-driven deployments.
Progressive Delivery: Implement canary deployments atau blue-green dengan Argo Rollouts.
Automated Testing: Integration tests dan smoke tests sebagai bagian dari deployment pipeline.

Kubernetes Anti-Patterns yang Harus Dihindari

Menggunakan latest tag — Selalu gunakan specific version tag untuk reproducibility
Tidak set resource limits — Satu pod bisa menghabiskan resource seluruh node
Menyimpan state di container — Gunakan Persistent Volumes atau external database
Single replica di production — Minimum 2 replicas dengan PDB untuk zero-downtime deployment
Skip health checks — Tanpa liveness/readiness probes, Kubernetes tidak tahu kondisi aplikasi
Over-engineering di awal — Mulai dengan setup sederhana, tambah complexity sesuai kebutuhan

Cost Optimization untuk Kubernetes di Indonesia

Biaya Kubernetes bisa membengkak tanpa governance yang tepat:

Right-sizing: Analisis actual resource usage vs requested. Tools seperti Goldilocks dan VPA memberikan recommendations.
Spot/Preemptible Instances: Untuk workload stateless dan batch processing, spot instances bisa menghemat 60-90% biaya compute.
Cluster Autoscaler: Otomatis menambah/mengurangi nodes berdasarkan pending pods. Jangan over-provision nodes.
Namespace Resource Quotas: Prevent satu tim menghabiskan resource cluster.

Kesimpulan

Kubernetes di production memerlukan lebih dari sekadar kubectl apply. Ini memerlukan mindset shift dari traditional infrastructure management ke platform thinking — di mana developer experience, security, observability, dan cost governance menjadi first-class concerns.

Divistant membantu tim DevOps Indonesia dalam perjalanan Kubernetes mereka — dari initial architecture design, migration dari Docker Compose ke K8s, hingga production hardening dan ongoing optimization. Hubungi tim kami untuk diskusi arsitektur Kubernetes yang sesuai dengan kebutuhan Anda.

FAQ

Q: Apakah Kubernetes cocok untuk startup kecil? A: Tidak selalu. Jika tim kecil (<5 engineer) dan workload sederhana, Docker Compose atau managed PaaS (Cloud Run, App Engine) mungkin lebih appropriate. Adopt K8s saat complexity dan scale justify-nya.

Q: Berapa minimum tim untuk mengelola Kubernetes production? A: Dengan managed K8s, 1-2 DevOps/SRE engineer bisa mengelola cluster kecil-menengah. Self-hosted memerlukan minimum 2-3 engineer dedicated.

Q: K8s distribution mana yang direkomendasikan untuk on-premise? A: k3s untuk edge/small deployments, RKE2 untuk enterprise on-premise, atau OpenShift untuk yang memerlukan enterprise support dan integrated CI/CD.