# Strategi Deployment Kubernetes yang Perlu Anda Ketahui > Kuasai deployment Blue-Green, Canary, dan Rolling di Kubernetes. Pelajari kapan menggunakan masing-masing strategi beserta contoh YAML nyata. URL: https://www.matthewswong.com/id/blog/kubernetes-deployment-strategies/ - Author: Matthews Wong (https://www.matthewswong.com/id/about/) - Published: 2024-08-05 - Updated: 2024-08-05 - Category: DevOps Strategi deployment Kubernetes menentukan bagaimana aplikasi Anda bertransisi dari satu versi ke versi berikutnya tanpa mengganggu pengguna. Memilih strategi yang salah bisa berarti menit-menit downtime, rollout buruk yang menjangkau semua pengguna sekaligus, atau pemborosan biaya infrastruktur. Dalam artikel ini kita mengurai Rolling Update, Blue-Green, dan Canary deployment — kapan menggunakan masing-masing, trade-off-nya, dan contoh YAML yang langsung dapat diterapkan ke cluster Anda hari ini. ## Mengapa Strategi Deployment Itu Penting Setiap deployment membawa risiko. Image baru mungkin memperkenalkan regresi, migrasi database bisa merusak kompatibilitas mundur, atau masalah performa mungkin hanya muncul di bawah beban produksi. Strategi deployment adalah alat utama Anda untuk mengendalikan blast radius: berapa banyak pengguna yang terdampak, berapa lama, dan seberapa cepat Anda bisa pulih. ### Default: Rolling Update Kubernetes secara default mengganti Pod secara bertahap — memunculkan replika baru sebelum menghentikan yang lama. Dengan pengaturan maxSurge dan maxUnavailable Anda mengontrol seberapa agresif rollout berjalan. Rolling update bersifat zero-downtime untuk layanan stateless dan tidak memerlukan infrastruktur tambahan, menjadikannya pilihan tepat untuk sebagian besar deployment. ### Kapan Rolling Update Tidak Cukup Rolling update mencampur Pod lama dan baru selama jendela transisi, yang merusak skenario yang memerlukan isolasi versi ketat — misalnya migrasi skema database yang tidak kompatibel mundur dengan versi aplikasi lama. Dalam kasus tersebut Anda memerlukan Blue-Green atau Canary yang dikontrol feature flag. > Tetapkan 'minReadySeconds: 30' pada Deployment Anda agar Kubernetes menunggu 30 detik setelah Pod baru lulus readiness probe sebelum menghitungnya sebagai tersedia. Ini memberi waktu pemanasan pada aplikasi Anda dan mencegah traffic diarahkan ke Pod yang secara teknis siap tetapi belum hangat. ## Deployment Blue-Green di Kubernetes Blue-Green mempertahankan dua environment identik — Blue (live) dan Green (staging). Anda men-deploy versi baru ke Green, menjalankan smoke test, kemudian membalik selector Service tunggal untuk merutekan 100% traffic dari Blue ke Green. Environment Blue lama tetap utuh untuk rollback instan: cukup balik selectornya. ### Implementasi Blue-Green dengan Service Selector Kuncinya adalah field selector pada Service. Deployment Blue maupun Green berbagi label 'app: myapp' yang sama tetapi berbeda dengan 'version: blue' dan 'version: green'. Mengubah Service selector adalah satu perintah kubectl patch dan berlaku dalam hitungan detik tanpa restart Pod apa pun. ### Implikasi Biaya dan Sumber Daya Blue-Green menggandakan jejak komputasi selama transisi. Untuk deployment besar ini cukup signifikan. Mitigasinya adalah men-scale Green turun ke nol setelah cutover dikonfirmasi stabil, kemudian men-scale Blue turun. Tools seperti Argo Rollouts mengotomasi siklus hidup ini dan bahkan mengintegrasikan dengan load balancer untuk weighted traffic splitting tanpa menduplikasi Service. ## Canary Deployment: Pergeseran Traffic Bertahap Canary release mengirimkan sebagian kecil traffic produksi nyata ke versi baru sementara mayoritas terus menghantam versi stabil. Anda mengamati error rate, latensi, dan metrik bisnis kustom sebelum secara bertahap meningkatkan bobot canary. Jika ada yang terlihat salah Anda langsung mengalihkan 100% kembali ke stabil. ### Canary Native Kubernetes dengan Rasio Replika Canary native paling sederhana menggunakan dua Deployment (stable: 9 replika, canary: 1 replika) yang sama-sama dipilih oleh Service yang sama. Dengan total 10 Pod, sekitar 10% permintaan mendarat di canary. Untuk kontrol lebih halus tanpa perubahan Ingress Anda memerlukan service mesh (Istio, Linkerd) atau Ingress controller yang mendukung traffic splitting. > **Perhatikan Session Stickiness pada Canary Deploy** > Jika aplikasi Anda menggunakan sesi server-side atau sticky cookie, beberapa pengguna mungkin terpaku ke versi canary untuk seluruh sesi mereka. Pastikan metrik Anda tersegmentasi berdasarkan label versi, bukan hanya error rate keseluruhan, agar Anda bisa membedakan masalah canary dari noise baseline. Gunakan label selector Prometheus seperti 'version="canary"' dalam kueri Anda. ## Argo Rollouts: Progressive Delivery Tingkat Lanjut Argo Rollouts memperluas Kubernetes dengan custom resource Rollout yang mengimplementasikan Blue-Green dan Canary secara native, mengintegrasikan dengan analysis template (kueri metrik otomatis untuk mempromosikan atau membatalkan), dan menyediakan dashboard UI. Ini adalah pilihan siap produksi ketika Anda memerlukan analisis Canary otomatis tanpa memelihara skrip kustom. ### Analysis Template dan Promosi Otomatis AnalysisTemplate mendefinisikan kueri PromQL dan kriteria keberhasilan. Selama rollout Canary, Argo Rollouts menjalankan analisis pada setiap interval langkah. Jika kueri mengembalikan nilai di luar ambang batas — misalnya error rate di atas 1% — rollout secara otomatis dibatalkan dan versi stabil dipulihkan tanpa intervensi manusia apa pun. ### Mengintegrasikan Rollouts dengan GitHub Actions Setelah pipeline CI membangun dan mendorong image baru, langkah CD dapat memanggil 'kubectl argo rollouts set image' untuk memulai progressive delivery. Pipeline kemudian dapat menunggu dan memantau status rollout serta menggagalkan workflow jika rollout dibatalkan. > Gunakan langkah traffic mirror Argo Rollouts untuk membayangi sebagian kecil traffic live ke canary tanpa memengaruhi respons pengguna. Ini memberi Anda load testing dunia nyata dengan nol dampak pengguna sebelum Anda mulai menggeser bobot traffic sebenarnya. ## Memilih Strategi yang Tepat Rolling Update adalah default dan mencakup 80% kasus penggunaan — layanan stateless, aplikasi frontend, dan sebagian besar backend API. Blue-Green ideal untuk migrasi database, environment sensitif compliance yang memerlukan cutover bersih, atau kapan pun Anda memerlukan rollback instan. Canary terbaik ketika Anda menginginkan sinyal pengguna nyata sebelum rollout penuh, terutama untuk layanan traffic tinggi di mana bahkan 1% error rate memiliki dampak bisnis yang terukur. ### Matriks Keputusan Tanyakan pada diri sendiri: apakah versi baru berbagi skema database dengan yang lama? Jika ya dan migrasinya tidak kompatibel mundur, Anda butuh Blue-Green. Apakah Anda memiliki stack metrik yang kuat dan ingin paparan pengguna bertahap? Gunakan Canary dengan Argo Rollouts. Apakah perubahan berisiko rendah dan sepenuhnya kompatibel mundur? Rolling Update dengan nilai maxUnavailable yang wajar sudah cukup. ## Source links - https://kubernetes.io/docs/concepts/workloads/controllers/deployment/ - https://kubernetes.io/docs/concepts/cluster-administration/manage-deployment/ - https://martinfowler.com/bliki/BlueGreenDeployment.html - https://martinfowler.com/bliki/CanaryRelease.html ## FAQ ### Kapan sebaiknya menggunakan Blue-Green dibanding Rolling Update? Blue-Green adalah pilihan tepat ketika migrasi skema database tidak kompatibel mundur dengan versi aplikasi lama, karena Rolling Update mencampur Pod lama dan baru selama jendela transisi. Strategi ini juga ideal untuk environment sensitif compliance yang memerlukan cutover bersih dan rollback instan — cukup balik Service selector ke environment lama. ### Bagaimana Canary deployment native Kubernetes mengontrol persentase traffic tanpa service mesh? Pendekatan paling sederhana menggunakan dua Deployment yang berbagi Service selector yang sama — misalnya 9 replika stabil dan 1 replika canary — sehingga canary mendapat sekitar 10% permintaan. Untuk kontrol lebih halus tanpa mengubah Ingress, Anda memerlukan service mesh seperti Istio atau Linkerd, atau Ingress controller yang mendukung traffic splitting. ### Apa yang ditambahkan Argo Rollouts dibanding Deployment Kubernetes biasa? Argo Rollouts memperkenalkan custom resource Rollout yang mengimplementasikan Blue-Green dan Canary secara native serta menambahkan AnalysisTemplate — kueri PromQL otomatis yang mempromosikan atau membatalkan rollout berdasarkan kriteria keberhasilan. Alat ini juga menyediakan dashboard UI dan terintegrasi dengan GitHub Actions sehingga pipeline CD dapat memantau status rollout dan gagal otomatis jika canary dibatalkan. ### Mengapa perlu menetapkan minReadySeconds pada Deployment? Menetapkan minReadySeconds: 30 membuat Kubernetes menunggu 30 detik setelah Pod baru lulus readiness probe sebelum menghitungnya sebagai tersedia. Ini memberi waktu pemanasan pada aplikasi dan mencegah traffic diarahkan ke Pod yang secara teknis siap tetapi belum benar-benar hangat. ### Bagaimana memilih antara Rolling Update, Blue-Green, dan Canary untuk perubahan tertentu? Rolling Update mencakup sekitar 80% kasus penggunaan — layanan stateless, aplikasi frontend, dan perubahan backend yang kompatibel mundur. Gunakan Blue-Green ketika migrasi tidak kompatibel mundur atau Anda butuh rollback instan. Pilih Canary ketika Anda menginginkan sinyal pengguna nyata sebelum rollout penuh, terutama untuk layanan traffic tinggi di mana bahkan 1% error rate memiliki dampak bisnis yang terukur. --- - HTML version: https://www.matthewswong.com/id/blog/kubernetes-deployment-strategies/ - English: https://www.matthewswong.com/en/blog/kubernetes-deployment-strategies/ - Site index for agents: https://www.matthewswong.com/llms.txt - Sitemap: https://www.matthewswong.com/sitemap.xml - API description (OpenAPI): https://www.matthewswong.com/openapi.json