Belajar Helm Chart - Migrasi & Upgrade Chart

#Pendahuluan

Setelah di episode 26 sebelumnya kita membahas troubleshooting dan debugging — bagaimana membedah kegagalan instalasi, release yang stuck, hingga teknik advanced seperti inspeksi secret release — pada episode kali ini kita menghadapi jenis tantangan yang berbeda: bukan memulihkan yang rusak, melainkan melakukan perubahan besar secara terkendali. Migrasi platform, upgrade major version, dan menghadapi deprecation adalah momen paling berisiko dalam umur sebuah sistem, dan hampir selalu melibatkan Helm di dalamnya.

Kenapa topik ini penting? Perubahan besar punya karakteristik unik: ia menggabungkan risiko teknis (breaking changes), risiko operasional (downtime jika gagal), dan risiko proses (siapa yang bertanggung jawab kapan). Perusahaan yang sudah berjalan di produksi tidak bisa memilih untuk "tidak pernah migrasi" — Helm 2 mau tidak mau harus pensiun, chart major version mau tidak mau hadir, dan API Kubernetes yang deprecated mau tidak mau harus diganti. Yang bisa dipilih hanya satu: migrasi yang direncanakan dengan metode yang benar, atau migrasi darurat di tengah insiden.

Di episode ini kita akan membedah migrasi Helm 2 ke Helm 3 dengan plugin helm-2to3, strategi upgrade chart antar major version, strategi upgrade aplikasi (rolling update, blue-green, canary) dan bagaimana Helm berinteraksi dengannya, lalu menutup dengan cara menghadapi deprecation — baik API Kubernetes maupun Chart API v1 vs v2.

#Migrasi Helm 2 ke Helm 3

Jika kalian bergabung dengan tim yang sudah lama, ada kemungkinan masih ada jejak Helm 2 — atau bahkan release yang masih dikelola Helm 2. Helm 2 secara resmi sudah end-of-life (rilis terakhirnya November 2020), dan Tiller-nya menjadi risiko keamanan serius karena memiliki izin luas di cluster. Migrasi bukan pilihan.

#Mengapa Harus Migrasi

Helm 2 dan Helm 3 berbeda secara fundamental di tiga hal yang paling memengaruhi operasional:

1. Tiller dihapus — Helm 2 membutuhkan komponen server Tiller yang berjalan dengan izin cluster-wide; ini pelanggaran least-privilege yang terkenal. Helm 3 sepenuhnya client-only.
2. Penyimpanan release — dari ConfigMap (Helm 2) menjadi Secret (Helm 3), dan kunci kriptografinya berubah; otomatis semua state lama tidak terbaca.
3. API dan perilaku — apiVersion: v1 vs v2 di Chart.yaml, helm install --name dihapus (nama release jadi argumen posisi), dan mekanisme patch berubah ke three-way strategic merge.

Konsekuensinya: tidak ada upgrade in-place. Release Helm 2 tidak bisa "di-upgrade" menjadi Helm 3 — ia harus dimigrasi. Inilah pekerjaan plugin helm-2to3.

#Plugin helm-2to3

helm-2to3 adalah plugin resmi dari komunitas Helm yang mengotomatisasi migrasi release dan repositori. Instalasi:

helm plugin install https://github.com/helm/helm-2to3
 
# Verifikasi
helm plugin list
helm 2to3 help

Plugin ini memiliki tiga subperintah utama — convert, move, dan cleanup — dan kita akan menjalankannya dalam urutan yang benar.

#Langkah Migrasi

Langkah 1 — persiapan. Cadangkan seluruh state Helm 2. Cara paling mudah dan menyeluruh: snapshot configmaps release di namespace Tiller. Catat juga versi Helm 2 dan daftar release yang sedang berjalan dengan helm2 list.

Langkah 2 — migrasi release. Perintah convert membaca release dari ConfigMap dan menuliskannya ulang sebagai Secret versi Helm 3:

# Koneksikan ke cluster yang sama dengan Tiller
helm 2to3 convert --tiller-namespace kube-system
 
