Kubernetes sering dipelajari sebagai API object yang bisa di-apply dengan kubectl, tetapi produksi adalah tempat di mana abstraksi bertemu realitas: node crash, network partition, storage latency, dan cost escalation. Artikel ini membawa engineer dari konsep inti Kubernetes hingga pola arsitektur yang dipakai tim produksi untuk menjalankan workload yang benar-benar Andal.
Arsitektur kontrol plane: etcd, API server, scheduler, dan controller manager
Kontrol plane adalah otak cluster. API server menjadi gateway tunggal untuk semua perubahan state; semua komunikasi internal maupun eksternal melewatinya. etcd menyimpan state cluster secara konsisten menggunakan Raft consensus. Jika etcd lambat, seluruh cluster akan terasa lambat karena API server menunggu write acknowledgment.
Scheduler menentukan di node mana pod akan dijalankan berdasarkan resource request, affinity, anti-affinity, dan taint/toleration. Controller manager menjalankan controller loop yang memastikan state aktual mendekati state desired, misalnya replication controller mempertahankan jumlah replica, dan endpoint controller menyusun daftar IP pod yang siap melayani.
Di produksi, kontrol plane harus dijalankan di node yang terpisah dari worker. Alasan sederhana: jika worker node crash dan kontrol plane ikut mati, cluster menjadi unrecoverable tanpa manual intervention. Juga, aktifkan high-availability kontrol plane dengan tiga atau lima member agar single node failure tidak membuat cluster mati.
Workload: Deployment, StatefulSet, DaemonSet, dan Job
Deployment adalah workload paling umum untuk stateless application. Ia mendukung rolling update, rollback, dan scaling horizontal. StatefulSet dirancang untuk stateful workload seperti database dan message queue yang membutuhkan stable network identity dan stable storage. Setiap replica mendapat nama deterministic dan penyimpanan yang terpisah.
DaemonSet menjamin satu pod berjalan di setiap node atau subset node yang cocok dengan node selector. Gunakan DaemonSet untuk logging agent, metrics collector, network plugin, atau security scanner yang harus hadir di setiap node. Job dan CronJob menangani batch processing yang berakhir atau berjalan secara periodik. Job memastukan pod berjalan sampai selesai, sedangkan CronJob menambahkan schedule semacam cron.
Pemilihan workload yang tepat menghindari arsitektur yang tidak sesuai. Jika Anda menggunakan Deployment untuk database, Anda kehilangan stable identity yang dibutuhkan oleh client untuk reconnect setelah rolling update. Jika Anda menggunakan StatefulSet untuk API stateless, Anda menambah kompleksitas yang tidak dibutuhkan.
Networking: CNI, service, ingress, dan network policy
Setiap pod memerlukan IP yang bisa reach dari node lain. CNI plugin adalah interface yang membuat networking berfungsi. Pilihan populer: Calico untuk policy enforcement dan BGP routing, Cilium untuk eBPF-based security dan observability, dan Flannel untuk overlay sederhana.
Service menyediakan stable virtual IP dan DNS name untuk sekumpulan pod. ClusterIP hanya bisa diakses dari dalam cluster. NodePort mengekspos service di setiap node pada port statis. LoadBalancer meminta cloud provider untuk menyediakan external load balancer. Ingress adalah resource layer 7 yang mengarahkan traffic berdasarkan host dan path ke service yang sesuai. Ingress controller seperti Nginx, Traefik, atau Istio Gateway menerjemahkan Ingress resource menjadi konfigurasi proxy yang berjalan.
Network policy adalah firewall di level pod. Tanpa policy, semua pod saling bisa communicate. Implementasikan default deny all, kemudian buka rule untuk traffic yang memang dibutuhkan. Misalnya, hanya izinkan traffic dari namespace frontend ke service backend pada port 443. Pendekatan ini mengurangi blast radius jika pod terkompromasi.
Storage: PersistentVolume, StorageClass, dan CSI
Penyimpanan di Kubernetes diabstraksi melalui PersistentVolumeClaim. Pod mengajukan claim, dan cluster menyediakan volume sesuai StorageClass. Untuk cloud provider, StorageClass biasanya memetakan ke managed disk atau block storage. Untuk on-premise, StorageClass bisa memetakan ke NFS atau Ceph.
Pilih tipe storage sesuai workload. Database membutuhkan disk yang konsisten dan cepat: SSD block storage dengan IOPS yang terjamin. File upload atau media bisa menggunakan object storage melalui MinIO atau cloud S3. Log dan cache bisa menggunakan tmpfs atau ephemeral disk yang tidak membutuhkan durabilitas.
Jangan pernah menjalankan database di dalam Kubernetes sebelum storage class benar-benar diuji untuk latency dan throughput. Banyak tim lompat ke Kubernetes untuk database dan mengalami masalah karena storage class default menggunakan HDD atau network filesystem yang tidak cocok untuk transaksi database.
Security: RBAC, pod security, secrets, dan admission control
RBAC menentukan siapa yang bisa melakukan apa di cluster. Selalu ikuti prinsip least privilege: berikan permission hanya untuk resource dan namespace yang dibutuhkan. Jangan pernah menggunakan cluster-admin untuk developer Selain RBAC, pod security memastikan container berjalan dengan permission yang aman. Pod Security Standards mendefinisikan tiga level: privileged, baseline, dan restricted. Terapkan restricted untuk namespace produksi karena melarang privilege escalation, host namespace sharing, dan capability yang berbahaya.
Secrets disimpan di etcd yang terenkripsi secara default di banyak distribusi, tetapi pastikan etcd encryption diaktifkan. Jangan pernah menyimpan secrets di ConfigMap karena tidak dienkripsi. Gunakan external secrets operator untuk menyinkronkan secrets dari vault atau cloud secret manager ke Kubernetes secrets.
Admission control adalah gateway untuk memvalidasi dan memodifikasi request sebelum masuk ke API server. OPA Gatekeeper atau Kyverno menerapkan policy seperti maksimum CPU request, image yang hanya boleh berasal dari registry terpercaya, atau label yang wajib ada. Tanpa admission control, konfigurasi berbahaya bisa masuk cluster tanpa terdeteksi.
Cost management di Kubernetes
Kubernetes memudahkan provisioning, tetapi juga memudahkan waste. Tanpa kontrol, developer bisa membuat deployment dengan resource request yang terlalu besar atau meninggalkan workload yang tidak digunakan. Terapkan resource request dan limit untuk setiap container. Request menentukan berapa resource yang dipastikan diberikan; limit menentukan batas maksimum. Kedua nilai harus ditetapkan berdasarkan observasi production metrics, bukan tebakan.
Gunakan tool seperti Kubecost atau OpenCost untuk mengukur cost per namespace, per deployment, dan per team. Kubecost menunjukkan right-sizing recommendation dan mendeteksi idle resources. Jika cluster berjalan di cloud provider, aktifkan autoscaling: cluster autoscaler menambah atau mengurangi node sesuai pending pod, dan horizontal pod autoscaler menyesuaikan jumlah replica berdasarkan CPU, memory, atau metric kustom.
Spot instance atau preemptible VM bisa mengurangi cost hingga 90 persen, tetapi mereka bisa diambil kembali kapan saja. Jalankan workload fault-tolerant seperti batch processing, CI/CD, dan stateless API di spot instance. Jangan menjalankan database atau latency-sensitive workload di spot.
CI/CD dan GitOps di Kubernetes
Deployment manual dengan kubectl tidak skalabel dan berisiko human error. GitOps mendeklarasikan state cluster di repository Git, dan agent seperti ArgoCD atau FluxCD menyinkronkan state git ke cluster secara otomatis. Setiap perubahan harus melalui pull request, memberikan audit trail dan code review.
Pipeline CI/CD membangun image, menjalankan test, scan vulnerability, dan mengemas Helm chart atau Kustomize overlay. Setelah image siap, pipeline menuliskan tag image ke Git repository manifests. ArgoCD mendeteksi perubahan dan melakukan deployment. Jika ada masalah, rollback cukup revert commit Git dan sinkronisasi akan memulihkan state sebelumnya.
Praktik yang direkomendasikan adalah memisahkan staging dan production namespace. Staging menerima perubahan yang masih dalam testing. Production hanya menerima perubahan yang sudah melewati staging dan disetujui. Gunakan promotion workflow: staging dipromosikan ke production melalui penyalinan manifest yang sudah terverifikasi, bukan rebuild image baru.
Observability: metrics, logging, dan tracing
Prometheus adalah standar de facto untuk metrics di Kubernetes. Cluster dengan kube-state-metrics dan node exporter menyediakan metrics tentang node, pod, dan resource utilization. Instrumentasi aplikasi dengan OpenMetrics exposition format agar Prometheus bisa scrape. Bangun dashboard Grafana untuk ringkasan cluster: CPU request versus limit, memory pressure, pod restart count, PVC usage, dan ingress latency.
Logging di Kubernetes menggunakan sidecar atau node agent untuk mengumpulkan log dari container stdout. Agent seperti Fluent Bit atau Promtail mengirim log ke Loki atau Elasticsearch. Pastikan log mengandung metadata penting: namespace, pod name, container name, dan labels. Metadata ini memudahkan query saat insiden terjadi.
Tracing lintas pod memerlukan OpenTelemetry collector yang dijalankan sebagai sidecar atau agent node. Trace context disebarkan melalui header HTTP. Jika service memanggil message queue atau background job, pastikan propagasi context tetap berfungsi. Distributed tracing adalah cara terbaik melacak request yang melewati lima atau lebih service di cluster.
Service mesh: Istio, Linkerd, dan Cilium
Ketika jumlah service bertambah, cross-cutting concern seperti retry, timeout, circuit breaker, dan traffic splitting menjadi semakin rumit jika diimplementasikan di setiap aplikasi. Service mesh memasukkan proxy sidecar di setiap pod untuk menangani concern tersebut secara terpusat.
Istio adalah pilihan feature-rich dengan traffic management kuat, tetapi cenderung kompleks. Linkerd menawarkan setup lebih sederhana dengan overhead lebih kecil. Cilium mengandalkan eBPF untuk networking dan security tanpa sidecar, menjadikannya pilihan menarik untuk cluster yang ingin menghindari overhead proxy.
Service mesh juga menyediakan mTLS otomatis antar service, authorization policy berbasis identitas service, dan observability granular. Namun jangan deploy service mesh sebelum benar-benar memahami konsep dan kebutuhan. Mesh introduction bisa menambah latency dan kompleksitas yang tidak dibutuhkan untuk cluster kecil.
Kesalahan umum yang menghancurkan produksi
Kesalahan pertama adalah mengabaikan resource quota di namespace produksi. Tanpa quota, satu developer bisa membuat deployment yang menghabiskan seluruh cluster dan memengaruhi semua orang. Terapkan ResourceQuota dan LimitRange agar setiap namespace memiliki batasan yang jelas.
Kesalahan kedua adalah tidak menguji rolling update. Banyak insiden terjadi karena rolling update tidak menunggu pod baru siap sebelum mematikan pod lama. Pastikan readiness probe memeriksa kondisi sesungguhnya, bukan hanya port terbuka. Startup probe harus mencoba beberapa kali sebelum menandai pod tidak sehat.
Kesalahan ketiga adalah menggunakan default namespace untuk produksi. Semua resource dari semua tim berkumpul di satu tempat, membuat troubleshooting dan access control sangat sulit. Buat namespace per environment dan per team. Gunakan RBAC untuk membatasi akses ke namespace masing-masing.
Kesalahan keempat adalah mengandalkan kubectl sebagai audit trail. kubectl apply tidak tercatat otomatis. Gunakan Git sebagai single source of truth dan aktifkan audit logging di API server. Audit log menunjukkan siapa, kapan, dan apa yang diubah di cluster dan sangat berharga saat investigasi insiden.
High availability dan disaster recovery
High availability di Kubernetes dimulai dari node level. Gunakan node group dengan spread_across_zones agar node tidak berada di zone yang sama. Pod disruption budget menjamin jumlah minimum pod yang tersedia selama maintenance voluntary disruption. Jika deployment memiliki 3 replica, set PDB minimal available 2 agar scheduling tidak mematikan lebih dari satu replica pada satu waktu.
Disaster recovery memerlukan backup etcd secara berkala. etcd adalah satu-satunya state of truth cluster. Tanpa backup, kehilangan etcd berarti kehilangan seluruh konfigurasi cluster. Simpan backup di lokasi yang terpisah dari cluster. Uji restore secara berkala karena backup yang tidak diuji adalah backup yang tidak terbukti bekerja.
Untuk stateful workload, backup application-level lebih penting daripada cluster-level. Database replication dan WAL archiving menjamin pemulihan point-in-time. Object storage dengan versioning melindungi file dari penghapusan yang tidak disengaja. Gabungkan keduanya: backup etcd untuk infrastructure recovery dan backup application untuk data recovery.
Roadmap: setelah Kubernetes dasar
Setelah cluster produksi stabil, eksplorasi area lanjutan: operator pattern untuk mengotomatisasi operational knowledge, service mesh untuk traffic management yang lebih halus, dan progressive delivery dengan Argo Rollouts untuk canary dan blue-green deployment.
Jangan mencoba mempelajari semua sekaligus. Fokus pada area yang memberikan dampak terbesar: reliability melalui probe dan HPA, security melalui RBAC dan network policy, observability melalui metrics dan logging. Kemenangan kecil yang konsisten lebih baik daripada migrasi besar yang berisiko tinggi.
Kesimpulan
Kubernetes adalah platform yang kuat, tetapi kekuatannya hanya terasa ketika cluster dijalankan dengan disiplin produksi: resource yang dibatasi, workload yang sesuai, security policy yang diterapkan, dan observability yang lengkap. Artikel ini telah membahas fondasi yang dibutuhkan untuk mengoperasikan cluster yang andal. Ingatlah bahwa Kubernetes adalah tools, bukan tujuan. Tujuan akhir adalah membangun sistem yang bisa dipercaya oleh pengguna dan tim engineering.
