Kubernetes Kümelerinde Yazılımı Helm 2 Paket Yöneticisi ile Kurma

Kubernetes Kümelerinde Yazılımı Helm 2 Paket Yöneticisi ile Kurma

Kubernetes, konteynerize edilmiş uygulamaları dağıtmak, ölçeklendirmek ve yönetmek için güçlü bir platform sunar. Ancak, Kubernetes manifest dosyalarının (Deployment, Service, Ingress, ConfigMap vb.) sayısı ve karmaşıklığı arttıkça, uygulamaların dağıtımı ve yönetimi zorlaşabilir. Özellikle birden fazla ortamda (geliştirme, test, üretim) tutarlı dağıtımlar sağlamak, bağımlılıkları yönetmek ve uygulama yaşam döngüsünü (kurulum, yükseltme, geri alma, silme) kontrol etmek büyük bir meydan okuma haline gelir. İşte tam bu noktada Helm devreye girer.

Helm, Kubernetes için bir paket yöneticisidir. Linux dağıtımlarında apt, yum veya brew ne ise, Kubernetes için de Helm odur. Helm, Kubernetes uygulamalarını paketlemek, dağıtmak ve yönetmek için standart bir yöntem sunar. Bu makalede, Helm’in ikinci büyük sürümü olan Helm 2’ye odaklanacağız. Helm 3 daha güncel ve güvenlik açısından daha gelişmiş olsa da, dünya genelinde hala birçok eski sistem ve proje Helm 2 kullanmaya devam etmektedir. Bu nedenle, Helm 2’yi anlamak ve onunla çalışabilmek, mevcut Kubernetes altyapılarıyla ilgilenen geliştiriciler ve operasyon ekipleri için kritik bir beceridir.

Helm Nedir ve Neden Kullanılır?

Helm, Kubernetes uygulamalarını “Chart” adı verilen paketler halinde gruplandırarak, bu uygulamaların dağıtımını ve yönetimini kolaylaştırır. Bir Chart, bir uygulamanın veya hizmetin Kubernetes’te çalışması için gereken tüm kaynakları (manifest dosyaları, yapılandırma, bağımlılıklar vb.) içeren bir koleksiyondur.

Helm’in temel bileşenleri şunlardır:

* Helm CLI (Client): Geliştiricilerin ve operatörlerin Chart’ları oluşturmak, yönetmek, depolamak ve Kubernetes kümelerine dağıtmak için kullandığı komut satırı aracıdır.
* Tiller (Server): Helm 2’ye özgü bir bileşendir. Kubernetes kümesi içinde çalışan bir sunucu tarafı bileşenidir. Helm CLI’dan gelen komutları alır, Chart’ları işler ve Kubernetes API’si aracılığıyla kaynakları oluşturur/günceller/siler. Tiller, release’lerin (yüklenmiş Chart örnekleri) durumunu ve geçmişini de yönetir.
* Chart: Bir Kubernetes uygulamasını tanımlayan ve Helm tarafından yönetilen bir pakettir. Bir Chart, uygulamanın tüm Kubernetes manifestlerini, yapılandırma dosyalarını, şablonları ve bağımlılıklarını içerir.
* Repository: Helm Chart’larının depolandığı ve paylaşıldığı yerdir. Genellikle bir HTTP sunucusu olarak çalışır ve Chart’ları indeksler.
* Release: Bir Kubernetes kümesine yüklenmiş bir Chart’ın belirli bir örneğidir. Her release benzersiz bir ada sahiptir ve Helm tarafından izlenir.

Helm kullanmanın başlıca avantajları şunlardır:

* Uygulama Yaşam Döngüsü Yönetimi: Uygulamaları tek bir komutla kurabilir, yükseltebilir, geri alabilir ve silebilirsiniz. Bu, karmaşık çoklu mikro hizmet uygulamaları için özellikle değerlidir.
* Yeniden Kullanılabilirlik ve Paylaşılabilirlik: Bir kez oluşturulan Chart’lar, farklı ekipler veya projeler arasında kolayca paylaşılabilir ve yeniden kullanılabilir. Bu, standartlaştırılmış dağıtımlar sağlar.
* Basitleştirilmiş Karmaşık Dağıtımlar: Helm Chart’ları, birden fazla Kubernetes kaynağını (Deployment, Service, PersistentVolumeClaim, Ingress vb.) tek bir mantıksal birim altında birleştirerek karmaşık uygulamaların dağıtımını basitleştirir.
* Ortamlar Arası Tutarlılık: Geliştirme, test ve üretim gibi farklı ortamlarda aynı Chart’ı farklı yapılandırma değerleriyle kullanarak tutarlı dağıtımlar sağlayabilirsiniz.
* Bağımlılık Yönetimi: Bir uygulamanın birden fazla alt bileşene veya başka uygulamalara bağımlılığı varsa, Helm bu bağımlılıkları kolayca yönetebilir.
* Şablonlama (Templating): Chart’lar, Go şablonlama dilini kullanarak dinamik değerler ve koşullu mantık içerebilir. Bu, Chart’ların farklı ortamlar veya kullanım durumları için özelleştirilmesini sağlar.

