Panduan lengkap Rolling Update dan Rollback Kubernetes: cara update aplikasi tanpa downtime & rollback cepat dengan kubectl rollout. Praktis untuk sysadmin.

Bayangkan Anda baru saja merilis versi terbaru aplikasi ke production, lalu beberapa menit kemudian tim support melaporkan banjir keluhan: aplikasi error, pengguna tidak bisa login, transaksi gagal. Dalam situasi seperti ini, kecepatan bereaksi adalah segalanya. Satu menit downtime pada aplikasi e-commerce skala besar bisa berarti kehilangan jutaan rupiah pendapatan, belum lagi kepercayaan pelanggan yang tergerus.

Inilah alasan mengapa Rolling Update dan Rollback menjadi dua fitur paling krusial dalam ekosistem Kubernetes. Rolling Update memungkinkan Anda memperbarui aplikasi secara bertahap tanpa mematikan seluruh layanan sekaligus, sementara Rollback memberi jalan keluar instan ketika versi baru ternyata bermasalah.

Bagi seorang DevOps Engineer, Sysadmin, maupun System Administrator yang mengelola infrastruktur berbasis container, memahami cara kerja kedua mekanisme ini bukan sekadar “nice to have”, melainkan kebutuhan dasar untuk menjaga high availability sistem. Artikel ini akan membahas secara tuntas, mulai dari konsep dasar, cara kerja di balik layar, langkah praktis menggunakan kubectl, hingga kesalahan umum yang sering terjadi dan cara menghindarinya.

Apa Itu Rolling Update di Kubernetes?

Rolling Update adalah strategi deployment default di Kubernetes yang memperbarui Pod secara bertahap, satu per satu atau dalam kelompok kecil, alih-alih mematikan semua Pod versi lama sekaligus lalu menyalakan versi baru secara serentak (yang dikenal sebagai strategi Recreate).

Analoginya sederhana: bayangkan sebuah restoran yang ingin mengganti seluruh menunya. Alih-alih menutup restoran sepenuhnya selama proses pergantian menu (yang membuat pelanggan pergi), pemilik restoran mengganti menu secara bertahap—beberapa meja dilayani dengan menu baru, sementara meja lain masih menggunakan menu lama, sampai akhirnya semua meja beralih ke menu baru. Pelanggan tetap bisa makan sepanjang waktu, tanpa merasakan gangguan berarti.

Di Kubernetes, “meja” ini adalah Pod, dan proses pergantian menu adalah Rolling Update yang dikendalikan oleh objek Deployment.

Cara Kerja Rolling Update

Ketika Anda memperbarui image container pada sebuah Deployment, Kubernetes akan:

Membuat ReplicaSet baru yang merepresentasikan versi aplikasi terbaru.
Menaikkan jumlah Pod baru secara bertahap sesuai konfigurasi maxSurge.
Menurunkan jumlah Pod lama secara bertahap sesuai konfigurasi maxUnavailable.
Menunggu setiap Pod baru dinyatakan “Ready” melalui readiness probe sebelum melanjutkan ke batch berikutnya.
Proses berulang sampai seluruh Pod lama tergantikan oleh Pod baru.

Selama proses ini berlangsung, kombinasi Pod lama dan Pod baru akan melayani traffic secara bersamaan melalui Service, sehingga aplikasi tetap dapat diakses pengguna tanpa jeda.

Parameter Penting: maxSurge dan maxUnavailable

Dua parameter ini menentukan seberapa agresif atau seberapa hati-hati proses rolling update dilakukan:

maxSurge: jumlah maksimum Pod tambahan yang boleh dibuat di atas jumlah replika yang diinginkan selama proses update. Bisa berupa angka absolut atau persentase.
maxUnavailable: jumlah maksimum Pod yang boleh tidak tersedia (down) selama proses update berlangsung.

Secara default, Kubernetes menetapkan nilai 25% untuk keduanya. Artinya, pada Deployment dengan 4 replika, maksimal 1 Pod boleh down dan maksimal 1 Pod tambahan boleh dibuat di setiap tahap update.

Contoh konfigurasi dalam manifest YAML:

spec:
  replicas: 4
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1

Jika Anda menginginkan proses yang lebih konservatif (misalnya untuk aplikasi dengan traffic tinggi), Anda bisa menyetel maxUnavailable: 0 sehingga tidak ada satu pun Pod yang boleh down, dengan konsekuensi proses update sedikit lebih lambat karena harus menunggu Pod baru siap terlebih dahulu sebelum Pod lama dimatikan.

Praktik Rolling Update dengan kubectl

