Giriş: Kubernetes Konfigürasyon Yönetiminin Zorlukları

Giriş: Kubernetes Konfigürasyon Yönetiminin Zorlukları

Kubernetes, modern uygulama dağıtımında standart haline gelmiş olsa da, yüzlerce hatta binlerce satırdan oluşan YAML tabanlı konfigürasyon dosyalarını yönetmek zaman zaman karmaşık bir hal alabilir. Geliştirme (dev), test (staging) ve üretim (production) gibi farklı ortamlar için aynı uygulamanın konfigürasyonlarını tutmak, çoğu zaman tekrarlayan YAML blokları, manuel değişiklikler ve bu durumdan kaynaklanan hatalara yol açar. Bu durum, “Configuration Drift” (konfigürasyon kayması) olarak bilinen, farklı ortamların beklenmedik şekillerde birbirinden ayrılması sorununu beraberinde getirir.

Geleneksel olarak bu sorunları çözmek için Helm gibi şablonlama (templating) araçları kullanılmıştır. Helm, güçlü bir paket yöneticisi ve şablonlama motoru sunsa da, bazı kullanıcılar için getirdiği ek soyutlama katmanı ve Go Template yapısı karmaşık bulunabilir. Kustomize ise bu noktada farklı bir yaklaşım sunar: Mevcut Kubernetes YAML dosyalarını doğrudan değiştirerek, ortamlar arası farklılıkları yönetmek için daha hafif, bildirimsel (declarative) ve şablonlama gerektirmeyen bir yöntem sunar.

Kustomize Nedir ve Neden Kullanmalıyız?

Kustomize’ın Temel Felsefesi: Şablonlama Yerine Yama (Patching)

Kustomize, Kubernetes konfigürasyonlarını yönetmek için geliştirilmiş, bildirimsel bir araçtır. En önemli özelliği, mevcut YAML dosyalarını “yamalayarak” (patching) veya “dönüştürerek” (transforming) değişiklik yapmasıdır. Bu, Helm’in Go Template’leri kullanarak sıfırdan YAML dosyaları oluşturma yaklaşımından farklıdır. Kustomize, temel (base) bir konfigürasyon setini alır ve bu temel üzerine ortamlar arası farklılıkları tanımlayan katmanlar (overlays) uygular.

Neden Kustomize kullanmalıyız?

• Şablonlama Yok: Go Template gibi özel bir şablonlama dilini öğrenme ihtiyacını ortadan kaldırır. Doğrudan standart Kubernetes YAML dosyalarıyla çalışırsınız.
• DRY Prensibi (Don’t Repeat Yourself): Ortak konfigürasyonları tek bir “base” altında tutarak, farklı ortamlar için sadece değişen kısımları tanımlarsınız. Bu, YAML tekrarını büyük ölçüde azaltır.
• Doğal Kubernetes Deneyimi: Kustomize, kubectl komut satırı aracına entegredir (v1.14 ve sonrası). Bu sayede ekstra bir araç kurmaya veya öğrenmeye gerek kalmadan doğrudan kullanabilirsiniz.
• Kolay Anlaşılırlık: Değişiklikler, YAML diff’leri şeklinde kolayca incelenebilir. Bir yamayı okuduğunuzda neyin değiştiğini net bir şekilde görürsünüz.
• Esneklik: Farklı ortamlara özgü değişiklikleri, etiketleri, etiket ön eklerini/son eklerini, isim ön eklerini/son eklerini ve hatta tamamen yeni kaynakları kolayca ekleyebilirsiniz.

Temel Kavramlar: Base ve Overlays

• Base (Temel Konfigürasyon): Bir uygulamanın veya servisin varsayılan, ortamdan bağımsız temel konfigürasyonunu (Deployment, Service, ConfigMap vb.) içeren dizindir. Bu, tüm ortamlar için ortak olan YAML dosyalarını barındırır.
• Overlay (Katman): Belirli bir ortama (dev, staging, prod) özgü değişiklikleri tanımlayan dizindir. Bir overlay, bir veya daha fazla base’i referans alabilir ve bu base’ler üzerindeki alanları yamalayabilir, yeni kaynaklar ekleyebilir veya mevcut kaynakları dönüştürebilir.

