Kubernetes Kustomize ile Tanışalım: Başlangıç Rehberi

Distributed Systems

Kubernetes

Kubernetes Kustomize ile Tanışalım: Başlangıç Rehberi

Erkan ŞİRİN|

Ekim 15, 2025

| Yorumlar 0

Merhaba! Bugün Kubernetes dünyasında uygulama yapılandırmalarını (configuration) yönetmek için kullanılan harika bir araçtan bahsedeceğiz: Kustomize. Eğer Kubernetes ile çalışıyorsanız ve farklı ortamlar için sürekli YAML dosyalarını kopyalayıp değiştirmekten bıktıysanız, doğru yerdesiniz. Beraber Kustomize’ı öğreneceğiz ve basit örneklerle nasıl kullanılacağını göreceğiz.

Kustomize Nedir?

Kustomize, Kubernetes için geliştirilmiş bir yapılandırma yönetim (configuration management) aracıdır [1][2]. En güzel tarafı, Kubernetes 1.14 sürümünden itibaren kubectl içine entegre edilmiş durumda, yani ekstra bir şey kurmanıza gerek yok [1].

Peki Kustomize tam olarak ne işe yarıyor? Şöyle düşünün: Bir uygulamanız var ve bunu geliştirme (development), test (staging) ve canlı (production) ortamlarına deploy etmeniz gerekiyor. Her ortamda farklı ayarlar istiyorsunuz:

Geliştirmede 2 replika, canlıda 10 replika
Farklı ConfigMap değerleri
Farklı kaynak limitleri (resource limits)
Farklı etiketler (labels) ve açıklamalar (annotations)

Eski yöntemle her ortam için ayrı YAML dosyaları oluşturmanız gerekirdi. Bu hem zahmetli hem de hata yapmaya açık bir yaklaşım [2]. İşte Kustomize bu sorunu çözuyor!

Kustomize’ın Temel Kavramları

Kustomize’ı anlamak için iki temel kavramı öğrenmemiz gerekiyor [2][3]:

1. Base (Temel)

Base, tüm ortamlarda ortak olan temel Kubernetes kaynaklarınızı (resources) içerir. Deployment, Service, ConfigMap gibi manifesto dosyalarınızın orijinal halleri burada durur [2]. Düşünün ki bu sizin ana tarifniz.

2. Overlay (Kaplama)

Overlay’ler ise her ortama özgü değişiklikleri içerir [2]. Base üzerine yamalar (patches) uygulayarak ortama özel versiyonlar oluşturursunuz. Geliştirme ortamı için bir overlay, canlı ortam için başka bir overlay… Her biri base’i alır ve üzerine kendi özelleştirmelerini yapar [3].

3. kustomization.yaml

Bu dosya Kustomize’ın kalbidir [1][4]. Hangi kaynakların dahil edileceğini, hangi yamaların uygulanacağını, hangi etiketlerin ekleneceğini bu dosyada tanımlıyoruz.

İlk Kustomize Projemizi Oluşturalım

Hadi şimdi pratik yapalım! Basit bir NGINX deployment’ı için Kustomize projesi oluşturacağız.

Adım 1: Proje Yapısını Oluşturalım

Önce klasör yapımızı oluşturalım:

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

Adım 2: Base Dosyalarını Oluşturalım

base/deployment.yaml:

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

base/service.yaml:

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:
    app: nginx
  ports:
  - port: 80
    targetPort: 80
  type: ClusterIP

base/kustomization.yaml:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
- deployment.yaml
- service.yaml

commonLabels:
  app: nginx
  managed-by: kustomize

Bu kustomization.yaml dosyasında [1][4]:

resources: Hangi YAML dosyalarını dahil edeceğimizi belirtiyoruz
commonLabels: Tüm kaynaklara otomatik olarak eklenecek ortak etiketleri tanımlıyoruz

Adım 3: Geliştirme Ortamı için Overlay Oluşturalım

