Blog

Kubectl Kustomize Eklentisi - Nedir, Nereden Başlanır ?

Eğer Kubernetes kümeleri yöneten bir sistem yöneticisi iseniz muhtemelen kustomize eklentisini duymuşsunuzdur. Büyük Kubernetes ortamları yönetiyor ve uygulama sayınız sürekli olarak artıyor ise zaten devops süreçleri ile çoktan haşır neşir oluyorsunuzdur. Belki Helm template gibi daha ileri seviye deployment yöntemlerini takip ediyorsunuz. Bu makalede kubectl eklentisi olan kustomize aracından bahsetmeye çalışacağız. Başlangıç seviyesinde bir yazı olacak ve kustomize eklentisinin hangi tip problemleri çözmek için uygun olduğundan bahsedeceğiz.

Gereksinimler

Kubectl aracına sahip olan bir client makine.

Manifestoları uygulayacağımız bir kubernetes cluster.(minikube, kind,vb..)

Kustomize Nedir ?

En basit tanımı ile Kustomize bir kubectl eklentisidir. Template mantığına benzese de ondan farklı olarak Overlay ve Patch mantığı kullanarak manifestolarınızı yönetmenizi sağlar. Ana dayanağı farklı farklı yaml dosyalarını bir araya getirip ortak kullanım oluşturarak yönetilen manifesto sayısını azaltmak ve yaml dosyalarınızı sadeleştirmektir. Ek bir kurulum gerektirmez kubectl aracı içerisinde eklenti olarak gelir. En önemli faydası farklı ortamlar(dev/test/prod..) için ayrı ayrı manifesto geliştirmenizin önüne geçerek ana konfigurasyon dosyalarınızla birden fazla ortama tutarlı bir şekilde deployment yapabilmenizi sağlamasıdır.

Örnek Bir Kustomize Dizininin Anatomisi

Bir kustomize dizinine baktığımız aşağı yukarı benzer bir dizin yapısı görürüz. Bu makalede aşağıdaki gibi bir dizin yapısı üzerinden ilerleyeceğiz. Bu dizin yapısı bize yönetim kolaylığı sağlıyor olacak.

tree
.
├── base
│   ├── example-main.yaml
│   └── kustomization.yaml
└── overlays
    ├── prod
    │   ├── example-prod.yaml
    │   └── kustomization.yaml
    └── test
        ├── example-test.yaml
        └── kustomization.yaml

Base Layer

Ana konfigurasyon dosyalarımız bu dizinde olacak. Tüm ortamlar için ortak olmasını istediğimiz bilgileri buraya ekliyoruz. Overlay ortamlar bu dizini referans göstererek buradaki konfigurasyonları kullanabilecekler. Örnek olarak deployment objesini barındırabilir.

Overlays

Bu dizin altında farklı ortamlar için değişiklik gösterecek olan bilgileri ekleyeceğiz.

İçerisinde ana konfigürasyonlardan faydalanabilecek ortamlar bulunduracağız. Bir uygulama için bu geliştirme,test ve üretim ortamı gibi dizinler olabilir. Daha farklı amaçlar için de kullanılabilir.

Örnek olarak deployment objesinde farklı ortamlar için yapmak istediğimiz değişiklikleri burada belirleyebiliriz. Deployment objemiz için replike sayısının test ve prod ortamlarda farklılaştırılması gibi.

Patches ve Generators Kullanımı

Kustomize eklentisinin içerisinde ana yaml dosyalarını düzenlemekte kullanabileceğimiz patch ve generator gibi bileşenler de barınıyor. Bunları kullanarak ana yaml dosyalarında değişiklik yapabilir ya da basit dosyalarla configmap ve secret objeleri oluşturtabiliriz bunları çalışma zamanında ilgili kümeye uygulayabiliriz.

Bunlara örnek deployment objesi için bu replika sayısını değiştirmek, imaj tag bilgisini değiştirmek olabilir.

Bu sayede daha az yaml manifestosu yazarak json yama yöntemi ile farklı ortamlarımıza uygun konfigurasyonları kolay ve anlaşılabilir bir biçimde oluşturabileceğiz.

Daha detaylı bir şekilde patch ve generator özelliklerine de değineceğiz.

kustomization.yaml

Fark ettiyseniz bu dizin yapısında her alt dizinde aynı dosya ismiyle bir dosya barınıyor.

