Kustomize 102: Kapsamlı Rehber

Uygulamaları Kubernetes’e deploy etmek istediğinizi ve DEV, QA, STG, PROD gibi birden çok ortamınız olduğunu varsayalım. Her ortamda, deploylar için farklı yapılandırmalarınız olabilir.

Örneğin, dev ve qa’de sürekli güncellemelere ihtiyacınız olmayabilir, ancak prod’da buna ihtiyacınız olabilir. Ayrıca, her ortamda farklı replica sayıları, farklı CPU ve bellek kaynakları, ek açıklamalar vb. kullanmak isteyebilirsiniz.

Bu nedenle, ilgili ortamın gereksinimlerini karşılamak için deploy’ları özelleştirmeniz gerekir.

Bu sorunun basit çözümü, her ortam için bir tane olmak üzere dört ayrı directory oluşturmak ve tüm Kubernetes manifestlerini ilgili klasörlere eklemektir. Ancak ölçeklenebilir bir çözüm değildir. Çünkü yeni uygulamalar dahil edildiğinde veya yeni yapılandırma dosyaları eklendiğinde, klasörlerdeki tüm YAML dosyalarını manuel olarak yönetmek zor olacaktır. Bu, yapılandırma kirliliği sorunlarına da yol açacaktır.

Farklı bir çözüm olarak YAML dosyalarınızdaki yapılandırmaları değiştirmek için script dosyaları oluşturabilirsiniz, ancak çok sayıda hizmetiniz olduğunda bu da iyi bir yaklaşım olmaz.

Tüm bu sorunlar Kustomize kullanılarak çözülebilir. Ayrıca onu diğer yapılandırma araçlarından ayıran bir özellik de Kubernetes cluster’larını yönetmek için komut satırı arabirimi olan kubectl ile sıkı entegrasyonudur.

Aşağıdaki başlıklarda, Kustomize kavramlarına ve faydalarına detaylı bir şekilde bakacağız. Kubernetes deploy’larını nasıl basitleştirdiğini size göstermek için bir Nginx Dağıtımı kullanan Kustomize’ın pratik bir örneğine de bakacağız.

Kustomize Nedir?

Kustomize, Kubernetes için açık kaynaklı bir yapılandırma yönetimi aracıdır.

Kustomize; Orijinal YAML dosyalarını değiştirmeden birden çok ortam için deployments, daemonsets, services, configMaps, vb. manifestleri declarative şekilde tanımlamanıza ve yönetmenize olanak tanır.

Basitçe ifade etmek gerekirse, YAML dosyaları için tek bir doğru kaynağınız vardır ve ortam gereksinimlerine göre temel YAML dosyalarının üzerine gereken yapılandırmaları uygularsınız.

Kustomize, iki temel kavrama sahiptir: Base ve Overlays. Kustomize ile temel dosyaları (ortak YAML’lar) tüm ortamlarda yeniden kullanabilir ve bu ortamlar için her biri için üstüne eklemeler (patches) yapabiliriz.

Overlaying, manifest dosyasının özelleştirilmiş bir versiyonunu oluşturma sürecidir

(base manifest + overlay manifest = customized manifest files)

Tüm ortamlar için oluşturduğunuz klasörün içerisinde kustomization.yaml dosyası olmalıdır.

Kustomize Özellikleri

Kustomize’in temel özellikleri aşağıdaki gibidir:

• Kubernetes YAML’larıyla aynı declarative yapıya sahip bir yapılandırma aracı olarak işlev görür.

• Orijinal dosyaları değiştirmeden manifest’leri değiştirebilir.

• Tüm manifest’lere ortak etiketler ve açıklamalar ekleyebilir.

• Deploy edildiği env’a bağlı olarak container image’larını değiştirebilir.

• Kustomize ayrıca, Secrets ve configMaps oluşturmak için env dosyalarını veya key-value kullanan secretGenerator ve configMapGenerator ile birlikte gelir.

Tüm bu kavramlar ve özellikler, size Kustomize’ı nginx dağıtımı kullanarak nasıl kullanacağınızı pratik olarak gösterdiğim bölümde daha anlamlı hale gelecektir.

Kustomize Kurulumu

Not: Kustomize’u kurmadan önce, bir Kubernetes cluster’ınızın çalışır durumda olması ve kubectl’in local’inizde kurulu ve cluster’a bağlı olması gerekir.

Kustomize, açık kaynaklı bir araçtır ve tek başına binary olarak veya kubectl eklentisi olarak kullanılabilir. Kustomize’ın kurulumu oldukça kolaydır.

Kubectl Kustomize

Kustomize modülü kubectl içine entegre edilmiştir. Kubectl üzerinden doğrudan Kustomize’ı kullanabilirsiniz. Aşağıdaki komutu kullanarak bunu doğrulayabilirsiniz.

