صاحب الموضوع
#1
Kustomize ile Kubernetes Yapılandırması
Kubernetes cluster’ınızda uygulama konfigürasyonlarını yönetirken doğrudan yaml dosyalarını çoğaltmak yerine katmanlı bir yapı kurmak, sürümleme ve varyant yönetimini kolaylaştırır. Kustomize bu ihtiyacı template olmadan, kaynakları değiştirmeden bir arada yönetmeyi mümkün kılar. Aşağıda temel fikirleri, pratik adımları ve yaygın desenleri paylaşıyorum.
Kustomize ile kendi yapınızı kurarken hangi alanda daha çok zorlanıyorsunuz: base ile overlay arası ayrımı mı yoksa patch’leri yönetme mi? Belirli bir örnek senaryo üzerinden adım adım nasıl yapılandıracağınızı paylaşabilir ya da karşılaştığınız bir hatayı birlikte inceleyebiliriz.
Kubernetes cluster’ınızda uygulama konfigürasyonlarını yönetirken doğrudan yaml dosyalarını çoğaltmak yerine katmanlı bir yapı kurmak, sürümleme ve varyant yönetimini kolaylaştırır. Kustomize bu ihtiyacı template olmadan, kaynakları değiştirmeden bir arada yönetmeyi mümkün kılar. Aşağıda temel fikirleri, pratik adımları ve yaygın desenleri paylaşıyorum.
- Temel çalışma mantığı
Kustomize, mevcut kubernetes manifest dosyalarını (Deployment, Service, ConfigMap, Secret vb.) bir araya getirir ve user-defined “kustomization.yaml” dosyası üzerinden varyantlar üretir. patching mekanizması ile mevcut alanları değiştirir; birden çok hedef için aynı temel kaynaktan türemiş konfigürasyonlar elde etmek mümkün olur. - Temel yapı taşları
- base: Uygulamanın ortak manifest dosyalarını içerir. Örneğin Deployment, Service, ConfigMap.
- overlays: Farklı ortamlar için (dev, staging, prod) özel değişiklikleri barındırır. Her overlay kendi kustomization.yaml ile base’ı referans eder ve patchlerle gerekli değişiklikleri uygular.
- patchesStrategicMerge ve patchesJson6902: Alan değişikliklerini belirtirken farklı yaklaşımlar kullanılır. Stratejik birleştirme, alan bazlı güncellemeler için yaygın tercih edilir.
- Örnek senaryo
Bir microservice için prod ve dev varyantları gerektiğini düşünün:
- base içinde bir Deployment ve ConfigMap var.
- dev overlay’ında replicaCount’u 1’e düşüren ve image tag’i dev sürümüne göre değiştiren patch bulunur.
- prod overlay’ında replicaCount’u 3’e çıkartan ve logging seviyesi ConfigMap üzerinden değiştiren patch uygulanır.
Bu yapıda aynı kaynaktan türetilmiş iki farklı çalışma ortamı elde edilmiş olur. - İleri seviye desenler
- CommonLabels ile her kaynağa tutarlı etiketler eklemek: labelSelectors ile izleme ve RBAC temelleri güçlendirilir.
- Secrets ve ConfigMaps için distinct namespace kullanımı veya SecretGenerator ile otomatik üretim.
- Image pullPolicy, nodeSelector, tolerations gibi alanlar overlay seviyesinde kolayca değiştirilebilir.
- Kustomize ile generatorlar kullanarak ConfigMap/Secret içeriğini dış kaynaklardan çekmek veya değişkenleri env vars’a aktarmak.
- En iyi uygulama ipuçları
- Base ve overlays arasındaki farkın net olduğundan emin olun: gereksiz patch’ler yerine açık değişikliklerle ilerleyin.
- Yaml dosyalarını temiz ve okunabilir tutun; aşırı karmaşık patch’lerden kaçının.
- CI/CD’de kustomize ile paketleme adımlarını otomatikleştirin; test aşamasında her overlay için manifestleri doğrulayın.
- Kısa karşılaştırma
Kustomize, Helm gibi çözümlere göre templating kullanmaz; bu, konfigürasyonun gerçeğe daha yakın kalmasını sağlar ama değişkenlik için patch mekanizmasına güvenmeniz gerekir. Büyük ölçekli cluster’larda menzil-sürüm yönetimini, patch’ler ve overlay’lar aracılığıyla disipline etmek mümkündür.
Kustomize ile kendi yapınızı kurarken hangi alanda daha çok zorlanıyorsunuz: base ile overlay arası ayrımı mı yoksa patch’leri yönetme mi? Belirli bir örnek senaryo üzerinden adım adım nasıl yapılandıracağınızı paylaşabilir ya da karşılaştığınız bir hatayı birlikte inceleyebiliriz.
