Feynman Metodu ile Kubernetes: Kubernetes’in Akıllı Paket Yöneticisi -> Helm

Selamlarrr!!! Kubernetes serimizin bir önceki yazısında, cluster içindeki görünmez ağ duvarlarını, “Default Deny” tuzaklarını ve daha nicesini Network Policies başlığı altında işlemiştik.

Helm Mimarisi

Kubernetes cluster’ı üzerinde tek bir mikroservisi bile ayağa kaldırmak istediğimizde iş sadece kodları konteynır haline getirmekle bitmiyor. O servisin stabil çalışabilmesi için bir Deployment, önünde bir Service, konfigürasyon verileri için ConfigMap veya Secret yazmamız, üstüne bir de ağ güvenliği için NetworkPolicy tanımlamamız gerekiyor. Tek bir servis için bile arka arkaya 5-6 farklı YAML dosyasıyla uğraşmak zorunda kalıyoruz. Peki, şirkette bu mikroservislerden 50 tane varsa? Ve bu 50 servisi hem development, hem staging, hem de production ortamlarına (farklı pod sayıları ve farklı şifrelerle) ayrı ayrı kurmanız gerekiyorsa? Binlerce satırlık statik YAML dosyası arasında kaybolmamamız için Linux dünyasındaki apt-get veya yum neyse, Kubernetes dünyasında da o imdada yetişen bir süper kahraman var: Helm!

Statik YAML’lardan Dinamik Şablonlara: Helm Mantığı

Kubernetes’in kendisi sadece statik kodlardan anlar. Canlı ortama kurarken 5 pod, test ortamına kurarken 1 pod ayağa kaldırmak istiyorsanız, Kubernetes size iki ayrı devasa dosya yazdırır. Helm ise bu işi bir şablon mimarisine oturtuyor. Biz koca koca YAML dosyalarını her ortam için ayrı ayrı yazmak yerine, parametreleri boş bırakılmış tek bir şablon klasörü (Templates) hazırlıyoruz. Bu şablonların içine gidecek olan pod sayılarını, imaj versiyonlarını veya port numaralarını ise tek bir merkezden, yani **values.yaml** dosyasından yönetiyoruz. Bir imaj güncellemesi geldiğinde onlarca dosyayı tek tek taramak yerine sadece values.yaml dosyasındaki ilgili satırı değiştirip helm upgrade komutunu koşmamız, tüm cluster'ın güncellenmesi için yeterli oluyor. Helm, client-side (istemci tabanlı) çalışan bir araçtır; şablonları yerelde birleştirip saf YAML haline getirir ve Kubernetes API'sine teslim eder.

Helm Chart

Terminalde helm create codepulse-chart komutunu verdiğimizde Helm bize standart bir klasör yapısı oluşturur. Kurumsal bir altyapıda bu yapının içindeki her dosyanın görevi son derece keskindir:

codepulse-chart/
├── Chart.yaml          # Paketin kimlik kartı ve versiyon hiyerarşisi
├── values.yaml         # Değişkenlerin yönetildiği ana direksiyon
├── charts/             # Bu chart'ın bağımlı olduğu alt paketler (Dependencies)
└── templates/          # Sihirli şablon mutfağı (Go Template Motoru)
    ├── deployment.yaml
    ├── service.yaml
    ├── _helpers.tpl    # Tekrar eden kod blokları için ortak kütüphane
    └── NOTES.txt       # Kurulum bittiğinde terminale basılacak rehber mesaj

1. Chart.yaml ve Versiyon Ayrımı

Bu dosya paketin meta verilerini tutar. İçerisinde karşımıza çıkan iki farklı versiyon tanımı yer alır:

• **version (Chart Version):** Tasarladığımız bu Helm paketinin (IKEA kutusunun) kendi versiyonudur. Şablon dosyasında ufak bir satır veya girinti bile değiştirsek bu sürümü artırmamız gerekir (Örn: 1.2.3).
• **appVersion (Application Version):** Kutunun içine koyduğumuz gerçek uygulamanın (Örn: CodePulse backend servisinin) kendi Docker imaj versiyonudur (Örn: v2.4.0). Uygulama kodu değiştikçe bu değer güncellenir.

2. values.yaml Hiyerarşisi ve Değişken Yönetimi

templates/ klasörünün içindeki boşlukları dolduracak tüm parametreler burada alt alta listelenir. Ancak kurumsal projelerde tek bir values.yaml ile yetinmeyiz. Ortam bazlı yönetim için hiyerarşik yapılar kurarız:

• values.yaml: Tüm ortamlar için geçerli olan ortak ve varsayılan ayarları tutar.
• values-dev.yaml: Sadece geliştirme ortamına özel düşük kaynak (CPU/Memory) ve pod sayılarını tutar.
• values-prod.yaml: Canlı ortama özel yüksek replika sayılarını, gerçek veritabanı bağlantı adreslerini ve production secret'larını barındırır.