Berikut adalah langkah-langkah praktis melakukan rolling update menggunakan kubectl.

Langkah 1: Membuat Deployment Awal

kubectl create deployment webapp --image=myregistry/webapp:v1 --replicas=4

Perintah ini membuat Deployment bernama webapp dengan 4 replika Pod menjalankan image versi v1.

Langkah 2: Memantau Status Deployment

kubectl rollout status deployment/webapp

Perintah ini akan menampilkan progres deployment secara real-time hingga seluruh Pod siap.

Langkah 3: Melakukan Update Image

Untuk memicu rolling update, Anda cukup mengganti image container:

kubectl set image deployment/webapp webapp=myregistry/webapp:v2

Kubernetes akan otomatis mendeteksi perubahan ini dan memulai proses rolling update sesuai strategi yang dikonfigurasi.

Alternatif lain, Anda bisa mengedit manifest langsung:

kubectl edit deployment/webapp

atau menerapkan file YAML yang sudah diperbarui:

kubectl apply -f webapp-deployment.yaml

Langkah 4: Memverifikasi Riwayat Rollout

kubectl rollout history deployment/webapp

Perintah ini menampilkan daftar revisi yang pernah dilakukan pada Deployment tersebut, lengkap dengan nomor revisinya.

Untuk melihat detail perubahan pada revisi tertentu:

kubectl rollout history deployment/webapp --revision=2

Langkah 5: Menjeda dan Melanjutkan Rollout

Jika Anda ingin melakukan beberapa perubahan sekaligus tanpa memicu rolling update di setiap perubahan, gunakan:

kubectl rollout pause deployment/webapp
# lakukan beberapa perubahan konfigurasi
kubectl rollout resume deployment/webapp

Fitur ini sangat berguna saat Anda ingin mengubah beberapa environment variable atau resource limit sekaligus sebelum benar-benar memicu update.

Apa Itu Rollback di Kubernetes?

Rollback adalah proses mengembalikan Deployment ke revisi sebelumnya yang diketahui stabil, ketika versi baru yang di-deploy ternyata bermasalah—baik karena bug, crash loop, kesalahan konfigurasi, maupun performa yang menurun drastis.

Kubernetes secara otomatis menyimpan riwayat revisi Deployment (dikendalikan oleh field revisionHistoryLimit), sehingga Anda bisa kembali ke versi mana pun yang masih tersimpan dalam riwayat tersebut.

Melakukan Rollback ke Revisi Sebelumnya

kubectl rollout undo deployment/webapp

Perintah ini akan mengembalikan Deployment ke revisi tepat sebelum revisi saat ini.

Rollback ke Revisi Spesifik

Jika Anda ingin kembali ke revisi tertentu, bukan hanya revisi sebelumnya:

kubectl rollout undo deployment/webapp --to-revision=2

Ini sangat berguna ketika masalah baru terdeteksi beberapa revisi setelah versi bermasalah pertama kali dirilis, dan Anda perlu kembali jauh ke belakang.

Memantau Proses Rollback

Sama seperti rolling update, proses rollback juga bisa dipantau:

kubectl rollout status deployment/webapp

Rollback pada dasarnya menggunakan mekanisme yang sama persis dengan rolling update, hanya arahnya berbalik—Kubernetes menaikkan kembali Pod dengan image versi lama dan menurunkan Pod versi baru secara bertahap, sehingga rollback pun tetap berlangsung tanpa downtime.

Studi Kasus Sederhana

Misalkan tim Anda mengelola aplikasi webapp dengan 6 replika di production. Tim developer merilis versi v3 yang ternyata memiliki bug pada modul pembayaran—transaksi gagal diproses untuk sekitar 15% pengguna.

Berikut alur penanganannya:

Tim monitoring mendeteksi lonjakan error rate melalui dashboard (misalnya Prometheus + Grafana).
Sysadmin memeriksa riwayat revisi: kubectl rollout history deployment/webapp.
Diketahui revisi sebelumnya (v2) masih stabil, sehingga dilakukan rollback: kubectl rollout undo deployment/webapp.
Dalam hitungan detik hingga menit (tergantung jumlah replika dan readiness probe), traffic kembali dilayani oleh Pod versi v2 sepenuhnya.
Tim developer memperbaiki bug pada v3, menguji ulang di staging, lalu merilis v4 yang sudah diperbaiki melalui rolling update seperti biasa.

Dengan mekanisme ini, dampak bug pada pengguna bisa ditekan seminimal mungkin, tanpa perlu proses manual yang rumit atau downtime berkepanjangan.

Best Practice Rolling Update dan Rollback