kubectl kustomize --help

Standalone Kustomize

Aşağıda belirttiğim komut, işletim sistemini otomatik olarak algılar ve Kustomize’ı yükler.

curl -s "https://raw.githubusercontent.com/kubernetes-sigs/kustomize/master/hack/install_kustomize.sh"  | bash

Kurulumdan sonra, aşağıdaki komutu çalıştırarak Kustomize’nin yüklendiğini doğrulayın. Sürümü göstermiyorsa terminalinizi kapatın ve yeni bir terminal açarak komutu çalıştırın.

kustomize version

Hala bash: kustomize: command not found hatası alıyorsanız, aşağıdaki komutu çalıştırın ve tekrar kontrol edin.

sudo install -o root -g root -m 0755 kustomize /usr/local/bin/kustomize

Ayrıca MAC ve Windows üzerinde chocolatey veya brew kullanarak da kurabilirsiniz.

MAC Kullanıcıları İçin

brew install kustomize

Windows Kullanıcıları İçin

choco install kustomize

Kustomize’ı Anlayalım

Öncelikle aşağıdaki anahtar konseptleri anlamanız gerekir.

• kustomization yaml dosyası
• Base and Overlays
• Transformers
• Patches

Her bir konsepte ayrı ayrı göz atalım.

kustomization.yaml Dosyası

kustomization.yaml dosyası, Kustomize aracı tarafından kullanılan ana dosyadır. Kustomize build komutunu çalıştırdığınızda Kustomize kustomization.yaml adlı dosyayı arar. Bu dosya, Kustomize tarafından yönetilmesi gereken tüm Kubernetes manifest’lerinin (YAML dosyaları) bir listesini içerir. Ayrıca oluşacak manifestler için tüm custom özelleştirmeleri içerir.

Aşağıda örnek kustomization.yaml dosyasını görebilirsiniz.. Tüm yapılandırmalar için endişelenmeyin. Sonraki bölümlerde tüm alanlardan bahsedeceğim.

Base ve Overlays

Base klasörü tüm ortamlarda (dev, qa, stg, prod) aynı olacak yapılandırmayı temsil eder. Kullanacağımız tüm kubernetes manifestlerini base’e ekleriz. Daha sonra default değerleri yazacağımız manifestler ile elbette değiştirebileceğiz.

Overlays klasörü default olarak kullandığımız manifestlerin üzerine özelleştirmeler yaptığımız yapılandırmayı temsil eder. Overlay ile her ortam için spesifik ayarlamalar yapabiliriz. Default base klasörümüzdeki tüm manifest değerlerinin üzerine yazma veya değiştirme işlemlerini burada yaparız.

Temel olarak Base klasörünüzdeki manifestleriniz overlays üzerinde birleşerek ve ezilerek k8s manifestleriniz oluşur.

Transformers

Adından da anlaşılacağı gibi, Transformers bir config’e belirttiğimiz değerleri ekleyen veya dönüştüren konsepttir. Transformers’ı kullanarak temel Kubernetes YAML yapılandırmalarımızı belirteceğimiz değerlere güncelleyebiliriz. Bazı transformer’lar ve kullanımları aşağıdaki gibidir;

• commonLabel: Tüm Kubernetes manifestlerine bir etiket ekler
• namePrefix: Tüm manifest dosyalarına ortak bir önek ekler.
• nameSuffix: Tüm manifest dosyalarına ortak bir sonek ekler.
• Namespace: Tüm manifestlere ortak bir namespace ekler.
• commonAnnotations: Tüm manifestlere ortak bir annotations ekler.

Örneklerle biraz daha iyi anlayalım. Aşağıdaki resimde kustomization.yaml dosyamızda commonLabels kullanarak deployment kind’ımıza env:dev label’ını ekledik.

Image Transformer

Deployment manifestimizin içerisindeki container image’ı değiştirmemize olanak tanır.

Aşağıdaki resimde bulunan örnekte transformers kullanarak nginx olan image’ı deployment.yaml ‘da bulup adını ubuntu ile değiştirdik. Bunu kustomization.yaml dosyamızda aşağıdaki gibi kullandık.

Patches (Overlays)

Patches veya overlays kubernetes configlerimizi yöneten bir başka metottur. Manifestlerimizde değişiklik yapmak için daha spesifik özellikler sağlar. Değişiklik yapabilmemiz için 3 parametre kullanmamız gerekir.

• Operation Type: Burada add veya remove veya replace kullanılır.
• Target: Değiştirmek istediğimiz resouce adı. Örneğin Deployment
• Value: Eklenecek veya değiştirilecek değer adı. Remove işlemi için burası boş bırakılır.

Patches yapmanın ise 2 yöntemi vardır.