Kurulum yaparken helm install core-app ./chart -f values-prod.yaml diyerek ilgili ortamın değişken dosyasını şablonun üzerine giydiririz.

3. templates/

Burası Kubernetes objelerinin taslak halidir. Helm, bu klasördeki dosyaları işlemek için Go programlama dilinin şablon motorunu kullanır. İçeride sadece değişken çekmekle kalmaz, mantıksal kararlar da üretebiliriz:

• Mantıksal Kontroller (if-else): Örneğin bir ağ güvenlik duvarının (NetworkPolicy) sadece production ortamında yaratılmasını istiyorsak şablonun başına ve sonuna şu blokları ekleriz:

{{- if eq .Values.environment "production" }} apiVersion: networking.k8s.io/v1 kind: NetworkPolicy ... {{- end }}

Eğer değişken dosyamızda ortam “development” olarak belirtilmişse, Helm bu YAML dosyasını Kubernetes’e hiç göndermez, havada yok eder.

• Hizalama (indent): YAML dilinin boşluk hassasiyetini hepimiz biliyoruz. Büyük bir konfigürasyon dosyasını veya text bloğunu şablona gömerken sağa doğru tam 4 boşluk kaydırmak için şu sihirli fonksiyonu kullanırız.

data: config.properties: | {{ .Values.appConfig | indent 4 }}

Bu sayede text blokları YAML kurallarını bozmadan şak diye içeriye hizalanır.

• Ortak Kütüphane (_helpers.tpl): Sürekli tekrar eden label (etiket) tanımlamalarını veya isimlendirme standartlarını tek bir yerde yazar, şablonların içinde {{ include "codepulse.labels" . }} diyerek çağırırız.

Geçmiş Yönetimi ve Release Kavramı

Helm dünyasında bir chart’ı cluster’a kurduğumuz an, onun canlıdaki o spesifik örneğine “Release” (Yayın) denir. Aynı şablon klasörünü kullanarak cluster içinde tamamen bağımsız dev-release, staging-release ve prod-release adlarında üç farklı canlı yapı ayağa kaldırabiliriz. Helm, cluster’a yaptığımız her install veya upgrade işleminde arkada yeni bir sürüm numarası (Revision) üretir. Bu revizyonların geçmiş verileri yerel bilgisayarımızda saklanmaz; çünkü yerel disk bozulabilir veya bilgisayar çökebilir. Helm, tüm bu sürüm geçmişini ve eski konfigürasyonları Kubernetes Cluster'ının bizzat kendi içinde, şifreli birer **Secret** nesnesi olarak muhafaza eder. Bu sayede helm rollback komutu koşturulduğunda doğrudan cluster içindeki o Secret nesnesi okunur ve sistem saniyeler içinde eski sürüme geri döndürülebilir.

Git, Helm ve ArgoCD Ortaklığı

Kurumsal altyapılarda canlı ortam ile yerel Git depolarının senkronizasyonunu kusursuz yönetmek için süreci tamamen GitOps (ArgoCD) modeline devrederiz. Bu modelde roller kesindir ve birbirini tamamlar:

• Git: Uygulamanın iskeletinin, şablon parametrelerinin ve tüm ayarlarının durduğu tek doğru kaynaktır.
• Docker & Kubernetes: Uygulamayı izole bir konteynır haline getiren kutu ve o kutuları canlıda yöneten devasa altyapı motorudur.
• Helm: Git’ten gelen parametrelere (values.yaml) göre Kubernetes'in anlayacağı saf YAML dosyalarını anında basan ve paketleyen bir terzi gibidir.
• ArgoCD: Sürekli Git reposunu ve Canlı Cluster’ı izleyen bir müfettiştir. Git reposundaki values.yaml dosyasında bir değişiklik gördüğü an (Örn: pod sayısı 3'ten 5'e çıktığında), hemen arkadaki usta terziyi (Helm) çağırır. Helm o 5 sayısını alarak yeni tertemiz Kubernetes dosyalarını üretir. ArgoCD de bu dosyaları alıp canlı ortama entegre eder.

Bu modelde “Git’te ne yazıyorsa, canlı ortamda o çalışır” kuralı işletilir ve tüm YAML bürokrasisi tek bir merkezden otomatik olarak yönetilir.

Helm ile Üretim Ortamı Stratejileri ve Koruma Filtreleri

Helm, YAML yönetimini ve dağıtım süreçlerini inanılmaz derecede kolaylaştırsa da, canlı altyapılarda kontrolsüz veya körlemesine kullanıldığında büyük kesintilere ya da güvenlik açıklarına yol açabilir. Üretim ortamındaki sistemlerin kararlılığını korumak ve cluster sağlığını garanti altına almak adına mimariye mutlaka dahil ettiğimiz üç temel ileri seviye pratik şunlardır:

1. Dağıtım Öncesi Güvenlik Filtreleri: lint ve --dry-run Simülasyonu

