Pengelolaan Release

Peningkatan, rollback, dan disiplin values dalam pengelolaan release Helm sehari-hari.

Daftar isi

Topik ini membahas pengelolaan release Helm sehari-hari, yaitu peningkatan keadaan melalui helm upgrade, pengembalian melalui rollback, dan disiplin values yang dijaga dalam git. Pembahasan dimulai dari mekanisme peningkatan beserta dua cara menyuntikkan values, dilanjutkan penjagaan konsistensi antara git dan kluster, kemudian mekanisme rollback pada riwayat revisi, dan ditutup simulasi riwayat revisi yang dapat dijalankan ulang.

Peningkatan release dengan helm upgrade#

Perintah helm upgrade mengirim versi baru dari chart dan values pada release yang telah ada. Helm merender ulang seluruh template dengan nilai yang baru, membandingkan hasilnya dengan manifest revisi sebelumnya, kemudian menerapkan bagian yang berubah saja. Setiap peningkatan menambah nomor revisi satu tingkat, sehingga keadaan sebelumnya tidak pernah hilang dari riwayat.

bash
# tidak-dijalankan
# meningkatkan release dengan mengubah satu nilai secara langsung
helm upgrade catatan ./catatan-api --set replicaCount=3
text Contoh keluaran
Release "catatan" has been upgraded. Happy Helming!
NAME: catatan
LAST DEPLOYED: Tue May 12 10:02:11 2026
NAMESPACE: default
STATUS: deployed
REVISION: 2

Argumen --set menyuntikkan satu nilai langsung pada baris perintah, sehingga praktis untuk percobaan cepat. Untuk perubahan yang terencana, berkas values lingkungan lebih tepat karena isinya tertulis dan dapat ditinjau sebelum dijalankan.

bash
# tidak-dijalankan
# meningkatkan release menggunakan berkas values lingkungan produksi
helm upgrade catatan ./catatan-api -f values-produksi.yaml

Pemanggilan kedua mencetak keluaran yang serupa, dengan nomor revisi yang naik. Apabila --set dan -f digunakan bersama pada satu perintah, nilai dari --set berlaku paling akhir, sehingga argumen tersebut menimpa seluruh berkas values yang disebutkan. Untuk memeriksa hasil sebelum benar-benar diterapkan, opsi –dry-run mencetak manifest hasil perenderan ke terminal tanpa mengirimnya ke kluster.

Disiplin values dalam git#

Berkas values lingkungan tersimpan dalam git bersama chart yang dituju, sehingga setiap perubahan keadaan kluster memiliki jejak commit, peninjauan, dan penulisnya. Alur kerja yang sehat menempatkan values-produksi.yaml sebagai satu-satunya sumber keadaan produksi, kemudian menjalankan helm upgrade dari commit yang telah disetujui. Dengan disiplin ini, pertanyaan mengapa kluster berada pada keadaan tertentu dijawab oleh riwayat git, bukan oleh ingatan operator.

Argumen --set berada di luar disiplin tersebut. Nilai yang disuntikkan melalui baris perintah tersimpan dalam revisi release di kluster, tetapi tidak pernah muncul di git, sehingga peningkatan berikutnya dari git akan menimpanya diam-diam. Selisih semacam ini sulit dideteksi saat insiden terjadi karena dua sumber kebenaran menunjukkan keadaan yang berbeda.

Mengembalikan keadaan dengan helm rollback#

Perintah helm rollback memulihkan release ke keadaan revisi tertentu. Mekanismenya bukan penghapusan revisi, melainkan pencatatan revisi baru yang isinya disalin dari revisi tujuan, sehingga riwayat tetap utuh dan penomoran terus naik. Riwayat dapat dilihat dengan helm history yang menampilkan status setiap revisi, termasuk revisi yang gagal.

bash
# tidak-dijalankan
# menampilkan riwayat revisi release catatan
helm history catatan
# mengembalikan release ke keadaan revisi 2
helm rollback catatan 2
text Contoh keluaran
REVISION  UPDATED                   STATUS    CHART              APP VERSION  DESCRIPTION
1         Tue May 12 09:14:03 2026  deployed  catatan-api-0.1.0  1.2.0        Install complete
2         Tue May 12 10:02:11 2026  deployed  catatan-api-0.1.0  1.2.0        Upgrade complete
3         Tue May 12 10:31:40 2026  failed    catatan-api-0.1.0  1.3.0        Upgrade "catatan" failed: timed out waiting for the condition
Rollback was a success! Happy Helming!

Pada keluaran di atas, revisi 3 gagal menunggu Pod siap, sehingga statusnya failed, dan rollback ke revisi 2 menghasilkan pesan keberhasilan. Nomor revisi setelah rollback menjadi 4, yang memuat salinan keadaan revisi 2, sedangkan revisi 3 tetap terbaca pada riwayat sebagai catatan kejadian. Rollback adalah langkah pemulihan yang cepat, tetapi akar masalah tetap harus diperbaiki pada chart atau values, kemudian diterapkan kembali melalui helm upgrade.

Rollback memulihkan manifest, tetapi bukan seluruh akibat dari versi yang pernah berjalan. Perubahan skema basis data yang sudah dijalankan oleh aplikasi versi baru tidak ikut dipulihkan, sehingga komponen yang menyentuh data perlu dinilai secara terpisah sebelum rollback dipilih. Pada komponen tanpa keadaan seperti API catatan, keadaan revisi yang disalin sudah cukup sebagai pemulihan yang utuh.

Simulasi riwayat revisi#

Riwayat revisi pada sandbox artikel ini disimulasikan dengan Python. Skrip mencatat tiga kejadian, yaitu peningkatan yang berhasil, peningkatan yang gagal, dan rollback ke revisi kedua, kemudian mencetak tabel riwayat dengan kolom yang meniru keluaran helm history.

python riwayat-release.py
# Simulasi riwayat revisi Helm: setiap upgrade mencatat revisi baru dan
# rollback ke revisi lama menghasilkan revisi baru berisi keadaan lama.
import copy

def catat(riwayat, chart, keadaan, status, keterangan):
    revisi = riwayat[-1]["revisi"] + 1
    riwayat.append({"revisi": revisi, "chart": chart,
                    "keadaan": copy.deepcopy(keadaan),
                    "status": status, "keterangan": keterangan})

def cetak(riwayat):
    print("revisi | chart | keadaan                 | status   | keterangan")
    for r in riwayat:
        keadaan = f"tag {r['keadaan']['tag']}, replika {r['keadaan']['replika']}"
        print(f"{r['revisi']:6} | {r['chart']} | {keadaan:23} | {r['status']:8} | {r['keterangan']}")

riwayat = [{"revisi": 1, "chart": "0.1.0",
            "keadaan": {"tag": "1.2.0", "replika": 1},
            "status": "deployed", "keterangan": "Install complete"}]
# revisi 2: peningkatan jumlah replika yang berhasil
catat(riwayat, "0.1.0", {"tag": "1.2.0", "replika": 3},
      "deployed", "Upgrade complete")
# revisi 3: peningkatan versi aplikasi yang gagal menunggu pod siap
catat(riwayat, "0.1.0", {"tag": "1.3.0", "replika": 3},
      "failed", 'Upgrade "catatan" failed')
# rollback ke revisi 2: keadaan revisi 2 disalin menjadi revisi 4
tujuan = riwayat[1]
catat(riwayat, tujuan["chart"], tujuan["keadaan"],
      "deployed", "Rollback to 2")
cetak(riwayat)
text Keluaran
revisi | chart | keadaan                 | status   | keterangan
     1 | 0.1.0 | tag 1.2.0, replika 1    | deployed | Install complete
     2 | 0.1.0 | tag 1.2.0, replika 3    | deployed | Upgrade complete
     3 | 0.1.0 | tag 1.3.0, replika 3    | failed   | Upgrade "catatan" failed
     4 | 0.1.0 | tag 1.2.0, replika 3    | deployed | Rollback to 2

Revisi 3 tetap tercantum dengan status failed walaupun keadaannya tidak berlaku, dan revisi 4 muncul sebagai salinan revisi 2, bukan sebagai penulisan ulang riwayat. Perilaku ini menegaskan bahwa riwayat Helm bersifat catatan lengkap yang hanya bertambah, bukan tumpukan yang disunting mundur. Karena keadaan disalin utuh, hasil rollback sama dengan keadaan revisi tujuan tanpa perlu menghitung ulang values.

Perbandingan upgrade dan rollback#

Kedua perintah sama-sama menambah revisi baru, tetapi keduanya melayani keputusan yang berbeda. Tabel berikut menegaskan perbedaannya.

Aspekhelm upgradehelm rollback
Masukanchart dan values yang barunomor revisi lama
Isi revisi barukeadaan baru hasil perenderansalinan keadaan revisi tujuan
Sumber keputusancommit pada gitkeputusan pemulihan saat insiden
Peranperubahan terencanajaring pengaman yang cepat

Keduanya saling melengkapi pada satu alur kerja yang sama. Peningkatan terencana dijalankan dari git, sedangkan rollback digunakan saat insiden untuk membeli waktu sebelum perbaikan ditulis. Setelah penyebab ditemukan dan diperbaiki, alur kembali ke helm upgrade, sehingga kluster dan git kembali menunjuk keadaan yang sama.

Ringkasan#

  • helm upgrade merender ulang chart dengan nilai baru, menerapkan hanya bagian yang berubah, dan mencatat revisi baru pada riwayat.
  • values lingkungan disimpan dalam git sebagai sumber kebenaran, sedangkan –set hanya untuk percobaan karena nilainya tidak tercatat di git.
  • helm rollback mencatat revisi baru berisi salinan keadaan revisi tujuan tanpa menghapus riwayat, termasuk revisi yang gagal.
  • Upgrade dan rollback melayani keputusan yang berbeda, yaitu perubahan terencana dari git dan pemulihan cepat saat insiden.

Referensi#