• JSON 6902 Patching
• Stragetic Merge Patching

JSON 6902 Patching

Bu yöntemde 2 şeyi yönetiriz. Bunlar target ve patch details. Örnekle daha iyi anlayalım.

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

Aşağıdaki resimde sonucu görüp daha iyi anlayalım.

Stragetic Merge Patching

Bu yolda verdiğimiz yapılandırma config’i standart kubernetes yaml’a benzer şekildedir. Sadece değiştirmek istediğimiz alanları vermemiz yetiyor.

Örnekle biraz daha iyi anlayalım.

patches:
  - patch: |-
      apiVersion: apps/v1
      kind: Deployment
      metadata:
        name: web-deployment
      spec:
        replicas: 5

Patch From File

Her iki patch türünü de kustomization.yaml üzerinden kullanmak yerine farklı dosya üzerinden de ayrı bir şekilde yapıldırabiliriz. Biraz daha iyi açıklamak gerekirse; kustomization.yaml dosyamızda patches yapılandırmamızın bulunduğu patches dosya yolunu verip, tüm patches yapılandırmalarınızı ilgili verdiğimiz dosyaya yazıp işlemi aynı şekilde tamamlayabiliriz.

Örnekle biraz daha iyi kavrayalım.

Kustomization.yaml dosyamız aşağıdaki gibi olsun.

patches:
- path: replicas.yaml

Replicas.yaml dosyamızda aşağıdaki gibi olsun.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-deployment
spec:
  replicas: 5

Artık tüm temel Kustomize kavramlarını iyi anladığımıza göre, öğrendiklerimizi uygulamalı bir şekilde görelim.

Kustomize Kullanarak Uygulama Deploy Etmek

Şimdi, Kustomize’nin farklı ortamları içeren gerçek dünya dağıtım senaryosunu kullanarak nasıl çalıştığını görelim.

O halde bir senaryo oluşturalım.

• Nginx web server dev ve prod’da deploy edilmesi gerekiyor
• Dev’de yalnızca 2 replica, bir Nodeport service, daha az ram ve CPU kaynağı içeren bir deploy’a ihtiyacımız var.
• Prod’da, 4 replica, farklı CPU ve bellek limitleri, bir rolling update strategy ve Nodeport’suz bir service içeren bir deploy’a ihtiyacımız var.

Bunu Kustomize kullanarak nasıl kurgulayabileceğimize bakalım.

Kullandığım tüm manifestler bu github reposundadır. Dilerseniz doğrudan bakabilirsiniz.

Dizin yapımız aşağıdaki gibidir;

├── kustomize
  ├── base
    │   ├── deployment.yaml
    │   ├── service.yaml
    │   ├── kustomization.yaml
    └ overlays
        ├── dev
        │   ├── deployment-dev.yaml
        |   ├── service-dev.yaml
        │   └── kustomization.yaml
        └── prod
            ├── deployment-prod.yaml
            ├── service-prod.yaml
            └── kustomization.yaml

GitHub repo dosyalarını referans olarak kullanabilir veya aşağıdaki komutları kullanarak ilgili klasörleri ve dosyaları oluşturabilirsiniz:

mkdir -p kustomize/base && 
    touch kustomize/base/deployment.yaml \
         kustomize/base/service.yaml \
         kustomize/base/kustomization.yaml && 
    mkdir -p kustomize/overlays/dev && 
    touch kustomize/overlays/dev/deployment-dev.yaml \
         kustomize/overlays/dev/service-dev.yaml \
         kustomize/overlays/dev/kustomization.yaml && 
    mkdir -p kustomize/overlays/prod && 
    touch kustomize/overlays/prod/deployment-prod.yaml \
         kustomize/overlays/prod/service-prod.yaml \
         kustomize/overlays/prod/kustomization.yaml

Base klasöründen anlatıma başlayalım.

Base Klasörü

Base klasörü deployment, service ve kustomization dosyalarını içerir. Base klasörü içerisinde biz ortak olarak kullanacağımız deployment, service veya diğer yaml dosyalarımızı tutuyoruz.

base/deployment.yaml

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

base/service.yaml

apiVersion: v1
  kind: Service
  metadata:
    name: web-service
  spec:
    selector:
      app: web
    ports:
    - name: http
      port: 80

base/kustomization.yaml

Bu dosyamızda deployment.yaml dosyamızı ve service.yaml dosyamızı referans olarak gösteriyoruz. Diyoruz ki kardeşim sen git base olarak bu 2 dosyayı kullan 🙂

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

Dev Overlay Klasörü

Senaryomuza göre bu env ‘da sadece deployment.yaml dosyamızı değiştireceğiz.

deployment-dev.yaml

