Helm ile Kustomize Arasındaki Fark: Şablon mu, Katmanlı Yama mı?

Aynı sorun, iki farklı çözüm

Kubernetes'e bir uygulama kurmak için Deployment, Service, ConfigMap, Ingress gibi birçok YAML manifesti gerekir. Aynı uygulama geliştirme, test ve üretim ortamlarında küçük farklarla (kopya sayısı, kaynak limiti, alan adı, imaj etiketi) çalıştığında, bu manifestleri kopyalayıp elle düzenlemek hızla yönetilemez hale gelir. Helm ve Kustomize bu sorunu çözmek için kullanılan en bilinen iki araçtır.

Helm bir paket yöneticisidir. Uygulamanın manifestleri, Go şablon diliyle yazılmış şablonlar ve varsayılan değerlerin tutulduğu values dosyasıyla birlikte chart adı verilen bir pakete dönüştürülür. Kurulum sırasında değerler şablonlara işlenir ve ortaya çıkan manifestler kümeye uygulanır. Kümeye kurulan her chart örneği bir release olarak izlenir.

Kustomize ise şablon kullanmaz. Düz ve geçerli YAML manifestlerinden oluşan bir base hazırlanır; her ortam için bir overlay, bu base'i kustomization.yaml dosyasında tanımlanan yamalar ve dönüştürücülerle değiştirir. Kustomize desteği kubectl'e de eklenmiştir; kubectl apply -k komutuyla ayrı bir araç kurmadan kullanılabilir.

Ölçüt ölçüt farklar

• Ölçüt: Yaklaşım. Helm: şablon ve parametre; manifestlerde değişecek yerler önceden değişken olarak işaretlenir. / Kustomize: yama ve birleştirme; manifestler olduğu gibi kalır, farklar üzerine yazılır.
• Ölçüt: Okunabilirlik. Helm: şablonlar koşul, döngü ve yardımcı fonksiyonlarla zenginleştikçe okumak zorlaşır; çıktıyı görmek için şablonun işlenmesi gerekir. / Kustomize: base ve yamalar düz YAML olduğu için okunur, ama çok katmanlı overlay'lerde son hali kafada birleştirmek zorlaşabilir.
• Ölçüt: Paketleme ve dağıtım. Helm: chart'lar sürümlenir, paketlenir ve repository üzerinden paylaşılır; üçüncü taraf yazılımlar (veritabanı, izleme, ingress denetleyicisi) genellikle Helm chart'ı olarak dağıtılır. / Kustomize: paket kavramı yoktur; base başka bir depodan ya da klasörden referansla alınır.
• Ölçüt: Kurulum durumu takibi. Helm: her kurulum, yükseltme ve geri alma release'in sürüm numarasını artırır; helm history ile geçmiş görülür, helm rollback ile önceki sürüme dönülür. / Kustomize: kümede durum tutmaz; geçmiş ve geri alma Git ya da kullanılan dağıtım aracı üzerinden yönetilir.
• Ölçüt: Yapılandırma girdisi. Helm: values dosyaları ve --set parametreleri; birden fazla values dosyası verilirse en sağdaki önceliklidir. / Kustomize: patches, images, replicas, namePrefix gibi alanlar ve ConfigMap ile Secret üreten generator'lar.
• Ölçüt: Yaşam döngüsü kancaları. Helm: kurulum öncesi ve sonrası çalışacak işler için hook'lar sunar. / Kustomize: böyle bir mekanizma yoktur; sıralı işler başka araçla çözülür.
• Ölçüt: Öğrenme eğrisi. Helm: Go şablon sözdizimi ve chart yapısı öğrenilmelidir. / Kustomize: Kubernetes YAML bilen biri için başlangıcı daha kolaydır.

Aynı ihtiyacın iki uygulaması

Örneğin bir ekip, sipariş servisini test ve üretim ortamlarına kuruyor. Üretimde kopya sayısı daha yüksek, kaynak limitleri daha geniş ve imaj etiketi onaylanmış sürüm.

Helm ile ekip bir chart hazırlar. Deployment şablonunda kopya sayısı, imaj etiketi ve kaynak limitleri değişken olarak tanımlanır, varsayılanlar values.yaml dosyasındadır. Her ortam için ayrı bir values dosyası tutulur ve kurulum şöyle yapılır:

helm upgrade --install siparis ./siparis-chart -f values-prod.yaml

Kustomize ile ekip, test ve üretimde ortak olan manifestleri base klasörüne koyar. overlays/prod klasöründeki kustomization.yaml, base'i resources altında referans verir, replicas ve images alanlarıyla kopya sayısını ve imaj etiketini değiştirir, kaynak limitleri için küçük bir yama dosyası ekler. Uygulama şöyle yapılır:

kubectl apply -k overlays/prod