overlays/dev/kustomization.yaml:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

namePrefix: dev-

commonLabels:
  environment: development

bases:
- ../../base

patches:
- patch: |-
    - op: replace
      path: /spec/replicas
      value: 1
  target:
    kind: Deployment
    name: nginx-deployment

Burada neler yaptık?

namePrefix: Tüm kaynak isimlerine “dev-” öneki ekledik [1]
commonLabels: Ortama özel etiket ekledik
bases: Base dizinini referans gösterdik
patches: Replika sayısını 1’e düşürdük (geliştirmede fazla kaynak kullanmaya gerek yok)

Adım 4: Canlı Ortam için Overlay Oluşturalım

overlays/prod/kustomization.yaml:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

namePrefix: prod-

commonLabels:
  environment: production

bases:
- ../../base

patches:
- patch: |-
    - op: replace
      path: /spec/replicas
      value: 5
  target:
    kind: Deployment
    name: nginx-deployment
- patch: |-
    - op: replace
      path: /spec/type
      value: LoadBalancer
  target:
    kind: Service
    name: nginx-service

replicas:
- name: nginx-deployment
  count: 5

Canlı ortamda daha fazla özelleştirme yaptık:

Replika sayısını 5’e çıkardık
Service tipini LoadBalancer’a değiştirdik (dışarıdan erişim için)

Adım 5: Build ve Deploy Edelim

Şimdi Kustomize’ın sihirli tarafını görelim! Önce ne ürettiğine bakalım:

# Geliştirme ortamı için build edelim
kubectl kustomize overlays/dev

# Canlı ortam için build edelim
kubectl kustomize overlays/prod

Bu komutlar, Kustomize’ın base ve overlay’leri birleştirerek ürettiği nihai YAML’ları gösterecek. Orijinal dosyalara dokunmadan! [3]

Eğer sonuçlardan memnunsak, deploy edelim:

# Geliştirme ortamına deploy
kubectl apply -k overlays/dev

# Canlı ortama deploy
kubectl apply -k overlays/prod

-k parametresi kubectl’e “bu bir Kustomize dizini” diyor [1].

Daha Fazla Özellik: ConfigMap ve Secret Üretimi

Kustomize’ın çok kullanışlı bir özelliği daha var: ConfigMap ve Secret’ları otomatik olarak üretebilir [1][3].

base/kustomization.yaml’a ekleyelim:

configMapGenerator:
- name: app-config
  literals:
  - APP_ENV=base
  - LOG_LEVEL=info

secretGenerator:
- name: app-secrets
  literals:
  - API_KEY=placeholder-key

Overlay’lerde bu değerleri değiştirebiliriz:

overlays/prod/kustomization.yaml’a ekleyelim:

configMapGenerator:
- name: app-config
  behavior: merge
  literals:
  - APP_ENV=production
  - LOG_LEVEL=error
  - CACHE_ENABLED=true

behavior: merge parametresi, base’deki değerleri koruyarak yenilerini ekler veya değiştirir [3].

Strategic Merge Patches vs JSON Patches

Kustomize iki tür yama (patch) yöntemi sunar [5]:

Strategic Merge Patch

Daha kolay ve okunabilir. YAML formatında yazılır:

patches:
- path: replica-patch.yaml
  target:
    kind: Deployment
    name: nginx-deployment

replica-patch.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 10

JSON Patch

Daha hassas kontrol için JSON Patch kullanılır [5]:

patches:
- patch: |-
    - op: add
      path: /spec/template/spec/containers/0/env/-
      value:
        name: NEW_VAR
        value: "new-value"
  target:
    kind: Deployment

JSON Patch işlemleri (operations):

add: Yeni alan ekler
replace: Var olan alanı değiştirir
remove: Alan siler
copy ve move: Değerleri kopyalar veya taşır

Gerçek Hayat Senaryosu: Multi-Environment Setup

Şimdi daha gerçekçi bir senaryo görelim. Bir mikroservis uygulamanız var:

myapp/
├── base/
│   ├── deployment.yaml
│   ├── service.yaml
│   ├── configmap.yaml
│   └── kustomization.yaml
└── overlays/
    ├── dev/
    │   ├── kustomization.yaml
    │   └── resource-limits.yaml
    ├── staging/
    │   ├── kustomization.yaml
    │   └── hpa.yaml
    └── prod/
        ├── kustomization.yaml
        ├── resource-limits.yaml
        └── hpa.yaml

overlays/prod/hpa.yaml (Horizontal Pod Autoscaler):

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: myapp-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: myapp
  minReplicas: 3
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

overlays/prod/kustomization.yaml:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

namespace: production

bases:
- ../../base

resources:
- hpa.yaml

patches:
- path: resource-limits.yaml

commonLabels:
  environment: prod
  version: v2.0.1

images:
- name: nginx
  newName: myregistry.com/nginx
  newTag: 2.0.1

images bölümü ile base’deki image’ları değiştirebiliyoruz [3]. Çok pratik!

Kustomize’ın Avantajları

Şimdiye kadar gördüklerimizden Kustomize’ın avantajlarını özetleyelim [2][3]:

Template-free (Şablonsuz): Saf YAML kullanıyorsunuz, öğrenme eğrisi düşük [3][6]
kubectl ile entegre: Ekstra kurulum gereksiz [1][6]
Deklaratif: Kubernetes felsefesiyle uyumlu [2][7]
DRY prensibi: Base’i bir kere yaz, her yerde kullan [2]
Git-friendly: Tüm yapılandırma git’te tutulabilir [3][6]
Orijinal dosyalara dokunmaz: Base dosyalarınız temiz kalır [3]

Kustomize vs Helm: Hangisini Kullanmalıyım?

Kubernetes dünyasında en çok sorulan sorulardan biri bu [6][8]. Hadi her ikisini de kıyaslayalım.

Helm Nedir?

Helm, Kubernetes için bir paket yöneticisi (package manager) [6][9]. Linux’taki apt/yum veya macOS’taki Homebrew gibi düşünebilirsiniz. Helm Chart’ları (paketler) kullanarak karmaşık uygulamaları tek komutla deploy edebilirsiniz.

Temel Farklar

Özellik	Kustomize	Helm
Yaklaşım	Overlay (Kaplama) motoru	Template (Şablon) motoru [7]
Kurulum	kubectl ile birlikte gelir	Ayrı kurulum gerekir [6][9]
Dosya Formatı	Saf YAML	Go template + YAML [6][8]
Paket Yönetimi	Yok	Var (Chart repository) [6][9]
Versiyon Yönetimi	Yok	Var (Release tracking) [8][10]
Rollback	Manuel	Otomatik [10]
Öğrenme Eğrisi	Düşük	Yüksek [8][7]
Okunabilirlik	Yüksek (Saf YAML)	Düşük (Template logic) [6][8]

Helm’in Avantajları

1. Hazır Chart Ekosistemi

Helm’in binlerce hazır chart’ı var [6]. PostgreSQL, Redis, Prometheus gibi popüler uygulamaları tek komutla kurabilirsiniz:

helm install my-postgres bitnami/postgresql

2. Paket Yönetimi

Helm, uygulamanızı bir birim olarak yönetir [6][9]:

Versiyonlama
Rollback (geri alma)
Upgrade (güncelleme)
Lifecycle hooks (yaşam döngüsü kancaları)

3. Template Gücü

Go template’leri ile karmaşık mantık oluşturabilirsiniz [6][8]:

{{- if .Values.autoscaling.enabled }}
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
# ...
{{- end }}

4. values.yaml ile Parametre Yönetimi

Tek bir dosyada tüm parametrelerinizi tutabilirsiniz [9]:

# values.yaml
replicaCount: 3
image:
  repository: nginx
  tag: 1.21
service:
  type: LoadBalancer
  port: 80