Helm 2 ve Helm 3 Arasındaki Temel Farklar

Helm 2, Kubernetes ekosistemine paket yönetimini getirerek büyük bir boşluğu doldurmuş olsa da, özellikle güvenlik ve mimari açısından bazı eleştiriler almıştır. Helm 3, bu sorunları gidermek ve daha modern bir yaklaşım sunmak üzere tasarlanmıştır. Helm 2 ve Helm 3 arasındaki temel farkları anlamak, neden hala Helm 2’ye ihtiyaç duyulabileceğini veya neden Helm 3’e geçişin teşvik edildiğini kavramak açısından önemlidir.

* Tiller Bileşeni:
* Helm 2: En büyük fark, Helm 2’nin Kubernetes kümesi içinde çalışan bir sunucu tarafı bileşeni olan Tiller’a sahip olmasıdır. Tiller, Chart’ları yorumlar, Kubernetes API’si ile etkileşime girer ve release’leri yönetir.
* Helm 3: Tiller tamamen kaldırılmıştır. Helm 3 CLI, doğrudan Kubernetes API’si ile etkileşime girer. Bu, mimariyi basitleştirir ve güvenlik risklerini azaltır.
* Güvenlik:
* Helm 2: Tiller’ın kümede çalışması, genellikle küme yöneticisi (cluster-admin) yetkilerine sahip olması gerektiği anlamına geliyordu. Bu durum, Tiller’ın ele geçirilmesi durumunda tüm kümeye erişim sağlanabileceği ciddi bir güvenlik açığı oluşturuyordu. RBAC (Role-Based Access Control) ile Tiller’a daha kısıtlı yetkiler vermek mümkün olsa da, yapılandırması karmaşıktı ve çoğu zaman göz ardı ediliyordu.
* Helm 3: Tiller’ın olmaması nedeniyle bu güvenlik endişeleri ortadan kalkmıştır. Helm 3, kullanıcıların kubectl için sahip olduğu yetkileri kullanır. Bu, Helm operasyonlarının, kullanıcının Kubernetes RBAC izinleriyle sınırlı olduğu anlamına gelir.
* Release Yönetimi:
* Helm 2: Release bilgilerini ve geçmişini Kubernetes ConfigMaps içinde saklardı.
* Helm 3: Release bilgilerini Secrets içinde saklar. Bu, hassas bilgilerin daha güvenli bir şekilde saklanmasını sağlar.
* Chart API Sürümü:
* Helm 2: Chart.yaml dosyalarında apiVersion: v1 kullanır.
* Helm 3: Chart.yaml dosyalarında apiVersion: v2 kullanır ve bazı metadata alanlarında değişiklikler yapılmıştır.
* Namespace Desteği:
* Helm 2: helm install komutu varsayılan olarak Tiller’ın çalıştığı namespace’e yüklerdi veya --namespace ile belirtilen namespace’e yükleyebilirdi. Ancak, release’ler genellikle küme genelinde izleniyordu.
* Helm 3: Release’ler artık belirli bir namespace’e bağlıdır ve release adları namespace içinde benzersiz olmak zorundadır.
* Bağımlılık Yönetimi:
* Helm 2: requirements.yaml dosyası kullanılırdı.
* Helm 3: Chart.yaml dosyası içindeki dependencies alanı kullanılarak bağımlılıklar yönetilir.

Helm 2’nin hala öğrenilmesi veya kullanılması gereken durumlar şunlardır:

* Mevcut Eski Projeler: Birçok şirket ve proje, Helm 3’e geçiş yapmamış veya yapmayı planlamayan eski Kubernetes kümelerinde Helm 2 kullanmaya devam etmektedir.
* Belirli Ortam Kısıtlamaları: Nadiren de olsa, belirli kurumsal veya güvenlik politikaları Helm 3’ün getirdiği değişikliklerle uyumlu olmayabilir (ancak bu çok istisnai bir durumdur).
* Anlayış Geliştirme: Helm’in evrimini ve Tiller gibi bir bileşenin neden var olduğunu anlamak, Kubernetes paket yönetiminin derinlemesine kavranmasına yardımcı olabilir.

Bu makalenin geri kalanında, Helm 2’nin kurulumu, yapılandırması ve kullanımı detaylı olarak ele alınacaktır.

Ön Koşullar

Helm 2 ile Kubernetes kümelerinde yazılım kurmaya başlamadan önce aşağıdaki ön koşulların yerine getirildiğinden emin olmalısınız:

1. Kubernetes Kümesi: Çalışır durumda bir Kubernetes kümesine sahip olmalısınız. Bu bir yerel geliştirme kümesi (Minikube, Kind, Docker Desktop’taki Kubernetes), bir bulut sağlayıcısı kümesi (Google Kubernetes Engine (GKE), Amazon Elastic Kubernetes Service (EKS), Azure Kubernetes Service (AKS)) veya kendi barındırdığınız bir küme olabilir.
2. kubectl Yüklü ve Yapılandırılmış: Kubernetes kümenizle etkileşim kurmak için kubectl komut satırı aracı yüklü ve doğru şekilde yapılandırılmış olmalıdır. kubectl get nodes komutunu çalıştırdığınızda kümenizdeki düğümleri görebilmelisiniz.
3. İnternet Bağlantısı: Helm Chart depolarına erişmek ve Docker imajlarını çekmek için internet bağlantısı gereklidir.

Helm 2 Kurulumu

Helm 2’yi kullanmak için hem Helm CLI’yı yerel makinenize kurmanız hem de Kubernetes kümenize Tiller’ı dağıtmanız gerekir.

Helm CLI Kurulumu

Helm CLI, Chart’ları yönetmek ve Tiller ile iletişim kurmak için kullanılır.

Linux ve macOS için:

* Homebrew (macOS için önerilir):

brew install helm@2

Not: helm@2 paketi, Helm 2’yi kurar. Eğer helm yazarsanız Helm 3’ü kuracaktır. Helm 2’yi kurduktan sonra helm komutunu kullanmak için genellikle sembolik bir bağlantı oluşturulur veya PATH’e eklenir. Eğer hem Helm 2 hem de Helm 3’ü aynı anda kullanmak isterseniz, Helm 2 için helm2 gibi bir alias veya farklı bir PATH ayarı yapmanız gerekebilir. Bu makale boyunca helm komutunun Helm 2’yi işaret ettiğini varsayacağız.

* curl Script ile:

curl https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3 | sed 's/get_latest_version/get_stable_version/g' | bash
    # Bu script varsayılan olarak Helm 3'ü indirir. Helm 2'yi indirmek için aşağıdaki gibi belirli bir sürümü belirtmeniz gerekebilir:
    curl -L https://git.io/get_helm.sh | bash -s -- --version v2.16.1 --no-sudo

v2.16.1 yerine istediğiniz Helm 2 sürümünü yazabilirsiniz. get_helm.sh scripti artık Helm 3’ü varsayılan olarak indirdiği için Helm 2 için özel bir sürüm belirtmek önemlidir.

Windows için:

* Chocolatey (önerilir):

choco install kubernetes-helm --version 2.16.1

Yine, 2.16.1 yerine istediğiniz Helm 2 sürümünü belirtmelisiniz. Varsayılan olarak Helm 3 yüklenebilir.

* Scoop:

scoop install helm@2