Kustomize ile İlk Adımlar ve Pratik Kullanım

Kurulum

Kubernetes 1.14 ve sonraki sürümleriyle birlikte kubectl komutuna Kustomize entegre olarak gelir. Bu nedenle, ayrı bir kurulum yapmanıza gerek yoktur. Komut istemcinizde kubectl kustomize --help yazarak Kustomize’ın hazır olup olmadığını kontrol edebilirsiniz.

Temel Konfigürasyon (Base) Oluşturma

İlk olarak, uygulamamızın temel konfigürasyonunu tanımlayalım. Bu konfigürasyon, tüm ortamlar için geçerli olacak varsayılan ayarları içerecektir.

Proje yapımızı şu şekilde oluşturalım:

my-app/
├── base/
│   ├── deployment.yaml
│   ├── service.yaml
│   └── kustomization.yaml
    

my-app/base/deployment.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-deployment
  labels:
    app: my-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app-container
        image: nginx:1.21.6
        ports:
        - containerPort: 80
    

my-app/base/service.yaml:

apiVersion: v1
kind: Service
metadata:
  name: my-app-service
  labels:
    app: my-app
spec:
  selector:
    app: my-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  type: ClusterIP
    

Şimdi, bu YAML dosyalarını Kustomize’a tanıtmak için bir kustomization.yaml dosyası oluşturalım:

my-app/base/kustomization.yaml:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - deployment.yaml
  - service.yaml
    

Bu temel konfigürasyonu uygulamak için:

kubectl kustomize my-app/base
Veya doğrudan küme'ye uygulamak için:
kubectl apply -k my-app/base
    

Bu komut, Kustomize tarafından işlenmiş nihai YAML çıktısını gösterecektir. Henüz herhangi bir değişiklik yapmadığımız için, doğrudan deployment.yaml ve service.yaml dosyalarının birleşmiş hali olacaktır.

Ortama Özel Değişiklikler (Overlays) Oluşturma

Şimdi geliştirme (dev) ve üretim (prod) ortamları için farklı konfigürasyonlar oluşturalım. Örneğin, dev ortamında replika sayısını 1’den 2’ye çıkaralım ve farklı bir imaj etiketi kullanalım. Prod ortamında ise replika sayısını 3 yapalım ve kaynak limitleri ekleyelim.

Proje yapımızı güncelleyelim:

my-app/
├── base/
│   ├── deployment.yaml
│   ├── service.yaml
│   └── kustomization.yaml
└── overlays/
    ├── dev/
    │   └── kustomization.yaml
    │   └── patch-dev-deployment.yaml
    └── prod/
        └── kustomization.yaml
        └── patch-prod-deployment.yaml
    

Geliştirme Ortamı (Dev Overlay)

my-app/overlays/dev/kustomization.yaml:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
bases:
  - ../../base # base dizinini referans alıyoruz
namePrefix: dev- # Tüm kaynaklara "dev-" ön eki ekle
namespace: dev-namespace # Tüm kaynakları bu namespace'e taşı
patches:
  - path: patch-dev-deployment.yaml
    target:
      kind: Deployment
      name: my-app-deployment
commonLabels:
  environment: dev
    

my-app/overlays/dev/patch-dev-deployment.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-deployment # Base'deki Deployment'ın adıyla eşleşmeli
spec:
  replicas: 2 # Replikaları 2 yap
  template:
    spec:
      containers:
      - name: my-app-container
        image: nginx:1.22.1 # Farklı bir imaj etiketi kullan
    

Dev ortamı konfigürasyonunu görmek için:

kubectl kustomize my-app/overlays/dev
    

Çıktıda, Deployment adının dev-my-app-deployment olduğunu, replikaların 2’ye çıktığını ve imajın nginx:1.22.1 olarak değiştiğini göreceksiniz. Ayrıca tüm kaynaklara environment: dev etiketi eklenmiş ve dev-namespace‘e taşınmış olacaktır.

Üretim Ortamı (Prod Overlay)

my-app/overlays/prod/kustomization.yaml:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
bases:
  - ../../base
namePrefix: prod-
namespace: prod-namespace
patches:
  - path: patch-prod-deployment.yaml
    target:
      kind: Deployment
      name: my-app-deployment