Kustomize’ın Avantajları

1. Basitlik ve Okunabilirlik

Kustomize saf YAML kullanır [6][8]. Template logic yok, direkt anlaşılır:

# Helm template (karmaşık)
replicas: {{ .Values.replicaCount | default 3 }}

# Kustomize (basit)
replicas: 3

2. kubectl ile Native Entegrasyon

Ekstra araç gereksiz [1][6][9]:

kubectl apply -k ./overlays/prod

3. GitOps Dostu

Tüm YAML’lar git’te saklanabilir, CI/CD pipeline’larına kolay entegre [3][6].

4. Vendor YAML’larını Kullanma

Üçüncü parti bir YAML’ı fork etmeden üzerinde değişiklik yapabilirsiniz [4]:

# Vendor'un deployment'ını kullan
resources:
- github.com/vendor/app/deployment.yaml

# Sadece ihtiyacın olanı değiştir
patches:
- patch: |-
    - op: replace
      path: /spec/replicas
      value: 10
  target:
    kind: Deployment

Helm’in Dezavantajları

Template Karmaşıklığı: Büyük chart’lar okunması zor hale gelebilir [6][8][7]
Debug Zorluğu: Template render edilmeden hata bulmak zor [8][7]
Ayrı Araç: Kurulum ve güncelleme gerektirir [6][9]
Güvenlik Geçmişi: Helm 2’deki Tiller güvenlik sorunlarıyla ünlüydü (Helm 3’te kaldırıldı) [7]

Kustomize’ın Dezavantajları

Hazır Paket Yok: Her şeyi kendiniz yazmalısınız [7][10]
Versiyon Yönetimi Yok: Release tracking built-in değil [8][10]
Basit Özellikler: Helm kadar gelişmiş değil [7]
Dokümantasyon: Helm kadar zengin kaynak yok [7]

Ne Zaman Hangisini Kullanmalı?

Helm’i tercih edin eğer:

Hazır chart’lardan faydalanmak istiyorsanız [6][10]
Paket yönetimi ve rollback önemli ise [8][10]
Karmaşık, conditional logic gerekiyor [6]
Ekibiniz template’lere aşina [8]

Kustomize’ı tercih edin eğer:

Basitlik ve okunabilirlik öncelikli [6][8]
Kendi YAML’larınızı yönetiyorsanız [6][7]
kubectl dışında araç istemiyorsanız [6][9]
GitOps workflow kullanıyorsanız [3][6]
Vendor YAML’larını customize etmeniz gerekiyorsa [4]

İkisini Birlikte Kullanabilir miyiz?

Evet! Aslında çoğu organizasyon her ikisini de kullanıyor [6][10]:

# 1. Helm ile base uygulamayı kur
helm template my-app ./chart > base-app.yaml

# 2. Kustomize ile ortama özel değişiklikler yap
kubectl apply -k overlays/prod

Kullanım senaryosu:

Helm: Üçüncü parti uygulamaları paket olarak yönet
Kustomize: Kendi uygulamalarınız için environment-specific customization

Best Practice:

Base chart’ları Helm ile yönetin
Environment farklılıklarını Kustomize ile yapın
CI/CD pipeline’ında ikisini birleştirin [6][10]

Sonuç: Kustomize ile Kubernetes Yönetimi Kolaylaşıyor

Kustomize, Kubernetes yapılandırmalarını yönetmek için harika bir araç. Özellikle çoklu ortam (multi-environment) deployment’larında işinizi çok kolaylaştırıyor. Template complexity’si olmadan, saf YAML kullanarak DRY prensibine uygun yapılandırmalar oluşturabiliyorsunuz.

Öğrendiklerimizi özetleyelim:

Kustomize overlay motoru kullanır, template değil
Base + Overlay yapısı ile DRY prensibine uygun çalışır
kubectl ile entegre, ekstra kurulum gereksiz
ConfigMap ve Secret generator’ları çok kullanışlı
Strategic Merge ve JSON Patch ile esnek yamalar oluşturabilirsiniz
Helm ile farklı amaçlara hizmet eder, birlikte kullanılabilir