* İkili İndirme:
Helm’in GitHub releases sayfasından (https://github.com/helm/helm/releases) istediğiniz Helm 2 sürümünün (örneğin helm-v2.16.1-windows-amd64.zip) ikili dosyasını indirin. İçindeki helm.exe dosyasını sistem PATH’inize ekli bir dizine (örneğin C:\Program Files\Helm) kopyalayın.

Kurulumu Doğrulama:
Helm CLI’nın doğru yüklendiğinden emin olmak için aşağıdaki komutu çalıştırın:

helm version --client

Çıktıda Client: &version.Version{SemVer:"v2.x.x", ...} gibi bir ifade görmelisiniz.

Tiller Kurulumu

Helm 2’nin çalışması için Kubernetes kümenizde Tiller’ın yüklü olması gerekir. Tiller, varsayılan olarak kube-system namespace’inde çalışır. Ancak güvenlik nedeniyle, Tiller’a küme yöneticisi yetkileri vermek yerine, ona özel bir ServiceAccount ve kısıtlı ClusterRoleBinding atamak en iyi uygulamadır.

1. Tiller için ServiceAccount ve ClusterRoleBinding Oluşturma:

Tiller’a yalnızca ihtiyacı olan yetkileri vermek için bir ServiceAccount ve ona bağlı bir ClusterRoleBinding oluşturacağız. Bu, Tiller’ın küme genelinde herhangi bir kaynağı oluşturmasına, güncellemesine ve silmesine izin veren cluster-admin rolünü atar. Gerçek bir üretim ortamında, bu yetkileri daha da kısıtlamayı düşünebilirsiniz.

tiller-rbac.yaml adında bir dosya oluşturun:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: tiller
  namespace: kube-system # Tiller'ın çalışacağı namespace
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: tiller-cluster-rule
subjects:
  - kind: ServiceAccount
    name: tiller
    namespace: kube-system
roleRef:
  kind: ClusterRole
  name: cluster-admin # Tiller'a cluster-admin yetkileri veriyoruz
  apiGroup: rbac.authorization.k8s.io

Bu dosyayı kümenize uygulayın:

kubectl apply -f tiller-rbac.yaml

2. Tiller’ı Kurma:

Şimdi Helm CLI’yı kullanarak Tiller’ı kümenize kurabilirsiniz. --service-account tiller parametresi, Tiller’ın yukarıda oluşturduğumuz tiller ServiceAccount’ını kullanmasını sağlar. --history-max ise release geçmişi için tutulacak revizyon sayısını belirler.

helm init --service-account tiller --history-max 20

Bu komut, Tiller’ı kube-system namespace’ine dağıtacak ve varsayılan Helm Chart deposunu (stable) ekleyecektir.

3. Tiller Kurulumunu Doğrulama:

Tiller’ın başarıyla kurulduğunu ve çalıştığını kontrol etmek için aşağıdaki komutları kullanabilirsiniz:

kubectl get pods -n kube-system -l app=helm

Çıktıda tiller-deploy-xxxxxxxxxx-xxxxx gibi bir pod görmelisiniz ve durumu Running olmalıdır.

Ardından, Helm CLI’nın Tiller ile iletişim kurabildiğini doğrulamak için:

helm version

Bu komutun çıktısında hem Client hem de Server (Tiller) versiyon bilgilerini görmelisiniz. Eğer sadece Client versiyonunu görüyorsanız veya Error: ... mesajı alıyorsanız, Tiller kurulumunda bir sorun var demektir.

Helm Chart’ları Anlamak

Helm Chart’ları, Kubernetes uygulamalarını paketlemenin temel birimidir. Bir Chart’ın yapısını ve nasıl çalıştığını anlamak, uygulamaları etkili bir şekilde dağıtmak ve yönetmek için kritik öneme sahiptir.

Chart Yapısı

Bir Chart, belirli bir dizin yapısına sahiptir:

my-app/
  Chart.yaml          # Chart hakkında meta bilgiler
  values.yaml         # Chart için varsayılan yapılandırma değerleri
  charts/             # Bağımlı Chart'lar
  templates/          # Kubernetes manifest şablonları
    deployment.yaml
    service.yaml
    ingress.yaml
    _helpers.tpl      # Yeniden kullanılabilir şablon parçacıkları
  NOTES.txt           # Kurulum sonrası bilgiler

* Chart.yaml: Chart’ın adı, versiyonu, açıklaması, API versiyonu (v1 for Helm 2), maintainer bilgileri ve bağımlılıklar gibi meta verilerini içerir.

apiVersion: v1
    name: my-app
    version: 0.1.0
    appVersion: "1.0"
    description: A Helm chart for my application.

* values.yaml: Chart’ın dağıtım sırasında özelleştirilebilen varsayılan yapılandırma değerlerini içerir. Bu değerler, templates/ dizinindeki şablonlarda kullanılır.

replicaCount: 1
    image:
      repository: nginx
      tag: stable
      pullPolicy: IfNotPresent
    service:
      type: ClusterIP
      port: 80

* templates/: Bu dizin, Kubernetes kaynak manifestlerinin şablonlarını içerir. Helm, bu şablonları values.yaml‘daki değerlerle birleştirerek nihai Kubernetes manifestlerini oluşturur.
* _helpers.tpl: Genellikle sık kullanılan fonksiyonları, etiketleri veya adlandırma mantığını içeren yardımcı şablonları barındırır. Bu dosyalar doğrudan Kubernetes’e gönderilmez.
* charts/: Eğer Chart’ınız başka Chart’lara bağımlıysa (örneğin, bir uygulama MySQL veritabanına ihtiyaç duyuyorsa ve MySQL için ayrı bir Chart varsa), bu bağımlı Chart’lar buraya yerleştirilebilir. Bağımlılıklar Chart.yaml dosyasında da belirtilir ve helm dependency update ile indirilir.
* NOTES.txt: Chart başarıyla kurulduktan sonra kullanıcıya gösterilen bilgilendirme mesajlarını içerir. Bu genellikle uygulamanın nasıl erişileceği veya sonraki adımlar hakkında talimatlar içerir.

Şablonlama (Templating)

Helm’in gücünün büyük bir kısmı, Go şablonlama dilini kullanarak Kubernetes manifestlerini dinamik olarak oluşturma yeteneğinden gelir. templates/ dizinindeki dosyalar aslında Go şablonlarıdır.

* Değerleri Kullanma: values.yaml dosyasındaki değerlere {{ .Values.anahtar.altanahtar }} syntax’ı ile erişilir. Örneğin, values.yaml‘daki replicaCount: 1 değerine {{ .Values.replicaCount }} ile erişilir.
* Yerleşik Fonksiyonlar ve Borular (Pipes): Helm, şablonlarda kullanılabilecek birçok yerleşik fonksiyon sunar (örneğin, quote, default, indent). Borular (|) ile bu fonksiyonlar zincirlenebilir.

# Örnek: values.yaml'daki image.tag değerini al ve tırnak içine al
    image: "{{ .Values.image.repository }}:{{ .Values.image.tag | quote }}"

* Koşullu Mantık (if/else): Belirli koşullara bağlı olarak kaynakların oluşturulmasını veya değerlerin ayarlanmasını sağlar.

{{ if .Values.ingress.enabled }}
    apiVersion: networking.k8s.io/v1
    kind: Ingress
    # ... Ingress tanımı ...
    {{ end }}

* Döngüler (range): Bir liste veya harita üzerindeki öğeleri yinelemek için kullanılır.

# Örnek: Birden fazla container portunu tanımlama
    ports:
    {{- range .Values.service.ports }}
      - name: {{ .name }}
        port: {{ .port }}
        targetPort: {{ .targetPort }}
    {{- end }}

Bağımlılıklar

Bir Chart, başka Chart’lara bağımlı olabilir. Bu bağımlılıklar, Chart.yaml dosyasında dependencies bölümünde belirtilir:

apiVersion: v1
name: my-app
version: 0.1.0
dependencies:
  - name: mysql
    version: 8.x.x
    repository: "https://charts.bitnami.com/bitnami" # Veya başka bir depo
    condition: mysql.enabled # Sadece mysql.enabled true ise yükle

Bağımlılıkları indirmek ve güncellemek için:

helm dependency update my-app/ # veya Chart dizinindeyken 'helm dependency update .'

Uygulama Yükleme (Release Oluşturma)

Helm ile bir uygulamayı Kubernetes kümenize yüklemek, bir Chart’tan bir “release” oluşturmak anlamına gelir.

Chart Bulma

Helm Chart’larını bulmanın birkaç yolu vardır:

* Helm Hub (eski): Helm Hub, çeşitli Chart depolarından Chart’ları aramak için merkezi bir yerdi. Artık yerini büyük ölçüde Artifact Hub’a bırakmıştır.
* Artifact Hub: Hem Helm 2 hem de Helm 3 Chart’ları için popüler bir Chart deposu ve arama motorudur.
* Resmi Helm Chart Depoları: Geçmişte stable ve incubator gibi resmi depolar vardı, ancak bunlar arşivlenmiştir. Artık çoğu Chart sağlayıcının kendi deposu bulunmaktadır (örneğin Bitnami, Prometheus).
* Özel Depolar: Kendi özel Chart depolarınızı kurabilir veya başkalarının depolarını ekleyebilirsiniz.

helm repo add bitnami https://charts.bitnami.com/bitnami
    helm repo update # Depoları günceller
    helm search bitnami/nginx # Bitnami deposundaki Nginx Chart'ını arar

* Yerel Chart’lar: Kendi oluşturduğunuz veya indirdiğiniz Chart’ları doğrudan dosya sisteminden yükleyebilirsiniz.

Bir Chart Kurma

Bir Chart’ı kurmak için helm install komutu kullanılır. Bu komut bir Chart’ı alır, şablonları işler ve Kubernetes API’si aracılığıyla kaynakları kümenize dağıtır.

helm install [CHART_ADI | CHART_YOLU] --name [RELEASE_ADI] [OPSİYONLAR]

* [CHART_ADI | CHART_YOLU]: Kurulacak Chart’ın adı (örneğin stable/nginx-ingress) veya yerel dosya yolu (örneğin ./my-app).
* --name [RELEASE_ADI]: Bu release için benzersiz bir ad atar. Bu ad, release’i tanımlamak, yükseltmek veya silmek için kullanılır. Helm 2’de bu parametre zorunludur.
* --set: values.yaml dosyasındaki belirli değerleri komut satırından geçersiz kılmak için kullanılır. Birden fazla --set parametresi kullanılabilir.

helm install stable/nginx-ingress --name my-nginx --set controller.replicaCount=2,defaultBackend.enabled=false

* -f veya --values: Bir veya daha fazla özel values.yaml dosyasını belirtmek için kullanılır. Bu dosyalar, Chart’ın kendi values.yaml dosyasındaki değerleri geçersiz kılar.

helm install stable/mysql --name my-db -f my-custom-values.yaml

* --namespace: Release’in kurulacağı Kubernetes namespace’ini belirtir. Eğer belirtilmezse, Tiller’ın çalıştığı namespace’e veya kubectl‘ın varsayılan namespace’ine kurulabilir.
* --version: Chart’ın belirli bir sürümünü kurmak için kullanılır.

helm install stable/nginx-ingress --name my-nginx --version 1.24.3

Örnek: Nginx Kurulumu

Varsayılan stable deposu arşivlenmiş olsa da, çoğu Helm 2 kurulumunda hala yapılandırılmış olabilir. Bir örnek olarak stable/nginx-ingress Chart’ını kullanalım:

# Nginx Ingress Controller'ı kur
helm install stable/nginx-ingress --name my-nginx-ingress --namespace default \
  --set controller.replicaCount=2 \
  --set controller.service.type=NodePort \
  --set controller.publishService.enabled=true

Bu komut, my-nginx-ingress adında bir release oluşturacak, Nginx Ingress Controller’ı default namespace’ine 2 replika ile kuracak ve Service’i NodePort olarak ayarlayacaktır.

Release’leri Listeleme

Kümenizde yüklü olan tüm Helm release’lerini görmek için:

helm ls # veya helm list

Bu komut, release adını, Chart’ı, sürümünü, durumunu ve son güncelleme zamanını gösterir.

Release Bilgilerini Görüntüleme

Belirli bir release hakkında detaylı bilgi almak için:

helm status [RELEASE_ADI]

Bu komut, release’in durumunu, dağıtılan Kubernetes kaynaklarını, NOTES.txt içeriğini ve daha fazlasını gösterir.

Bir release için kullanılan değerleri görmek için:

helm get values [RELEASE_ADI]

Bir release tarafından dağıtılan tüm Kubernetes manifestlerini görmek için:

helm get manifest [RELEASE_ADI]

Uygulama Güncelleme ve Geri Alma

Helm, kurulu uygulamaların güncellenmesi ve gerekirse önceki bir sürüme geri alınması süreçlerini de kolaylaştırır.

Uygulama Güncelleme

Bir release’i güncellemek için helm upgrade komutu kullanılır. Bu, Chart’ın yeni bir sürümünü dağıtmak veya mevcut Chart’ın yapılandırma değerlerini değiştirmek için kullanılabilir.

helm upgrade [RELEASE_ADI] [CHART_ADI | CHART_YOLU] [OPSİYONLAR]

* [RELEASE_ADI]: Güncellenecek release’in adı.
* [CHART_ADI | CHART_YOLU]: Yeni Chart’ın adı veya yolu. Bu, aynı Chart’ın yeni bir sürümü veya tamamen farklı bir Chart olabilir (ancak genellikle aynı Chart’ın yeni sürümü tercih edilir).
* --set veya -f: Güncelleme sırasında yeni yapılandırma değerlerini geçersiz kılmak için kullanılır.

Örnek: Nginx Replikalarını Güncelleme

Yukarıda kurduğumuz my-nginx-ingress release’inin replika sayısını 2’den 3’e çıkarmak istediğimizi varsayalım:

helm upgrade my-nginx-ingress stable/nginx-ingress --set controller.replicaCount=3

Bu komut, my-nginx-ingress release’ini güncelleyecek ve Nginx Ingress Controller’ın replika sayısını 3’e çıkaracaktır. Helm, mevcut kaynakları akıllıca günceller (örneğin, Deployment’ı günceller, mevcut Pod’ları kapatıp yenilerini başlatır).

Geri Alma (Rollback)

Bir güncelleme sonrası sorun yaşandığında, Helm, uygulamayı önceki bir kararlı duruma geri almanızı sağlar. Her install ve upgrade işlemi bir revizyon numarası oluşturur.

Önceki revizyonları görmek için:

helm history [RELEASE_ADI]

Çıktıda, her bir revizyonun numarası, durumu ve açıklaması yer alır.

Bir release’i belirli bir revizyona geri almak için:

helm rollback [RELEASE_ADI] [REVİZYON_NUMARASI]

Örnek: Nginx’i Önceki Revizyona Geri Alma

my-nginx-ingress release’ini bir önceki revizyona geri almak istediğimizi varsayalım (örneğin, replika sayısını 3’e çıkardığımız güncellemeden önceki duruma):

helm rollback my-nginx-ingress 1 # Revizyon numarası 'helm history' çıktısından alınır.

Bu komut, release’i belirtilen revizyonun yapılandırma ve Chart durumuna geri döndürecektir.

Uygulama Kaldırma

Bir Kubernetes kümesinden Helm ile kurulmuş bir uygulamayı kaldırmak da oldukça basittir.

helm delete [RELEASE_ADI] [OPSİYONLAR]

* [RELEASE_ADI]: Kaldırılacak release’in adı.
* --purge: Bu opsiyon, release’in tüm geçmişini ve ilişkili tüm Kubernetes kaynaklarını (Deployment, Service, PVC vb.) siler. --purge olmadan silindiğinde, release geçmişi saklanır ve gelecekte geri alınabilir.

Örnek: Nginx Ingress Controller’ı Kaldırma

helm delete my-nginx-ingress --purge

Bu komut, my-nginx-ingress release’ini ve onunla ilişkili tüm Kubernetes kaynaklarını (Deployment, Service, Pod’lar vb.) kümeden tamamen silecektir.

Kendi Chart’ınızı Oluşturma

Helm ile mevcut Chart’ları kullanmak harika olsa da, kendi uygulamalarınız için özel Chart’lar oluşturmak, dağıtım süreçlerinizi otomatikleştirmek için çok güçlü bir yöntemdir.

1. Yeni Bir Chart Oluşturma:

Helm, yeni bir Chart yapısı oluşturmak için bir komut sağlar:

helm create my-custom-app

Bu komut, my-custom-app adında bir dizin oluşturur ve içine temel bir Chart yapısı ekler. Bu yapı, Nginx gibi basit bir web uygulamasını dağıtmak için varsayılan şablonlar (Deployment, Service, Ingress) ve values.yaml dosyası içerir.

2. Oluşturulan Dizini İnceleme:

my-custom-app/
  Chart.yaml
  values.yaml
  charts/
  templates/
    NOTES.txt
    _helpers.tpl
    deployment.yaml
    ingress.yaml
    service.yaml
    tests/
      test-connection.yaml

Bu temel yapı, çoğu uygulama için iyi bir başlangıç noktasıdır.

3. Chart’ı Özelleştirme:

* Chart.yaml: Uygulamanızın adını, sürümünü ve açıklamasını güncelleyin.
* values.yaml: Uygulamanızın yapılandırma seçeneklerini (örneğin, imaj adı, portlar, ortam değişkenleri, kaynak limitleri) tanımlayın.
* templates/:
* deployment.yaml: Uygulamanızın konteyner imajını, portlarını, ortam değişkenlerini ve diğer dağıtım ayarlarını belirleyin. values.yaml‘daki değerleri kullanarak şablonları dinamik hale getirin.
* service.yaml: Uygulamanızın Kubernetes içindeki ağ erişimini tanımlayın.
* ingress.yaml: Eğer uygulamanızın dışarıdan erişilmesi gerekiyorsa, Ingress kaynaklarını yapılandırın. ingress.enabled gibi bir değerle Ingress’i açıp kapatmayı sağlayabilirsiniz.
* Yeni kaynaklara ihtiyacınız varsa (örneğin, ConfigMap, Secret, PersistentVolumeClaim), templates/ dizinine yeni .yaml dosyaları ekleyin.
* _helpers.tpl dosyasını, tekrar eden kod parçacıklarını veya karmaşık adlandırma mantığını soyutlamak için kullanabilirsiniz.

4. Chart’ı Yerel Olarak Test Etme:

Chart’ınızı kümenize kurmadan önce, Helm’in oluşturacağı Kubernetes manifestlerini görmek ve olası hataları tespit etmek için helm install --dry-run --debug komutunu kullanın:

helm install ./my-custom-app --name my-test-release --dry-run --debug

Bu komut, Chart’ınızı Tiller’a gönderir, şablonları işler, ancak kaynakları Kubernetes API’sine göndermez. Bunun yerine, oluşturulan tüm manifestleri ve hata ayıklama bilgilerini konsola yazdırır. Bu, Chart’ınızın doğru şekilde yapılandırıldığından emin olmak için çok değerli bir adımdır.

5. Chart’ı Paketleme:

Chart’ınızı diğerleriyle paylaşmak veya bir depoya yüklemek için onu bir .tgz paketi halinde sıkıştırabilirsiniz:

helm package my-custom-app/

Bu komut, my-custom-app-0.1.0.tgz gibi bir dosya oluşturur.

Güvenlik Hususları ve En İyi Uygulamalar (Helm 2 için)

Helm 2 kullanırken, özellikle Tiller’ın varlığı nedeniyle güvenlik konusunda dikkatli olmak önemlidir. İşte bazı en iyi uygulamalar:

Tiller Güvenliği

* RBAC ile Minimum Yetki: Tiller’a cluster-admin rolü vermek en kolay yol olsa da, en güvenli yol değildir. Yukarıda gösterildiği gibi, Tiller için özel bir ServiceAccount oluşturun ve ona yalnızca ihtiyaç duyduğu yetkileri veren kısıtlı bir ClusterRole veya Role atayın. Örneğin, Tiller’ın sadece belirli bir namespace’te kaynakları yönetmesine izin verebilirsiniz.
* Ayrı Namespace: Tiller’ı kube-system yerine özel bir helm-tiller gibi ayrı bir namespace’e kurmayı düşünebilirsiniz.
* TLS ile Güvenli İletişim: Helm CLI ve Tiller arasında TLS (Transport Layer Security) kullanarak iletişimi şifrelemek mümkündür. Bu, iletişimin dinlenmesini veya manipüle edilmesini önler. Ancak, bu yapılandırma daha karmaşıktır ve sertifika yönetimi gerektirir. Üretim ortamlarında ciddi güvenlik gereksinimleri olan durumlarda düşünülmelidir.

Chart Kaynakları

* Güvenilir Chart Depoları: Yalnızca güvenilir ve bilinen Chart depolarından Chart’ları kullanın. Bilinmeyen kaynaklardan indirilen Chart’lar kötü amaçlı kod içerebilir.
* Chart’ları İnceleme: Bir Chart’ı kurmadan önce, özellikle üçüncü taraf Chart’ları için, templates/ dizinindeki manifestleri ve values.yaml dosyasını inceleyin. Neler dağıtıldığını ve hangi yapılandırma seçeneklerinin olduğunu anlayın.
* --dry-run --debug Kullanımı: Herhangi bir Chart’ı kurmadan önce helm install --dry-run --debug komutunu kullanarak oluşturulacak tüm Kubernetes kaynaklarını gözden geçirin.

values.yaml Yönetimi

* Hassas Bilgilerden Kaçınma: values.yaml dosyalarında veritabanı şifreleri, API anahtarları gibi hassas bilgileri doğrudan saklamaktan kaçının. Bunun yerine, Kubernetes Secret kaynaklarını kullanın. Chart’ınızın Secret kaynaklarını oluşturmasını sağlayabilir veya bunları manuel olarak oluşturup Chart’ın bu Secret’ları referans almasını sağlayabilirsiniz.
* GitOps Yaklaşımı: values.yaml dosyalarınızı versiyon kontrol sistemlerinde (Git) saklayın. Bu, yapılandırma değişikliklerinin izlenmesini ve denetlenmesini sağlar.
* CI/CD Entegrasyonu: Helm’i CI/CD (Sürekli Entegrasyon/Sürekli Dağıtım) işlem hatlarınıza entegre edin. Bu, otomatik test ve dağıtım süreçleri sağlar.

Versiyonlama ve Geri Alma

* Chart Versiyonlama: Chart’larınız için anlamlı versiyon numaraları kullanın (Semantic Versioning). Bu, değişiklikleri izlemeyi ve uyumluluğu yönetmeyi kolaylaştırır.
* Geri Alma Stratejileri: Uygulama güncellemeleri sonrası sorunlar için her zaman bir geri alma planınız olduğundan emin olun. Helm’in rollback özelliği bu konuda büyük kolaylık sağlar. helm history komutuyla revizyonları takip edin.

Sonuç

Helm 2, Kubernetes kümelerinde yazılım dağıtımını ve yönetimini basitleştiren devrim niteliğinde bir araç olmuştur. Tiller mimarisi nedeniyle bazı güvenlik endişeleri barındırsa da, uygulama yaşam döngüsü yönetimi, şablonlama yetenekleri ve Chart’lar aracılığıyla yeniden kullanılabilirlik gibi sağladığı avantajlar, onu uzun süre Kubernetes ekosisteminin vazgeçilmez bir parçası haline getirmiştir.

Bu makale boyunca, Helm 2’nin temel kavramlarını, kurulumunu, Chart yapısını, uygulama yükleme, güncelleme, geri alma ve kaldırma işlemlerini detaylı bir şekilde ele aldık. Kendi Chart’ınızı oluşturmanın adımlarını ve Helm 2 kullanırken dikkat edilmesi gereken güvenlik hususlarını da inceledik.

Her ne kadar Helm 3, Tiller’ı kaldırarak ve güvenlik mimarisini iyileştirerek daha modern bir yaklaşım sunsa da, dünya genelinde hala birçok eski proje ve altyapı Helm 2’yi kullanmaktadır. Bu nedenle, Helm 2’yi anlamak ve onunla çalışabilmek, mevcut sistemlerle etkileşim kurmak zorunda kalan geliştiriciler ve operasyon ekipleri için paha biçilmez bir beceridir.

Kubernetes ekosistemi sürekli geliştiği için, Helm’in en son sürümünü (Helm 3) ve onun sunduğu yeni özellikleri takip etmek her zaman önemlidir. Ancak, Helm 2’nin temel prensiplerini kavramak, genel olarak Kubernetes’teki uygulama paketleme ve yönetim mantığını anlamak için sağlam bir temel oluşturacaktır. Uygulama dağıtım süreçlerinizi otomatikleştirmek, standartlaştırmak ve yönetmek için Helm’in gücünden tam olarak yararlanmak, modern bulut yerel geliştirme ve operasyon pratiklerinin ayrılmaz bir parçasıdır.