Agar proses rolling update dan rollback berjalan aman dan minim risiko, terapkan praktik berikut:

Selalu konfigurasikan readiness probe dan liveness probe. Tanpa readiness probe yang tepat, Kubernetes bisa saja menganggap Pod baru “siap” padahal aplikasi di dalamnya belum benar-benar bisa melayani traffic.
Gunakan image tag yang spesifik, hindari tag latest. Tag latest membuat riwayat rollout sulit dilacak dan rollback bisa tidak berjalan sebagaimana mestinya.
Atur revisionHistoryLimit sesuai kebutuhan. Nilai default menyimpan cukup banyak riwayat, namun pada environment dengan frekuensi deploy tinggi, pertimbangkan untuk menyesuaikannya agar tidak membebani etcd secara berlebihan.
Uji strategi maxSurge dan maxUnavailable sesuai karakteristik aplikasi. Aplikasi stateless dengan traffic tinggi umumnya lebih aman dengan maxUnavailable: 0.
Terapkan monitoring dan alerting sebelum melakukan deployment besar. Rollback hanya efektif jika masalah terdeteksi secepat mungkin.
Gunakan strategi progressive delivery untuk aplikasi kritikal, seperti canary deployment atau blue-green deployment, sebagai lapisan tambahan di atas rolling update standar, terutama untuk sistem dengan risiko tinggi.
Selalu uji rollback di lingkungan staging, jangan hanya mengandalkan asumsi bahwa rollback pasti berjalan mulus di production.

Kesalahan yang Sering Terjadi

1. Tidak Mengatur Readiness Probe

Penyebab: Developer menganggap Pod otomatis “siap” begitu container berhasil start. Dampak: Traffic dialihkan ke Pod yang sebenarnya belum siap menerima request, menyebabkan error 502/503 pada pengguna selama proses update. Solusi: Definisikan readiness probe yang benar-benar merepresentasikan kesiapan aplikasi, misalnya endpoint /healthz yang memeriksa koneksi database sebelum mengembalikan status sukses.

2. Menggunakan Tag Image yang Sama Berulang Kali

Penyebab: Deploy ulang menggunakan tag latest tanpa versi spesifik. Dampak: Kubernetes tidak mendeteksi perubahan pada spec Pod (karena nama image sama), sehingga rolling update tidak terpicu sama sekali meski image sebenarnya berbeda isinya. Solusi: Selalu gunakan tag versi unik, misalnya berbasis commit hash atau semantic versioning (v1.2.3).

3. Tidak Memantau Proses Rollout

Penyebab: Tim langsung menganggap deployment berhasil setelah menjalankan perintah update tanpa memeriksa status lebih lanjut. Dampak: Masalah seperti ImagePullBackOff atau CrashLoopBackOff baru diketahui setelah pengguna melapor, bukan dari sistem monitoring internal. Solusi: Selalu jalankan kubectl rollout status setelah update, dan integrasikan proses ini ke dalam pipeline CI/CD agar deployment otomatis gagal (fail) jika rollout tidak sukses dalam batas waktu tertentu.

4. Rollback Terlambat Dilakukan

Penyebab: Tim menunggu terlalu lama untuk memastikan apakah masalah benar-benar disebabkan oleh deployment baru. Dampak: Dampak bug ke pengguna semakin meluas, kerugian bisnis semakin besar. Solusi: Tetapkan SOP dan threshold jelas—misalnya jika error rate naik di atas ambang tertentu dalam 5 menit setelah deployment, rollback otomatis dilakukan tanpa perlu menunggu persetujuan manual berlapis.

5. Riwayat Revisi Sudah Terhapus

Penyebab: Nilai revisionHistoryLimit terlalu kecil, sehingga revisi lama yang dibutuhkan untuk rollback sudah tidak tersimpan lagi. Dampak: Perintah kubectl rollout undo --to-revision=N gagal karena revisi yang dimaksud sudah tidak ada dalam riwayat. Solusi: Sesuaikan revisionHistoryLimit dengan kebutuhan tim, dan pertimbangkan pula menyimpan manifest versi sebelumnya di sistem version control (seperti Git) sebagai cadangan di luar riwayat internal Kubernetes.

Tips Tambahan untuk Produksi