commonLabels:
  environment: prod
    

my-app/overlays/prod/patch-prod-deployment.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-deployment
spec:
  replicas: 3 # Replikaları 3 yap
  template:
    spec:
      containers:
      - name: my-app-container
        resources: # Kaynak limitleri ekle
          limits:
            cpu: "500m"
            memory: "512Mi"
          requests:
            cpu: "250m"
            memory: "256Mi"
    

Prod ortamı konfigürasyonunu görmek için:

kubectl kustomize my-app/overlays/prod
    

Burada da benzer şekilde, Deployment adının prod-my-app-deployment olduğunu, replikaların 3’e çıktığını ve kaynak limitlerinin eklendiğini gözlemleyeceksiniz.

Kustomize’ın Gelişmiş Özellikleri

Kustomize, sadece yamalarla değil, aynı zamanda çeşitli “transformer” ve “generator” özellikleri ile de konfigürasyonlarınızı zenginleştirmenizi sağlar.

ConfigMap ve Secret Oluşturucular (Generators)

kustomization.yaml dosyasına doğrudan ConfigMap ve Secret oluşturabilirsiniz. Kustomize, belirtilen dosyalardan veya değişmez (literal) değerlerden bu kaynakları otomatik olarak oluşturur ve her değişikliği algıladığında yeni bir hash ile isimlerini günceller (immutable ConfigMaps/Secrets için idealdir).

Örnek kustomization.yaml:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - deployment.yaml
configMapGenerator:
  - name: my-app-config
    files:
      - config/app-settings.ini
    literals:
      - APP_ENV=production
secretGenerator:
  - name: my-app-secret
    literals:
      - API_KEY=supersecretkey
      - DB_PASSWORD=dbpassword123
    type: Opaque
    

config/app-settings.ini dosyası:

[database]
host = localhost
port = 5432
    

Kustomize bu tanımlamalardan otomatik olarak ConfigMap ve Secret kaynaklarını oluşturacak ve Deployment’ınızda referans verebileceğiniz hale getirecektir.

Ortak Etiketler ve Açıklamalar (Common Labels & Annotations)

Tüm kaynaklara otomatik olarak etiket veya açıklama eklemek için kullanışlıdır:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - deployment.yaml
commonLabels:
  app.kubernetes.io/name: my-app
  app.kubernetes.io/instance: my-app-prod
commonAnnotations:
  managed-by: kustomize
  owner: platform-team
    

İsim Ön Ekleri/Son Ekleri ve Namespace (Name Prefix/Suffix & Namespace)

Yukarıdaki örneklerde gördüğümüz gibi, tüm kaynak adlarına bir ön ek ekleyebilir veya kaynakların dağıtılacağı varsayılan namespace‘i belirleyebilirsiniz. Bu, ortamlar arası çakışmaları önlemek için çok önemlidir.

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - deployment.yaml
namePrefix: prod-
nameSuffix: -v1 # Tüm kaynak adlarına "-v1" son eki ekler
namespace: my-prod-namespace
    

Bileşenler (Components)

Kustomize’ın 5. sürümüyle tanıtılan “components” özelliği, küçük, tekrar kullanılabilir Kustomization parçacıkları tanımlamanıza olanak tanır. Örneğin, bir uygulamanın izleme etiketlerini veya kaynak limitlerini tanımlayan bir bileşen oluşturup bunu birden fazla overlay’de kullanabilirsiniz.

Örnek:

my-app/
├── base/
│   └── ...
├── components/
│   └── monitoring/
│       └── kustomization.yaml # monitoring etiketlerini içerir
└── overlays/
    ├── dev/
    │   └── kustomization.yaml
    └── prod/
        └── kustomization.yaml
    

my-app/components/monitoring/kustomization.yaml:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
commonLabels:
  prometheus.io/scrape: "true"
  prometheus.io/port: "8080"
    

my-app/overlays/prod/kustomization.yaml (içinde bileşeni kullanır):

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
bases:
  - ../../base
components:
  - ../../components/monitoring # Monitoring bileşenini dahil et
patches:
  - path: patch-prod-deployment.yaml
    target:
      kind: Deployment
      name: my-app-deployment
    