Helm örneğinde farklar şablona açılmış değişkenlerle sınırlıdır; şablonda öngörülmemiş bir alanı değiştirmek için chart'ı düzenlemek gerekir. Kustomize örneğinde ise herhangi bir alan yamayla değiştirilebilir, ama değişikliğin hangi manifeste uygulandığını takip etmek ekibin klasör disiplinine bağlıdır.

Hangi durumda hangisi?

Helm'in öne çıktığı durumlar: • Uygulama birçok ekip, müşteri ya da kurum tarafından farklı ayarlarla kurulacak; paket olarak dağıtılması gerekiyor. • Üçüncü taraf bir yazılım kuruluyor ve üreticisi resmî Helm chart'ı yayınlıyor. • Kurulum, yükseltme ve geri alma geçmişinin kümede release olarak tutulması isteniyor. • Kurulum öncesi veritabanı geçişi gibi sıralı işler hook'larla yönetilmek isteniyor.

Kustomize'ın öne çıktığı durumlar: • Uygulama şirketin kendi uygulaması; dışarıya dağıtılmayacak, yalnız ortamlar arası farklar yönetilecek. • Ekip şablon mantığı yerine düz YAML üzerinde çalışmayı ve inceleme sırasında son hali kolay görmeyi tercih ediyor. • Hazır bir manifest setinde, şablona açılmamış alanlar değiştirilmek isteniyor. • Ek bir araç kurmadan kubectl ile çalışmak isteniyor.

Kısa bir ölçüt: Başkalarına dağıtılacak bir paket üretiyorsanız Helm, kendi uygulamanızın ortam farklarını yönetiyorsanız Kustomize genellikle daha sade sonuç verir.

Birlikte kullanım ve GitOps

İki araç birbirini dışlamaz. Yaygın bir kalıp, üçüncü taraf yazılımı Helm chart'ından üretip kuruma özgü son düzeltmeleri Kustomize yamasıyla eklemektir. Örneğin bir ingress denetleyicisinin chart'ı values ile ayarlanır, chart'ın sunmadığı bir etiket ya da ek alan Kustomize ile eklenir. Kustomize, kustomization.yaml içinde Helm chart'larını işleyebilen bir alan da sunar; bunun etkinleştirilmesi araç ayarına bağlıdır.

GitOps araçları her ikisini de destekler. Argo CD bir uygulama tanımında Helm chart'ını ya da Kustomize klasörünü kaynak olarak alabilir; Flux'ta ise Kustomize ve Helm için ayrı denetleyiciler bulunur. GitOps ile çalışırken önemli bir fark ortaya çıkar: Helm'in kendi release geçmişi ile Git geçmişi iki ayrı gerçek kaynağına dönüşebilir. Bu nedenle GitOps kurgularında geri alma işlemi genellikle helm rollback yerine Git'teki değişikliğin geri alınmasıyla yapılır.

Sık yapılan hatalar

• Her alanı değişkene açan aşırı parametreli chart'lar yazmak: values dosyası manifestin kendisinden uzun hale gelir, chart'ın değeri kaybolur. Yalnız gerçekten ortamdan ortama değişen alanları parametreleyin.
• Kustomize'da derin overlay zincirleri kurmak: overlay'in overlay'i üzerine kurulan yapılarda bir değerin nereden geldiğini bulmak zorlaşır. kubectl kustomize ile çıktıyı inceleme alışkanlığı edinin.
• Helm çıktısını hiç görmeden kurmak: helm template ya da helm install --dry-run ile oluşacak manifestleri incelemek, şablon hatalarını kümeye ulaşmadan yakalar.
• Gizli bilgileri values dosyasına ya da Kustomize literal'ına düz metin yazıp Git'e koymak: şifreli gizli bilgi ya da harici bir gizli bilgi yöneticisi kullanılmalıdır.
• Aynı kaynağı iki araçla ayrı ayrı yönetmek: Helm ile kurulmuş bir kaynağı sonra kubectl apply -k ile değiştirmek, bir sonraki helm upgrade'de değişikliğin ezilmesine yol açar.

Mindset programlarında Helm ve Kustomize

Helm ve K8s Paket Yönetimi eğitimi chart geliştirme temellerinden ileri düzey şablon tekniklerine, sürüm yönetimi, Helm repository ve GitOps ile Helm entegrasyonuna uzanır. Uygulamalarını birden çok ekibe ya da müşteriye paket olarak dağıtan platform ve DevOps ekipleri için doğrudan karşılık bulur.

Kustomize ile Kubernetes Manifest Yönetimi eğitimi ise base yapısı, overlay ve patch stratejileri ile pipeline entegrasyonuna odaklanan daha kısa ve odaklı bir programdır. Kendi uygulamalarının ortam farklarını düz YAML üzerinden yönetmek isteyen geliştirme ve operasyon ekiplerine uygundur.