kustomization.yaml dosyası içerisine girdiğimiz tanımlar kustomize eklentisini tetikliyor. Bu sayede ilgili kustomization dosyasındaki tarife göre yeni yaml dosyaları oluşuyor.

Örnek bir kustomization dosyası içeriği şu şekilde:

Her kustomization dosyasında olmazsa olmaz resources bölümü yer alıyor. Bu bölüm sayesinde biz hangi yaml dosyalarının oluşacak son yaml dosyası içerisinde bulunacağına karar veriyoruz.

resources:
- deployment.yaml
secretGenerator:
- name: example-secret-1
  files:
  - password.txt

Buraya kadar teorik bilgimizi verdik. Şimdi de örnek bir deployment objemizin replika sayısını farklı ortamlar için nasıl özelleştirebiliriz onu görelim.

Öncelikle dizin yapımızı oluşturalım.

$ mkdir base
$ mkdir -p overlays/{test,prod}

$ cat << 'EOF' > base/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: gantek-deployment
  labels:
    app: gantek-app
spec:
  replicas: 1 # Default replica count
  selector:
    matchLabels:
      app: gantek-app
  template:
    metadata:
      labels:
        app: gantek-app
    spec:
      containers:
      - name: gantek-container
        image: nginx:latest
        ports:
        - containerPort: 80
EOF

$ cat << 'EOF' > base/kustomization.yaml
resources:
  - deployment.yaml
EOF

$ cat << 'EOF' > overlays/test/replica-patch-test.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: gantek-deployment
spec:
  replicas: 2 # Test environment uses 2 replicas
EOF

$ cat << 'EOF' > overlays/test/kustomization.yaml
resources:
  - ../../base
patches:
- path: replica-patch-test.yaml
  target:
    kind: Deployment
    name: gantek-deployment
EOF

$ cat << 'EOF' > overlays/prod/replica-patch-prod.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: gantek-deployment
spec:
  replicas: 5 # Production environment uses 5 replicas
EOF

$ cat << 'EOF' > overlays/prod/kustomization.yaml
resources:
  - ../../base
patches:
- path: replica-patch-prod.yaml
  target:
    kind: Deployment
    name: gantek-deployment
EOF

$ tree
.
├── base
│   ├── deployment.yaml
│   └── kustomization.yaml
└── overlays
    ├── prod
    │   ├── kustomization.yaml
    │   └── replica-patch-prod.yaml
    └── test
        ├── kustomization.yaml
        └── replica-patch-test.yaml

Tüm komutlar sonrası dizin yapımız yukarıdaki gibi olacak. Ana deployment dosyamızda normalde replika sayımız bir. Biz bunu overlay dizinlerindeki patch komutları sayesinde ortama özel değiştirmeyi hedefledik. Test için oluşacak yaml iki, prod için oluşacak yaml için bu değer beş olmalı. Aşağıdaki komutları ilgili dizinlerde çalıştıralım ve oluşan yaml dosyalarını inceleyelim.

$ cd overlays/test
$ oc kustomize .

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: gantek-app
  name: gantek-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
      app: gantek-app
  template:
    metadata:
      labels:
        app: gantek-app
    spec:
      containers:
      - image: nginx:latest
        name: gantek-container
        ports:
        - containerPort: 80
        
$ cd overlays/prod
$ oc kustomize .

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

Bu basit örnekte kustomize eklentisi kullanarak ortam spesifik manifesto dosyalarımızı nasıl kolaylıkla özelleştirebileceğimizi gördük. Bu basit bir örnek ancak kustomize konusunun iyi anlaşılabilmesi için önemli.

Sonuç

Sonuç olarak Kustomize konfigurasyon yönetimini basitleştiren bir araç olarak manifesto yönetim işini epey kolaylaştırıyor . Manifesto karmaşasını ortadan kaldırarak ve temel yaml dosyaları üzerinde hem hata oranınızı azaltabilirsiniz hem de farklı ortamlar arasındaki değişiklikleri kolay bir şekilde ayırt edebilirsiniz. Konfigürasyon tekrarını ortadan kaldırmak, özellikle ölçek büyüdükçe teknik borcu azaltmanın en önemli adımlarından biridir.

Eğer ortamınızda Kubernetes veya OpenShift kullanıyor, uygulama veya cluster konfigurasyon yaml dosyalarınızı yönetmekte zorlanıyorsanız gelin birlikte çalışalım ve bu karmaşayı yönetilebilir kılalım.