Sonuç, En İyi Pratikler ve Sıkça Sorulan Sorular (SSS)

Kustomize, Kubernetes konfigürasyon yönetimini basitleştirmek için güçlü, esnek ve şablonlama içermeyen bir yaklaşım sunar. Temel ve katman (base ve overlay) kavramlarıyla, farklı ortamlar için konfigürasyonları DRY prensibine uygun olarak yönetmek çok daha kolay hale gelir. kubectl entegrasyonu sayesinde öğrenme eğrisi düşüktür ve mevcut Kubernetes iş akışlarınıza sorunsuz bir şekilde entegre edilebilir.

En İyi Pratikler

• Base’i Temiz ve Genel Tutun: Base konfigürasyonlarınızı mümkün olduğunca jenerik tutun. Ortama özel hiçbir bilgiyi base’e dahil etmeyin.
• Overlays’leri Odaklı Tutun: Her overlay sadece kendi ortamına özgü değişiklikleri içermelidir. Gereksiz veya başka ortamlara ait yamaları eklemeyin.
• Versiyon Kontrolü Kullanın: Tüm Kustomize dosyalarınızı (base, overlays, yamalar) Git gibi bir versiyon kontrol sisteminde saklayın. Bu, değişiklikleri izlemenizi ve geri almanızı kolaylaştırır.
• Küçük ve Modüler Yamalar Oluşturun: Büyük, karmaşık yamalar yerine, belirli bir özelliği veya alanı değiştiren küçük, odaklı yamalar oluşturun. Bu, okunabilirliği ve bakımı artırır.
• CI/CD ile Entegre Edin: Kustomize’ı CI/CD pipeline’larınıza entegre ederek, otomatik dağıtımlar ve tutarlı ortamlar sağlayın.

Sıkça Sorulan Sorular (SSS)

Kustomize ve Helm Arasındaki Temel Fark Nedir?

Kustomize, mevcut YAML dosyalarını “yamalayarak” veya “dönüştürerek” çalışır. Şablonlama motoru yoktur, doğrudan standart YAML ile çalışır. Helm ise Go Template kullanarak sıfırdan YAML dosyaları oluşturan bir şablonlama motorudur ve aynı zamanda bir paket yöneticisidir. Kustomize daha hafif ve Kubernetes YAML’lerine daha yakınken, Helm daha kapsamlı bir paketleme ve şablonlama çözümü sunar.

Kustomize hangi Kubernetes versiyonlarında desteklenir?

Kustomize, Kubernetes 1.14 ve sonraki sürümleriyle birlikte kubectl komutuna entegre edilmiştir. Daha eski kubectl versiyonları için ayrı bir Kustomize CLI aracı indirmeniz gerekebilir, ancak bu artık yaygın bir durum değildir.

Kustomize ile Secret’ları nasıl yönetebilirim?

Kustomize’ın secretGenerator özelliğini kullanarak Secret’ları oluşturabilirsiniz. Bu özellik, belirtilen dosyalardan veya değişmez değerlerden Secret’lar oluşturur ve her değişiklikte yeni bir hash ile isimlerini günceller. Ancak, hassas verileri doğrudan YAML dosyalarına yazmak yerine, bunları harici bir sistemden (örneğin Vault, KMS) alıp SecretGenerator’a beslemek daha güvenli bir yaklaşımdır.

Kustomize ile dışarıdan bir Git reposundaki base’i kullanabilir miyim?

Evet, Kustomize uzak (remote) base’leri destekler. kustomization.yaml dosyanızda bases veya resources alanında bir Git URL’si belirterek uzak bir depodan konfigürasyonları çekebilirsiniz:

bases:
  - github.com/kubernetes-sigs/kustomize/examples/helloWorld?ref=master
    

Kustomize’ı CI/CD pipeline’ıma nasıl entegre edebilirim?

CI/CD pipeline’ınızda Kustomize’ı kullanmak oldukça basittir. Örneğin, bir Jenkinsfile veya GitHub Actions iş akışında, ilgili ortama ait Kustomize dizinine gidip kubectl apply -k komutunu çalıştırabilirsiniz. Bu, Kustomize tarafından oluşturulan nihai YAML’i doğrudan Kubernetes kümenize uygulayacaktır.