Kendi Helm chart'ınızı yazmak: adım adım uygulama rehberi

Helm chart ile ne paketlenir?

Bir Helm chart, Kubernetes üzerinde bir uygulamayı kurmak için gereken tüm manifest şablonlarını, varsayılan ayarları ve meta bilgiyi tek bir dizinde toplayan pakettir. Düz YAML dosyalarıyla çalışırken her ortam için Deployment, Service ve ConfigMap dosyalarını kopyalayıp elle değiştirirsiniz. Chart'ta ise sabit kısım şablon olur, değişen kısım değer dosyasına çıkar; aynı paket geliştirme, test ve üretim ortamında farklı değerlerle kurulur.

Chart yazmak bu yüzden birbirini tamamlayan becerileri birlikte ister: Kubernetes kaynaklarını doğru tanımlamak ve bunların hangi parçasının dışarıdan ayarlanabilir olması gerektiğine karar vermek. İkincisi daha zordur. Her alanı değişkene çevirirseniz chart okunmaz hale gelir; hiçbirini çevirmezseniz paket tek bir ortama kilitlenir.

Chart iskeleti nasıl oluşturulur ve dizin neyi içerir?

En hızlı başlangıç helm create komutudur. Komut verdiğiniz adla bir dizin açar ve içine çalışan örnek bir chart yerleştirir:

helm create uygulamam

Oluşan yapının temel parçaları şunlardır: • Chart.yaml: chart'ın adı, sürümü ve açıklaması. • values.yaml: şablonların kullandığı varsayılan değerler. • templates/: Kubernetes manifest şablonları. Helm bu dizindeki dosyaları şablon motorundan geçirip sonucu Kubernetes'e gönderir. • charts/: chart'ın bağımlı olduğu alt chart'lar.

Üretilen örnek chart; deployment.yaml, service.yaml, yardımcı şablonları tutan _helpers.tpl ve kurulum sonrası notları gösteren NOTES.txt dosyalarını da getirir. İlk chart'ınızı yazarken bu dosyaları silip tek bir kaynakla sıfırdan başlamak, her satırın ne yaptığını anlamanın etkili bir yoludur.

Chart.yaml dosyasının asgari hali şöyledir:

apiVersion: v2 name: uygulamam description: Örnek web uygulaması version: 0.1.0 appVersion: stabil

version chart paketinin kendi sürümüdür; şablonları değiştirdiğinizde artırırsınız. appVersion ise paketlenen uygulamanın sürümünü anlatır ve ikisi birbirinden bağımsız ilerler. Bu ayrımı karıştırmak, sonradan sürüm yönetiminde en sık görülen karışıklıklardan biridir.

Şablon yazarken values ve yerleşik nesneler nasıl kullanılır?

Şablonlar Go şablon dili ile yazılır ve çift süslü parantez içindeki ifadeler render sırasında değere dönüşür. Şu nesne gruplarını bilmek yeterli bir başlangıç sağlar: • .Values: values.yaml dosyasından ve kurulum sırasında verilen değerlerden gelir. • .Release: kurulumun adı ve ad alanı gibi bilgiler. Örneğin .Release.Name her kurulumda farklıdır. • .Chart: Chart.yaml içindeki alanlar.

Küçük bir Deployment şablonu şöyle görünür:

apiVersion: apps/v1 kind: Deployment metadata: name: {{ .Release.Name }}-web spec: replicas: {{ .Values.replicaCount }} selector: matchLabels: app: {{ .Release.Name }}-web template: metadata: labels: app: {{ .Release.Name }}-web spec: containers: - name: web image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"

Bu şablonun beslendiği values.yaml dosyası da aynı yapıyı izler:

replicaCount: 1 image: repository: nginx tag: stabil

Kaynak adlarına .Release.Name eklemek önemlidir. Aynı chart'ı aynı ad alanında ikinci kez kurduğunuzda adlar çakışmaz. Release adı uzunluk sınırına sahip olduğu için çok uzun adlar vermemek de gerekir.

Koşul, döngü ve yardımcı şablonlarla tekrar nasıl azaltılır?

Chart büyüdükçe aynı etiket bloğunu her dosyada yazmak sürdürülemez hale gelir. İlk çözüm _helpers.tpl içinde adlandırılmış şablonlar tanımlamak ve bunları include ile çağırmaktır. Etiketler, seçiciler ve kaynak adları için tek bir yardımcı tanımlarsanız adlandırma kuralını bir yerden değiştirirsiniz.

İkinci araç koşullardır. Ingress gibi her ortamda gerekmeyen kaynaklar if bloğuna alınır ve values.yaml içindeki bir anahtarla açılıp kapatılır. Üçüncü araç range döngüsüdür; ortam değişkenleri gibi liste halinde gelen girdileri tek bir şablon satırıyla üretmenizi sağlar.