Helm vs Kustomize tartışmasında kazanan yok – hangi ihtiyacınız varsa ona göre seçim yapın. Hatta ikisini de kullanın! Önemli olan Kubernetes yönetiminizi kolaylaştırmak ve hatasız deployment’lar yapmak.

Umarım bu rehber Kustomize’a başlamanız için yeterli bilgiyi sağlamıştır. Şimdi sıra sizde – kendi projelerinizde Kustomize’ı deneyerek öğrenmeye devam edin!

Happy Kustomizing! 🚀

Kaynaklar

[1] Kubernetes Official Documentation. “Declarative Management of Kubernetes Objects Using Kustomize.” kubernetes.io. https://kubernetes.io/docs/tasks/manage-kubernetes-objects/kustomization/

[2] DevOpsCube. “Kubernetes Kustomize Tutorial (Comprehensive Guide).” https://devopscube.com/kustomize-tutorial/

[3] Kustomize Official Site. “Kustomize – Kubernetes native configuration management.” https://kustomize.io/

[4] DEV Community. “Kubernetes Kustomize Tutorial: A Beginner-Friendly Developer Guide!” https://dev.to/pavanbelagatti/kubernetes-kustomize-tutorial-a-beginner-friendly-developer-guide-322n

[5] Glasskube. “The complete Kustomize tutorial.” https://glasskube.dev/blog/patching-with-kustomize/

[6] Spacelift. “Kustomize vs. Helm – How to Use & Comparison.” https://spacelift.io/blog/kustomize-vs-helm

[7] Harness. “Comparing Helm vs Kustomize.” https://www.harness.io/blog/helm-vs-kustomize

[8] Baeldung. “What Is the Difference Between Helm and Kustomize?” https://www.baeldung.com/ops/kubernetes-helm-vs-kustomize

[9] Apptio. “Chapter 11: Kustomize vs Helm.” https://www.apptio.com/topics/kubernetes/devops-tools/kustomize-vs-helm/

[10] FOSSTechnix. “Helm vs Kustomize with Real time Examples.” https://www.fosstechnix.com/helm-vs-kustomize-with-real-time-examples/

Bir yanıt yazın Yanıtı iptal et

Yorum yapabilmek için oturum açmalısınız.

Kustomize Nedir?

Kustomize’ın Temel Kavramları

1. Base (Temel)

2. Overlay (Kaplama)

3. kustomization.yaml

İlk Kustomize Projemizi Oluşturalım

Adım 1: Proje Yapısını Oluşturalım

Adım 2: Base Dosyalarını Oluşturalım

Adım 3: Geliştirme Ortamı için Overlay Oluşturalım

Adım 4: Canlı Ortam için Overlay Oluşturalım

Adım 5: Build ve Deploy Edelim

Daha Fazla Özellik: ConfigMap ve Secret Üretimi

Strategic Merge Patches vs JSON Patches

Strategic Merge Patch

JSON Patch

Gerçek Hayat Senaryosu: Multi-Environment Setup

Kustomize’ın Avantajları

Kustomize vs Helm: Hangisini Kullanmalıyım?

Helm Nedir?

Temel Farklar

Helm’in Avantajları

Kustomize’ın Avantajları

Helm’in Dezavantajları

Kustomize’ın Dezavantajları

Ne Zaman Hangisini Kullanmalı?

İkisini Birlikte Kullanabilir miyiz?

Sonuç: Kustomize ile Kubernetes Yönetimi Kolaylaşıyor

Kaynaklar

Related Posts:

Bir yanıt yazın Yanıtı iptal et

Sen Yenisin Galiba

Veri Bilimi

İş Analiği

Uygulama Araçları

Veri Bilimi Okulu 2025@All rights reserved

Password Requirements: