Helm ile sürüm yükseltme ve geri alma: kontrollü dağıtım rehberi

Helm'de release ve revizyon ne demek?

Bir chart'ı kümeye kurduğunuzda ortaya çıkan çalışan örneğe release denir. Aynı chart farklı adlarla birkaç kez kurulabilir ve her kurulum kendi release kaydını taşır. Release üzerinde yaptığınız her değişiklik, yani yükseltme veya geri alma, o kayıt için yeni bir revizyon numarası üretir. Bu geçmiş kümede, release'in bulunduğu ad alanında saklanır ve helm history komutuyla okunur.

Sürüm yönetimi bu yüzden şu sorulara cevap vermektir: bugün kümede hangi chart sürümü ve hangi değerler çalışıyor, ve bir şey ters giderse hangi önceki duruma güvenle dönebilirim? Kontrollü bir yükseltme ve gerektiğinde hızlı bir geri alma, bu soruların cevabını önceden hazırlamakla mümkün olur.

Yükseltme nasıl yapılır?

Mevcut bir release'i yeni chart sürümüne veya yeni değerlere taşımak için helm upgrade kullanılır:

helm upgrade web ./uygulamam -f uretim-degerleri.yaml

Release henüz yoksa aynı komut hata verir. Bunu önlemek için hem ilk kurulumu hem sonraki yükseltmeleri tek komutla yapan biçim yaygındır:

helm upgrade --install web ./uygulamam -f uretim-degerleri.yaml

Yükseltmeden önce şu kontrol listesini izleyin: • Hangi chart sürümünün ve hangi değerlerin çalıştığına bakın: helm list ve helm get values web. • Yeni değerleri render edip farkı gözle inceleyin: helm template web ./uygulamam -f uretim-degerleri.yaml. • Önce bir deneme ortamında aynı komutu çalıştırın. • Üretimde --wait bayrağını ekleyin. Helm kaynaklar hazır olana kadar bekler; hazır olmazsa komut hata ile döner ve siz durumu fark edersiniz. Bekleme süresini --timeout ile sınırlayın.

Bir noktaya özellikle dikkat edin: yeni kurulumda yalnızca değiştirdiğiniz değerleri verirseniz, daha önce komut satırından verilmiş değerler kaybolabilir. Değerleri her yükseltmede aynı dosyadan vermek, hangi ayarın çalıştığını izlenebilir tutar. --reuse-values bayrağı önceki değerleri korur ama chart'a eklenen yeni varsayılanları da gizleyebilir; bu yüzden dosya tabanlı yaklaşım daha öngörülebilirdir.

Atomik yükseltme ile başarısız dağıtımı otomatik geri almak

Üretimde elle müdahaleyi azaltmak için --atomic bayrağı kullanılır. Yükseltme belirlenen süre içinde başarılı olmazsa Helm release'i kendiliğinden bir önceki başarılı revizyona döndürür. Bayrak bekleme davranışını da içerdiği için ayrıca --wait vermeniz gerekmez.

helm upgrade --install web ./uygulamam -f uretim-degerleri.yaml --atomic --timeout <süre>

Bu yaklaşımın sınırı şudur: otomatik geri alma yalnızca Kubernetes düzeyinde hazır olmayan kaynakları fark eder. Uygulama ayağa kalkıp hazırlık denetimini geçiyor ama yanlış davranıyorsa Helm bunu bilemez. Bu nedenle hazırlık ve canlılık denetimlerinin chart içinde doğru tanımlanması, sürüm yönetiminin ön koşuludur.

Geri alma adım adım nasıl yapılır?

Önce geçmişi görün:

helm history web

Çıktıda her revizyonun numarası, durumu, chart sürümü ve açıklaması listelenir. Hangi revizyonun sağlıklı olduğunu bu tablodan belirlersiniz. Sonra geri alın:

helm rollback web <revizyon>

Resmî belgeye göre revizyon numarası isteğe bağlıdır; verilmezse ya da sıfır verilirse Helm bir önceki sürüme döner. Geri almanın davranışını belirleyen bayraklar şunlardır: • --wait: kaynakların hazır olmasını bekler, --timeout süresiyle sınırlıdır. • --cleanup-on-fail: geri alma başarısız olursa, işlem sırasında oluşturulmuş yeni kaynakları silmeye izin verir. • --no-hooks: geri alma sırasında hook'ları çalıştırmaz.

Geri alma sonrasında geçmişe bakın. Helm geri almayı da yeni bir revizyon olarak kaydeder; yani önceki durum eski numarasıyla geri gelmez, onun içeriğiyle yeni bir revizyon oluşur. Bu davranış denetim izi açısından faydalıdır ama revizyon numaralarını okurken şaşırtabilir.

Örnek olay: bozuk bir değer dağıtıldığında ne yapılır?

Örneğin bir ekip yeni görüntü etiketiyle yükseltme yapıyor ve podlar hazır olmadan hata döngüsüne giriyor. Sırayla ilerleyin: • helm status web ile release durumuna bakın, kubectl ile podların olaylarını okuyun. • Sorunun hızlı çözülemeyeceği anlaşılırsa helm history web ile son sağlıklı revizyonu bulun. • helm rollback web <revizyon> --wait ile geri dönün. • Geri dönüşün ardından nedenin ne olduğunu ayrı bir ortamda inceleyin; üretimi ayıklama alanı olarak kullanmayın. • Olayı kısaca kaydedin: hangi chart sürümü, hangi değer, hangi belirti.

Burada önemli olan, geri almanın veriyi geri getirmediğidir. Veritabanı şeması değişikliği ya da silinmiş kalıcı birimler Helm geri alımıyla düzelmez. Şema değişikliği içeren sürümlerde geri dönüş planı, uygulama ve veri tarafıyla birlikte önceden yazılmalıdır.

Geçmiş sınırı ve sürüm disiplini

Helm her revizyon için kayıt tutar ve bu kayıtlar zamanla birikir. --history-max bayrağı, release başına saklanacak revizyon sayısını sınırlar; resmî belgede varsayılan bir sınır bulunduğu ve sıfırın sınırsız anlamına geldiği belirtilir. Çok kısa tutarsanız geri dönmek istediğiniz sürüm silinmiş olabilir, çok uzun tutarsanız ad alanında kayıtlar şişer. Değeri ekibin geri alma ihtiyacına göre bilinçli seçin.

Sürüm yönetiminde kalıcı olan disiplinler şunlardır: • Chart sürümünü her şablon değişikliğinde artırmak. • Görüntü etiketini sabit ve izlenebilir tutmak; değişken bir etiket geri almayı anlamsız kılar. • Değer dosyalarını sürüm kontrolünde saklamak. • Yükseltme komutunu elle değil, bir CI veya GitOps akışı üzerinden çalıştırmak.

Mindset programında bu beceri nerede çalışılır?

Helm ve K8s Paket Yönetimi eğitimi, üretim ortamında uygulama sürümlerini yöneten DevOps ve platform ekipleri için uygundur. Sürüm Yönetimi ve Versiyonlama modülü bu sayfadaki yükseltme ve geri alma konusuyla örtüşür; Üretim Helm Yönetimi modülü bu kararların canlı ortamda nasıl alınacağını işler, GitOps ile Helm Entegrasyonu ise yükseltmeleri elle komut yerine kod deposundan yürütmek isteyen ekiplere yöneliktir.