Ringkasan Utama
Helm 4, dirilis pada November 2025, adalah versi mayor Helm pertama sejak 2019. Secara default ia memakai server-side apply Kubernetes untuk instalasi baru, menjadikan post-renderer sebagai plugin, menambah runtime plugin WebAssembly opsional, dan mewajibkan registry login hanya dengan domain. Sebagian besar chart Helm 3 tetap berjalan, jadi migrasi terutama soal flag CLI dan perilaku apply.
Helm 3 hadir pada 2019 dan lalu sangat stabil selama enam tahun — cukup lama sampai banyak tim berhenti menganggap binary Helm sebagai sesuatu yang bisa berubah di bawah mereka. Era itu sudah berakhir. Pada Rabu, 12 November 2025, saat presentasi Helm 4 di KubeCon plus CloudNativeCon Amerika Utara, para maintainer merilis Helm v4.0.0, dan pengumuman resminya terbit di blog Helm lima hari kemudian.
Saya menjalankan Helm di beberapa cluster, jadi saya membaca release notes-nya seperti membaca kenaikan versi mayor database: anggap ada sesuatu yang saya andalkan sudah bergeser. Kabar baiknya, chart tetap kompatibel ke belakang, jadi template Anda tetap bekerja. Perubahan yang benar-benar terasa ada di flag CLI, strategi apply, serta cara plugin dan post-renderer dirangkai. Panduan ini membahas apa yang berubah dan langkah persis yang saya ikuti untuk migrasi.
Rilis mayor Helm pertama dalam enam tahun
Helm berusia sepuluh tahun pada Oktober 2025, dan Helm 4 adalah tonggak yang datang bersama peringatan itu. Karena ini versi mayor penuh, para maintainer bebas membuat perubahan yang tidak kompatibel ke belakang — release notes menyatakan secara jelas bahwa Helm v4 mengubah flag dan output CLI serta Go SDK. Itulah model pikir yang perlu dipegang: chart aman, tooling tidak otomatis aman.
Upgrade ini juga berjalan dengan tenggat. Helm 3 hanya akan terus mendapat bug fix sampai rilis fitur terakhirnya pada 9 September 2026, dan security fix berakhir pada 10 Februari 2027 — diperpanjang dari tanggal November 2026 sebelumnya. Setelah itu, Helm 3 berhenti menerima pembaruan apa pun, termasuk pustaka klien Kubernetes dan patch keamanan. Ada jendela waktu nyata untuk merencanakan perpindahan alih-alih terburu-buru.
Apa yang benar-benar baru di Helm 4
Release notes mengelompokkan perubahan utama menjadi daftar singkat. Inilah fitur yang saya perhatikan sebagai operator, dikutip dari pengumuman resmi Helm 4:
- Sistem plugin yang dirancang ulang yang mendukung plugin berbasis WebAssembly berdampingan dengan plugin subprocess yang sudah ada.
- Post-renderer kini berupa plugin, bukan lagi executable bebas yang dilewatkan di command line.
- Server-side apply kini didukung, dan menjadi default untuk release yang baru diinstal.
- Pemantauan resource yang lebih baik, sehingga menunggu resource memakai kstatus alih-alih pengecekan kesiapan yang serampangan.
- Caching lokal berbasis konten, misalnya untuk chart, guna mempercepat operasi yang berulang.
- Logging melalui slog, sehingga logging SDK terintegrasi rapi dengan logger terstruktur modern.
- Build arsip chart yang reproducible dan idempoten, yang membuat proses packaging deterministik.
- API SDK yang diperbarui, termasuk dukungan untuk beberapa versi API chart dari satu codebase.
Perubahan besar yang perlu diperhatikan
Sebagian besar kesulitan migrasi terpusat pada beberapa detail CLI. Perintah registry login kini hanya menerima nama domain — tanpa skema dan tanpa path — agar login bisa dibatasi pada level berbeda dari sebuah registry di masa depan. Dua flag upgrade yang familiar diganti namanya: atomic menjadi rollback-on-failure, dan force menjadi force-replace. Nama lama masih bekerja di v4 tetapi mencetak peringatan deprecation, jadi skrip tetap jalan sambil Anda memperbaikinya. Dan karena post-renderer kini berupa plugin, Anda melewatkan nama plugin alih-alih path executable.
# registry login now takes the domain only (no scheme, no path) in Helm 4
helm registry login registry.example.com
# renamed upgrade flags (old names still work in v4 but print a deprecation warning)
helm upgrade myapp ./chart --rollback-on-failure # replaces --atomic
helm upgrade myapp ./chart --force-replace # replaces --force
# post-renderers are plugins now: pass a plugin name, not an executable path
helm template myapp ./chart --post-renderer my-postrendererAudit skrip CI Anda sebelum meng-upgrade binary Helm di pipeline. Registry login yang melewatkan URL lengkap beserta skema, atau post-renderer yang menunjuk ke path skrip shell, akan rusak di Helm 4 meskipun flag yang diganti namanya hanya memberi peringatan. Grep dulu otomasi Anda untuk registry login, --atomic, --force, dan --post-renderer.
Server-side apply: instalasi baru versus upgrade
Ini bagian yang halus. Helm 4 default ke server-side apply Kubernetes, tetapi hanya saat Anda menginstal release yang benar-benar baru. Saat Anda meng-upgrade atau melakukan rollback pada release yang sudah ada, Helm mempertahankan metode apply yang sudah dipakai release itu — artinya setiap release yang awalnya dibuat oleh Helm 3 tetap memakai client-side apply setelah Anda pindah ke Helm 4. Anda tidak diam-diam mengganti strategi apply pada beban kerja produksi hanya dengan meng-upgrade binary, dan itu disengaja.
Perilaku terbagi ini adalah fitur, bukan keanehan: ia memungkinkan Anda mengadopsi Helm 4 tanpa gejolak strategi apply pada release yang ada, lalu memilih memasukkan tiap release ke server-side apply sesuai jadwal Anda sendiri. Uji server-side apply pada release yang tidak kritis dulu — ia mengubah cara kepemilikan field dan konflik ditangani di API server.
Helm 3 versus Helm 4 sekilas
| Aspek | Helm 3 | Helm 4 |
|---|---|---|
| Strategi apply | Hanya client-side apply | Server-side apply default untuk instalasi baru |
| Sistem plugin | Hanya skrip subprocess | Dirancang ulang, menambah runtime WebAssembly opsional |
| Post-renderer | Path executable apa pun via flag | Harus berupa plugin bernama |
| Argumen registry login | URL lengkap diterima | Hanya nama domain |
| Flag upgrade | atomic dan force | rollback-on-failure dan force-replace |
| Logging SDK | Antarmuka logging khusus | slog pustaka standar |
Checklist migrasi saya
Saya memperlakukan upgrade mayor Helm seperti kenaikan dependency lainnya: ubah di tempat berisiko rendah, amati output-nya, lalu perluas. Inilah urutan yang saya ikuti.
# 1. Check what you are running today
helm version # client version
kubectl version # cluster version
# 2. Install Helm 4, then read your existing release history (unchanged from v3)
helm ls -A
# 3. New installs get server-side apply by default
helm install myapp ./chart
# 4. Existing Helm 3 releases keep client-side apply on the first v4 upgrade
helm upgrade myapp ./chart- Catat versi client dan cluster Anda saat ini, dan pastikan chart Anda masih ter-template dengan bersih di Helm 4 memakai helm template.
- Cari di CI dan skrip lokal Anda perintah helm registry login dengan URL, --atomic, --force, dan post-renderer executable, lalu perbaiki satu per satu.
- Ganti atomic menjadi rollback-on-failure dan force menjadi force-replace sekarang, meski flag lama masih memberi peringatan, agar Anda tidak mengejar peringatan nanti.
- Kemas ulang logika post-renderer apa pun sebagai plugin Helm dan rujuk dengan nama alih-alih path.
- Upgrade satu release yang tidak kritis dulu dan pastikan ia tetap client-side apply, lalu masukkan ke server-side apply secara sengaja sambil mengawasi konflik field.
- Baru setelah uji coba itu, luncurkan binary Helm 4 ke seluruh pipeline dan cluster lainnya.
Tidak ada yang dramatis di sini jika Anda melakukannya sebelum tenggat. Helm 4 menjaga chart Anda tetap bekerja, flag yang diganti namanya menurun dengan anggun lewat peringatan, dan pemisahan strategi apply melindungi release Anda yang ada dari perilaku mengejutkan. Risiko sebenarnya adalah menunda sampai dukungan keamanan Helm 3 berakhir pada Februari 2027 lalu menemukan perintah login yang rusak di pipeline yang Anda lupakan. Mulai dengan satu cluster kuartal ini.