Dev ortamında sadece replica sayısını 1 den 2 ye çıkartmak istiyoruz. Gördüğünüz gibi sadece değişiklikleri tanımlıyoruz, diğer base dosyasındaki yaml değerlerimizi tekrardan tanımlamıyoruz. Kustomize, base deployment dosyasını kontrol edecek ve onu devde oluşturduğumuz deployment.yaml ile karşılaştırıpdeğişiklikleri buna göre yamalayacaktır.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-deployment
spec:
  replicas: 3 # Update the replica count to 3
  template:
    spec:
      containers:
      - name: nginx
        resources:
          limits:
            cpu: "200" # Lower CPU limit to 200m (0.2 CPU cores)
            memory: "256Mi" # Lower memory limit to 256 MiB
          requests:
            cpu: "100" # Lower CPU request to 100m (0.1 CPU cores)
            memory: "128Mi"

service-dev.yaml

Dev ortamı için yine bizim bir NodePort olan service’e ihtiyacımız var. Bu nedenle NodePort tipinde bir overlay oluşturacağız.

apiVersion: v1
kind: Service
metadata:
  name: web-service
spec:
  type: NodePort

kustomization.yaml

Bu dosyamızda Stragetic Merge Patching yöntemini file ile patch yolu göstererek kullanacağız. Ayrıca bu dosyamızda base klasörümüzü resouces altında belirtmemiz gerekecek.

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

resources:
- ../../base

patches:
- path: deployment-dev.yaml
- path: service-dev.yaml

İnceleme & Patches Uygulama

Yazdığımız yamaları gözden geçirelim. Yamaları incelemek ve her şeyin doğru olup olmadığını kontrol etmek için aşağıdaki komutu kullanabiliriz.

kustomize build overlays/dev

Bu komuttan sonra aşağıdaki resimdeki gibi kubernetes manifestleriniz oluşmuş olacak.

Gördüğünüz gibi, deploymenttaki replica sayısı 2’ye yükseldi ve farklı CPU, bellek kaynakları ve service türü NodePort olarak değiştirildi. Bu dev ortamı için senaryomuzdu.

Aşağıdaki komutu kullanarak çıkan manifestleri doğrudan kubernetes üzerinde ayağa kaldırabilirsiniz.

kustomize build overlays/dev | kubectl apply -f -

Veya manifestlerinizi kustomize build komutundan sonra oluştuğunda aşağıdaki komut ile doğrudan kubernetes üzerinde folder’ın içerisindeki tüm manifestleri ayağa kaldırabilirsiniz.

kubectl apply -k overlays/dev

Prod Overlay Klasörü

deployment-prod.yaml

Prod deployment’ında, deployun 4 replicası ve farklı bellek ve CPU kaynakları ile RollingUpdate stratejisi ile çalışmasını istiyoruz.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-deployment
spec:
  template:
    replicas: 4 # Update the replica count to 3
    spec:
      containers:
      - name: nginx
        resources:
          limits:
            cpu: "1" # Lower CPU limit to 200m (0.2 CPU cores)
            memory: "1Gi" # Lower memory limit to 256 MiB
          requests:
            cpu: "500" # Lower CPU request to 100m (0.1 CPU cores)
            memory: "512Mi" # Lower memory request to 128 MiB
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1

service-prod.yaml

Service türünü NodePort olarak değiştiriyoruz.

apiVersion: v1
kind: Service
metadata:
  name: web-service
spec:
  type: NodePort

kustomization.yaml

Prod bazlı değişiklikler yapmak istediğimiz için, kustomization.yaml’de her iki dosyanın da yama için mutlak yolunu ekledim.

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

resources:
- ../../base

patches:
- path: deployment-prod.yaml
- path: service-prod.yaml

Yapılandırmayı ve yamaları gözden geçirmek için aşağıdaki komutu tekrar çalıştırın.

kustomize build overlays/prod

Alternatif olarak Kustomize kubectl komutu ile aşağıdaki gibi kullanabilirsiniz.

kubectl kustomize overlays/prod

İnceleme & Patches Uygulama

Her şey yolunda görünüyorsa, aşağıdaki komutu çalıştırarak deploy’u yapabiliriz.

kustomize build overlays/prod | kubectl apply -f -

Alternatif olarak kubectl komutunu aşağıdaki gibi kullanabilirsiniz.

kubectl apply -k overlays/prod

Deploy ettikten sonra aşağıdaki komutları çalıştırarak kubernetes nesnelerini kontrol edebiliriz.

kubectl get deployments
kubectl get services
kubectl get pods

Tüm kubernetes nesnelerini aynı anda görüntülemek için aşağıdaki komutu kullanabilirsiniz.

kubectl get all

Kustomize ile ilgili daha önce yazdığım bu linkteki yazıyı da okumanızı tavsiye ederim.