# Migrasi satu release tertentu ke namespace lain
helm 2to3 convert api --tiller-namespace kube-system --release-namespace api

Langkah 3 — migrasi repositori. Repositori Helm 2 disimpan sebagai ConfigMap bernama helm-repositories di namespace Tiller. Pindahkan ke konfigurasi Helm 3:

helm 2to3 move config --tiller-namespace kube-system
helm repo list

Langkah 4 — verifikasi. Sebelum membersihkan apa pun, uji dengan teliti. helm list --all-namespaces harus menampilkan semua release yang sama dengan helm2 list. Jalankan helm status <release> untuk beberapa release kritis, bandingkan helm get values dengan nilai yang dicatat sebelum migrasi, dan pastikan aplikasi tetap berjalan normal.

Langkah 5 — cleanup. Setelah semua release terverifikasi, barulah bersihkan jejak Helm 2:

# Hapus configmaps release lama (PENTING: cek `--dry-run` dulu)
helm 2to3 cleanup --tiller-namespace kube-system --dry-run
 
# Jika yakin, jalankan tanpa dry-run
helm 2to3 cleanup --tiller-namespace kube-system
 
# Terakhir, hapus Tiller deployment itu sendiri
kubectl -n kube-system delete deploy tiller-deploy
kubectl -n kube-system delete sa tiller

#Prosedur Cleanup yang Benar

Urutan cleanup tidak boleh terbalik: hapus state release setelah migrasi berhasil, jangan sebelum. Jika release dinyatakan "hilang" setelah convert, kalian masih bisa kembali ke ConfigMap Helm 2 selama belum dihapus. Cleanup Tiller paling akhir, karena itu satu-satunya komponen yang masih memungkinkan Helm 2 bekerja jika migrasi ternyata cacat. Dan catat: setelah Tiller dihapus, tidak ada jalan mundur — pastikan seluruh release sudah dalam kondisi deployed di Helm 3 sebelum mengeksekusi langkah ini.

#Upgrade Chart Version

Migrasi platform hanyalah satu jenis perubahan. Setiap hari, chart juga berganti versi — dan tidak semua kenaikan versi itu sama.

#Major Version dan Breaking Changes

Dengan semantic versioning (yang kita bahas di episode 16), kenaikan major (2.x → 3.x) menandakan perubahan yang bisa merusak: struktur values yang berubah, nama resource yang berbeda, atau perilaku yang tidak kompatibel. Kenaikan minor dan patch diharapkan kompatibel — itulah kontrak yang membuat helm upgrade aman. Tapi "diharapkan" bukan "dijamin": chart komunitas sering melanggar semver dengan membawa perubahan besar di versi minor. Karena itu, uji selalu, apa pun jenis kenaikan versinya.

#Membaca Migration Guides

Hampir semua chart besar menerbitkan upgrade notes — file UPGRADING.md atau halaman di repo — yang merinci perbedaan antar versi mayor, khususnya perubahan values dan resource yang perlu penanganan manual (misalnya nilai yang harus dipindah dari satu key ke key lain, atau secret yang perlu dibuat ulang). Contoh nyata: upgrade chart prometheus dari versi lama ke baru sering memindahkan konfigurasi dari server.* ke prometheus.*; melewatkan migration guide berarti me-render chart dengan semua nilai di tempat yang salah — dan aplikasi tetap "berhasil" ter-deploy dengan konfigurasi default yang salah.

#Planning Upgrade

Upgrade major version membutuhkan rencana yang eksplisit. Alur yang bisa dijadikan template:

1. Baca UPGRADING.md / migration notes chart
2. Bandingkan values lama vs schema/nilai baru
3. Render versi baru di lokal, diff dengan yang lama
4. Uji di staging dengan subset produksi
5. Jadwalkan jendela upgrade + rencana rollback
6. Monitor metrics & error setelah go-live

# Simpan manifest versi lama
helm get manifest api > /tmp/api-old.yaml
 
# Render versi baru dan diff
helm template api ./api-chart \
    -f values-prod.yaml > /tmp/api-new.yaml
diff /tmp/api-old.yaml /tmp/api-new.yaml

#Testing Upgrade

Jangan pernah meng-upgrade chart major version langsung di produksi tanpa mengujinya. Praktik minimum: (1) helm template dan diff di lokal; (2) instalasi bersih versi baru di environment dev/staging dengan values yang direplikasi dari produksi; (3) upgrade dari versi lama ke versi baru di staging — bukan hanya instalasi bersih, karena perbedaan keduanya nyata (upgrade menghadapi resource yang sudah ada); (4) hanya setelah ketiganya lolos, baru jadwalkan di produksi dengan rencana rollback yang sudah disiapkan.

#Upgrade Aplikasi

Upgrade chart sering menjadi kendaraan untuk meng-upgrade aplikasi — dan di situlah strategi deployment klasik bermain. Helm sendiri hanya menerapkan perubahan ke resource; strategi seperti rolling update, blue-green, dan canary adalah kebijakan bagaimana perubahan itu dirilis ke pengguna.

#Rolling Update

Strategi default Kubernetes dan Helm. Deployment diperbarui secara bertahap — maxUnavailable dan maxSurge mengontrol berapa Pod yang boleh down dan berapa yang boleh melebihi jumlah target. Interaksinya dengan Helm sederhana: satu helm upgrade memicu satu rolling update. helm status akan menunggu hingga semua Pod baru ready jika --wait digunakan. Ketika aplikasi butuh lebih banyak kontrol (misal memastikan semua Pod baru sehat sebelum traffic masuk), tambahkan readinessProbe dan minReadySeconds di Deployment.

#Blue-Green Deployment

Dua environment lengkap — biru (lama) dan hijau (baru) — dijalankan bersamaan, lalu Service dialihkan seluruhnya. Dalam praktik Helm, ini sering direpresentasikan sebagai dua release (misal api-blue dan api-green), atau satu release dengan values yang mengganti label selector. Keuntungan: rollback secepat mengganti traffic (zero-downtime), dan versi lama tetap hidup selama periode observasi. Kelemahan: resource ganda (biaya 2×), dan nilai label Service harus diubah — ini titik paling rawan salah karena selector Deployment tidak bisa diubah setelah dibuat.

#Canary Deployment

Versi baru menerima sebagian kecil traffic (misal 5%) dan dinaikkan bertahap jika metrik sehat. Strategi ini biasanya dikelola tool seperti Argo Rollouts atau Flagger — Helm sendiri tidak punya mekanisme canary bawaan. Di arsitektur GitOps, pola yang umum: release utama di-manage ArgoCD/Flux, dan canary-nya di-manage Flagger yang membuat Deployment/Service sementara lewat chart yang sama. Ketika canary lulus, rilis penuh dilakukan lewat commit Git.

#Interaksi Helm dengan Strategi Ini

Hal penting yang sering terlewat: Helm tidak memahami strategi deployment — ia hanya tahu resource. Menggunakan strategi apa pun di atas berarti kalian tetap mengelola Deployment/Service lewat chart, sementara strategi rilisnya dijalankan oleh layer lain (Kubernetes controller, Argo Rollouts, Flagger). Rancang chart kalian agar label dan selector cukup fleksibel untuk mendukung strategi ini — misalnya dengan parameter selector.matchLabels.version — sebelum berinvestasi pada strategi mahal seperti blue-green.

#Handling Deprecation

Bagian terakhir dari episode ini: bertahan hidup di tengah perubahan ekosistem yang terus bergerak.

#Kubernetes API Deprecations

Kubernetes secara berkala menghapus API lama. Contoh paling terkenal baru-baru ini: extensions/v1beta1 untuk Ingress, Deployment, dan DaemonSet (dihapus di Kubernetes 1.16+), serta autoscaling/v2beta2 yang disederhanakan menjadi v2. Jika chart kalian masih menulis apiVersion: extensions/v1beta1, ia akan gagal di cluster baru dengan error yang jelas. Cara menangkalnya: (1) pantau pengumuman deprecation di release notes Kubernetes (masa hidup API biasanya 3 rilis); (2) jalankan audit berkala dengan tool seperti kubeconform atau kubectl convert; (3) baca Capabilities.KubeVersion di template untuk logika kondisional jika perlu.

#Chart API v1 vs v2

Chart dengan apiVersion: v1 (format Helm 2) masih bisa dipakai Helm 3, tapi tidak mendapat fitur seperti dependency declaration di Chart.yaml dan values.schema.json. Migrasi ke v2 biasanya sederhana:

# Sebelum (v1)
apiVersion: v1
name: myapp
version: 1.0.0
 
# Sesudah (v2)
apiVersion: v2
name: myapp
version: 2.0.0
dependencies:
  - name: postgresql
    version: "15.x"
    repository: https://charts.bitnami.com/bitnami

Setelah mengubah apiVersion, pindahkan dependencies dari requirements.yaml (jika ada) ke field dependencies, lalu jalankan helm dependency update untuk menghasilkan Chart.lock. Rendering dan instalasi harus tetap berhasil — ini tes paling cepat.

#Resource Migration

Ketika API dihapus, resource harus dimigrasikan. Contoh nyata: migrasi Deployment dari extensions/v1beta1 ke apps/v1. Karena apps/v1 sudah lama menjadi API stabil, migrasinya sering hanya mengubah apiVersion dan menambahkan field selector yang kini wajib. Jangan lakukan ini manual untuk ratusan resource — gunakan kubectl convert (plugin kubectl-convert), lalu verifikasi dengan render dan install di cluster staging.

#Testing dengan API Baru

Setiap migrasi API harus diuji di cluster yang sudah tidak lagi memiliki API lama (atau setidaknya memakai API baru). Praktik terbaik: pertahankan satu environment "cutting-edge" yang selalu memakai versi Kubernetes terbaru, dan jalankan chart suite kalian di sana secara berkala. Dengan begitu, masalah deprecation terdeteksi berbulan-bulan sebelum masa tenggang berakhir — bukan di tengah insiden upgrade cluster produksi.

#Penutup

Pada episode 27 ini kita telah memahami bahwa migrasi dan upgrade adalah disiplin perubahan terkendali: migrasi Helm 2 ke Helm 3 lewat plugin helm-2to3 dengan urutan convert → move → verify → cleanup yang ketat; upgrade chart antar major version yang menuntut membaca migration guides, membandingkan values, dan pengujian berlapis di staging; strategi upgrade aplikasi — rolling, blue-green, canary — serta posisi Helm sebagai penerap resource, bukan pengatur strategi rilis; dan cara menghadapi deprecation baik API Kubernetes maupun Chart API v1 ke v2.

Inti yang harus kalian bawa:

• Migrasi Helm 2 → 3 adalah konversi, bukan upgrade in-place — dan cleanup dilakukan paling akhir setelah verifikasi penuh.
• Major version = potensi breaking changes; selalu baca migration notes dan uji upgrade (bukan hanya instal bersih) di staging.
• Helm menerapkan resource; strategi rilis (rolling/blue-green/canary) dijalankan layer lain — desain chart agar mendukungnya.
• Pantau deprecation API secara proaktif dengan environment "cutting-edge" agar tidak kejutan di tengah upgrade cluster.
• Setiap perubahan besar punya harga: rencanakan, uji, jadwalkan, dan siapkan rollback.

Semakin besar skala sistem, semakin besar pula tuntutan pada efisiensi — chart yang lambat dirender, upgrade yang menunggu lama, dan ratusan release yang membanjiri cluster bukan lagi hal sepele. Di episode 28 selanjutnya kita akan membahas optimasi performa dan skala besar: menyusun template yang efisien, mengecilkan ukuran chart dengan .helmignore, tuning instalasi massal, mengelola ratusan release, hingga memonitor kesehatan Helm dengan helm-exporter dan Prometheus. Sampai jumpa di episode 28!