Burada şu alışkanlıklar işinizi kolaylaştırır: • Değerleri iç içe geçmiş ama makul derinlikte tutun. Çok derin bir values yapısı kullanıcıyı hata yapmaya iter. • Gerekli bir değer boş bırakılırsa chart'ın anlaşılır bir hata vermesini isteyin. Helm'in required işlevi bu iş için vardır ve eksik bir görüntü adını kurulumdan önce yakalar.

Boşluk yönetimi de sık takılınan noktadır. YAML girintiye duyarlı olduğundan, şablon ifadesinin başına ve sonuna eklenen tire işaretleri gereksiz boş satırları temizler; nindent ile birleştirilmiş blok içerikler girintiyi otomatik ayarlar.

Chart'ı kuruluma göndermeden nasıl test edilir?

Chart yazarken en kritik alışkanlık, kümeye dokunmadan render sonucunu görmektir. Sırasıyla şu kontrolleri yapın: • helm lint uygulamam: şablon sözdizimi ve Chart.yaml hatalarını yakalar. • helm template uygulamam: şablonları yerelde işleyip üretilen YAML'ı yazdırır; hangi değerin nereye girdiğini gözle görürsünüz. • helm install --debug --dry-run deneme ./uygulamam: kurulum akışını simüle eder ve render edilmiş manifestleri döndürür. Resmî belge, başarılı bir dry-run'ın Kubernetes'in manifestleri kabul edeceğini kesinleştirmediğini hatırlatır; gerçek kümede ayrıca doğrulama gerekir. • helm get manifest deneme: gerçek bir kurulumdan sonra kümeye giden YAML'ı gösterir.

Değer dosyalarını ortama göre ayırmak da test mantığının parçasıdır. Üretim değerlerini ayrı bir dosyada tutup helm template uygulamam -f uretim-degerleri.yaml ile render ederseniz, geliştirme ortamında çalışan ama üretimde kırılan koşulları erken görürsünüz.

Chart yazarken sık yapılan hatalar nelerdir?

• Her şeyi değişkene çevirmek. Kullanıcının hiç dokunmayacağı alanları values.yaml'a taşımak dosyayı şişirir ve belgelendirmeyi zorlaştırır.
• Sabit görüntü etiketi yerine yalnızca en son etiketi kullanmak. Hangi sürümün çalıştığı izlenemez olur ve geri alma anlamını kaybeder.
• Chart sürümünü değiştirmeden şablonu güncellemek. Depoya yayımladığınız paketler birbirinden ayırt edilemez hale gelir.
• Sır değerlerini values.yaml içine yazmak. Parola ve anahtarlar chart'a gömülmez; kümedeki bir Secret'a referans verilir ya da dış bir sır yönetim aracından çekilir.
• Kaynak adlarını sabit yazmak. Aynı ad alanında ikinci kurulum çakışır.
• Test etmeden paketlemek. helm lint ve helm template adımlarını yayın öncesi otomatik kontrole bağlamak bu hataları yayından önce görünür kılar.

Bir chart'ın kalitesi, başka bir ekip üyesinin yalnızca values.yaml dosyasını okuyup uygulamayı doğru kurabilmesiyle ölçülür. Değer adlarını açık seçin ve her önemli değerin yanına kısa bir yorum satırı koyun.

Başlangıçtan ileri düzeye hangi sırayla ilerlenir?

İlk aşamada helm create ile gelen örnek chart'ı kurup silmeyi, ardından değerleri değiştirerek davranışın nasıl değiştiğini izlemeyi öğrenin. İkinci aşamada kendi uygulamanız için sıfırdan tek Deployment ve Service yazın. Üçüncü aşamada yardımcı şablonlar, koşullar ve döngülerle tekrarı azaltın.

İleri düzeyde bağımlı chart'lar (veritabanı gibi alt bileşenler), kurulum öncesi ve sonrası çalışan hook'lar, değer şeması doğrulaması ve chart testleri devreye girer. Bunun ardından chart'ı bir depoya yayımlamak ve sürüm yükseltme ile geri alma akışını yönetmek gelir.

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

Helm ve K8s Paket Yönetimi eğitimi, Kubernetes üzerinde uygulama dağıtımını elle yazılmış manifestlerden paketlenmiş ve tekrar kullanılabilir chart'lara taşımak isteyen DevOps ve platform mühendisleri için kurgulanmıştır. Müfredatta Chart Geliştirme Temelleri ve İleri Düzey Şablon Teknikleri modülleri doğrudan bu sayfadaki konuyu işler; Helm Temel Kavramı ve Mimarisi modülü ise chart ile sürüm kavramlarının temelini kurar.

Bir ekip ortak bir dağıtım standardı oluşturmak istiyorsa, aynı eğitim sayfasındaki GitOps ile Helm entegrasyonu ve üretim yönetimi modülleri chart'ların ekip genelinde nasıl kullanılacağını da kapsar.