YAML dilinin boşluk (indentation) hassasiyetini ve sözdizimi kurallarını hepimiz biliyoruz. Şablonlarımızın arasına sızacak tek bir yanlış karakter veya hatalı Go Template fonksiyonu, tüm CI/CD pipeline’ımızın patlamasına ya da canlı ortamda hatalı objelerin oluşmasına neden olabilir. Bu riskleri sıfıra indirmek için değişiklikleri cluster’a uygulamadan önce iki aşamalı bir yerel doğrulama filtresi işletiriz:

• **helm lint ./codepulse-chart:** Bu komut, yazdığımız şablon dosyalarını statik kod analizine tabi tutar. Dosyaların Helm standartlarına uygun olup olmadığını, değişkenlerin doğru çağrılıp çağrılmadığını ve YAML hiyerarşisinde bir kopukluk bulunup bulunmadığını cluster'a hiç dokunmadan yerelde denetler. Eğer bir hata varsa dağıtımı erkenden durdurmamızı sağlar.
• **helm upgrade --install core-app ./chart --dry-run:* --dry-run bayrağı, Helm'e şu emri verir: "Bu chart'ı ve values.yaml verilerini al, arkadaki Go motorunda birleştir ve Kubernetes'in önüne fırlatacağın o nihai, saf YAML çıktısını bana terminal ekranında göster; ama cluster'a sakın uygulama!"* Bu sayede, cluster üzerinde canlı hiçbir nesneye zarar vermeden, şablonlarımızın doldurulmuş son halini çıplak gözle simüle edip doğrulamış oluruz.

2. Hassas Verilerin Güvenliği (Production Secret Management)

values.yaml ve ona bağlı ortam dosyaları (values-prod.yaml gibi) Git depolarımız üzerinde düz metin (plain text) yani şifresiz olarak saklanır. Veritabanı şifreleri, üçüncü parti API token'ları, SSL anahtarları veya SSH key'ler gibi hassas verilerin bu dosyalara doğrudan yazılması, tüm şirket altyapısının güvenliğini tehlikeye atmak demektir. Kurumsal altyapılarda bu kör noktayı çözmek için iki profesyonel yaklaşımdan birini tercih ederiz:

• Runtime Entegrasyonu (HashiCorp Vault): Hassas değişkenlerin değerlerini Helm tarafında tamamen boş bırakırız. Uygulama ayağa kalkarken (runtime anında), cluster içinde çalışan bir agent veya özel bir sidecar konteynır vasıtasıyla şifreleri doğrudan HashiCorp Vault gibi merkezi bir gizli yönetim servisinden güvenli tünellerle çeker ve podun içine enjekte eder.
• Git Üzerinde Şifreleme (Sealed Secrets veya Mozilla SOPS): Eğer bu secret verilerini illa ki Git reponuzda tutmak istiyorsanız, Sealed Secrets veya Helm Secrets (SOPS) mekanizmasını kullanırsınız. Bu yöntemde, values-prod.yaml içindeki hassas satırlar asimetrik şifreleme algoritmasıyla yerelde şifrelenir. Bu veri Git üzerinde tamamen anlamsız bir kod yığını olarak durur. Şifreyi çözebilecek yegane private key sadece Kubernetes cluster'ınızın içinde yaşar. ArgoCD bu şifreli dosyayı cluster'a bastığı anda, cluster içindeki controller şifreyi çözer ve güvenli bir Kubernetes Secret nesnesine dönüştürür.

3. Cluster Sağlığı ve Performansı İçin Geçmiş Sınırlandırması (--history-max)

Helm’in en güçlü yanının, cluster içinde her güncellemede yeni bir revizyon (sürüm numarası) üreterek geçmişi şifreli Secret nesnelerinde saklaması olduğunu söylemiştik. Ancak bu durumun kurumsal hayatta sinsi bir performans düşmanına dönüşme riski vardır. Günde onlarca kez otomatik deploy alan (CI/CD) aktif bir projeniz varsa, Helm cluster içinde yüzlerce, hatta binlerce eski revizyon Secret'ı biriktirmeye başlar. Kubernetes’in tüm durum verilerini ve konfigürasyonlarını hafızasında tutan ana veritabanı etcd mimarisidir. Binlerce gereksiz eski Helm sürüm verisi etcd veritabanını gereksiz yere şişirir, cluster yedekleme süreçlerini yavaşlatır ve API server üzerinde bellek baskısı yaratır. Bunun önüne geçmek için üretim ortamı dağıtımlarında geçmiş limitini mutlaka sınırlandırırız:

helm upgrade --install core-app ./chart --history-max 10

Bu parametre sayesinde Helm, cluster içinde sadece son 10 başarılı/başarısız revizyonun kaydını tutar. 11. güncelleme yapıldığında, en eski revizyon otomatik olarak temizlenir. Böylece hem etcd veritabanını tertemiz ve hafif tutmuş oluruz, hem de kriz anında son 10 sürümden birine güvenle rollback yapma esnekliğimizi koruruz.

Helm’i de bitirdiysek Kubernetes konusunun sonuna yaklaşmış bulunmaktayızzz Takipte kalın bol kodlu günlerr🎊