Kombinasikan rolling update dengan Horizontal Pod Autoscaler (HPA) agar kapasitas tetap mencukupi saat sebagian Pod sedang dalam proses transisi.
Gunakan PodDisruptionBudget (PDB) untuk memastikan jumlah minimum Pod yang tetap tersedia, terutama jika ada proses lain (seperti node maintenance) yang berjalan bersamaan dengan rolling update.
Integrasikan proses rollout ke dalam pipeline CI/CD (misalnya GitLab CI, GitHub Actions, atau Jenkins) sehingga proses update dan validasi berjalan konsisten setiap kali ada perubahan kode.
Simpan setiap manifest Deployment dalam Git sebagai bagian dari praktik GitOps, sehingga histori perubahan konfigurasi tetap terlacak di luar cluster itu sendiri.

Kesimpulan

Rolling Update dan Rollback adalah dua sisi mata uang yang sama dalam strategi deployment Kubernetes yang aman dan andal. Rolling Update memungkinkan pembaruan aplikasi berjalan mulus tanpa mengorbankan ketersediaan layanan, sementara Rollback menjadi jaring pengaman ketika sesuatu berjalan tidak sesuai rencana.

Poin-poin penting yang perlu diingat:

Rolling Update mengganti Pod secara bertahap, dikendalikan oleh maxSurge dan maxUnavailable.
Perintah kubectl set image atau kubectl apply memicu proses rolling update.
kubectl rollout status digunakan untuk memantau progres.
kubectl rollout undo digunakan untuk rollback ke revisi sebelumnya atau revisi tertentu.
Readiness probe yang tepat adalah kunci keberhasilan kedua proses ini.
Monitoring dan alerting yang baik mempercepat deteksi masalah sehingga rollback bisa dilakukan lebih cepat.

Dengan memahami dan menerapkan praktik-praktik di atas, tim infrastruktur dapat merilis aplikasi baru dengan percaya diri, tanpa terus-menerus khawatir akan downtime yang merugikan pengguna maupun bisnis.

Bagaimana pengalaman Anda menerapkan rolling update dan rollback di cluster Kubernetes Anda sendiri?

Apakah pernah mengalami insiden yang berhasil diselamatkan berkat rollback cepat? Bagikan pengalaman Anda di kolom komentar, dan jangan lupa membagikan artikel ini ke rekan tim DevOps Anda yang mungkin membutuhkannya. Jelajahi juga artikel terkait lainnya seputar Kubernetes, DevOps, dan infrastruktur cloud di website ini.

Frequently Asked Questions (FAQ)

Pertanyaan: Apa perbedaan Rolling Update dengan strategi Recreate di Kubernetes? Jawaban: Rolling Update mengganti Pod secara bertahap sehingga aplikasi tetap dapat diakses selama proses berlangsung, sedangkan strategi Recreate mematikan seluruh Pod lama terlebih dahulu sebelum membuat Pod baru, yang menyebabkan downtime singkat.

Pertanyaan: Apakah rollback di Kubernetes bisa dilakukan otomatis tanpa perintah manual? Jawaban: Secara bawaan Kubernetes tidak melakukan rollback otomatis, namun hal ini bisa diimplementasikan menggunakan tooling tambahan seperti Argo Rollouts atau Flagger yang mendukung analisis metrik dan rollback otomatis berbasis kondisi tertentu.

Pertanyaan: Berapa lama proses rolling update biasanya berlangsung? Jawaban: Durasi bervariasi tergantung jumlah replika, nilai maxSurge/maxUnavailable, waktu startup aplikasi, dan konfigurasi readiness probe—bisa dari beberapa detik hingga beberapa menit.

Pertanyaan: Apakah rollback selalu berhasil mengembalikan aplikasi ke kondisi normal? Jawaban: Tidak selalu. Jika masalah disebabkan oleh perubahan pada dependensi eksternal seperti skema database, rollback pada Deployment saja mungkin tidak cukup dan perlu penanganan tambahan pada komponen terkait.

Pertanyaan: Bagaimana cara mengetahui revisi mana yang menyebabkan masalah sebelum melakukan rollback? Jawaban: Gunakan kubectl rollout history deployment/<nama> untuk melihat daftar revisi, kemudian periksa log dan metrik pada rentang waktu deployment tersebut dilakukan untuk memastikan revisi yang tepat sebelum menjalankan rollback.

Sudah paham cara kerja Rolling Update dan Rollback di Kubernetes? Yuk, tuliskan pengalaman atau kendala yang pernah Anda hadapi di kolom komentar—

diskusi Anda bisa membantu sysadmin lain yang menghadapi masalah serupa! Jangan lupa bagikan artikel ini ke rekan kerja atau komunitas DevOps Anda, dan terus ikuti artikel-artikel terbaru seputar Kubernetes, Cloud Computing, dan Infrastruktur IT di website ini.

Terkait

You may have missed

Kontribusi & Donasi...