Docker Compose’tan Kubernetes’e Geçiş: Helm Chart ile Adım Adım Dağıtım Rehberi

Giriş

Docker Compose, tek makinede çok konteynerli uygulamaları hızla ayağa kaldırmak için harika. Ancak ölçek, güvenlik ve gözlemlenebilirlik ihtiyaçları arttığında, Kubernetes’e geçiş kaçınılmaz oluyor. Bu yazıda, mevcut Compose tanımınızı Helm Chart’a dönüştürerek Kubernetes üzerinde modern, sürdürülebilir ve otomasyona uygun bir dağıtım yapmayı adım adım ele alacağız. Rehber, pratik örnekler, en iyi uygulamalar ve sık yapılan hatalara karşı öneriler içerir.

Neden Helm?

Helm, Kubernetes manifestlerini paketleyip versiyonlayarak tekrar kullanılabilir hale getirir. values.yaml ile çevreye göre yapılandırma yönetimi kolaylaşır, helm upgrade --install ile idempotent dağıtımlar yapılır, rollback ile hızlı geri dönüş sağlanır. Çeviklik, izlenebilirlik ve CI/CD uyumluluğu açısından Compose’a kıyasla çok daha güçlü bir yönetim modeli sunar.

Ön Koşullar

- Kubernetes kümesi (minikube, kind, AKS, EKS veya GKE)
- kubectl ve helm kurulu (Helm v3 önerilir)
- Mevcut Docker Compose dosyası (docker-compose.yml)
- Bir container registry erişimi (Docker Hub, GHCR, ECR vs.)

Compose’tan Helm’e Modelleme

Compose servislerini tek tek Deployment ve Service kaynaklarına bölün. Her servis için bir Deployment (replica sayısı, image, env, volume mount) ve bir Service (ClusterIP veya LoadBalancer) oluşturun. Ağ politikaları, health check, kaynak limitleri gibi Kubernetes yerleşik yeteneklerle güvenilirlik ve ölçeklenebilirlik kazanın.

Helm Chart İskeleti Oluşturma

Proje dizininde helm create uyg-app komutunu çalıştırın. Oluşan yapı:
charts/
templates/
values.yaml
Chart.yaml
Yararlı şablonlar gelse de, gereksiz varsayılanları sadeleştirmek iyi bir başlangıçtır.

values.yaml Tasarımı

Uygulamanın farklı ortamları için değişecek alanları values.yaml içine alın. Örnek bir iskelet:
image.repository: ghcr.io/org/uyg-app
image.tag: 1.2.3
replicaCount: 3
resources.limits.cpu: "500m"
resources.limits.memory: "512Mi"
env: { APP_ENV: "prod", LOG_LEVEL: "info" }
service.type: ClusterIP
service.port: 8080
ingress.enabled: true
ingress.hosts: ["api.ornek.com"]

Deployment ve Service Şablonları

Deployment için şunları ihmal etmeyin:
- resources: request ve limit belirleyin (örn. cpu: 200m, memory: 256Mi).
- livenessProbe ve readinessProbe: HTTP endpoint veya TCP check ile hızlı hata tespiti.
- securityContext: root dışı kullanıcı, readOnlyRootFilesystem, capabilities kısıtlaması.
- envFrom: ConfigMap ve Secret’lardan çevresel değişken yönetimi.
Service için uygun type (ClusterIP, NodePort, LoadBalancer) ve port seçin. Dış dünyaya açılacaksanız Ingress tanımı ve TLS sertifikası (ör. cert-manager) planlayın.

İnşa, Push ve İlk Dağıtım

- Container imajınızı CI üzerinden versiyonlayın ve registry’ye push edin (örn. 1.2.3 tag’i).
- values.yaml içindeki image.tag değerini güncelleyin.
- İlk kurulum: helm upgrade --install uyg-app ./uyg-app -n prod
- Dağıtımı doğrulayın: kubectl get pods -n prod ve kubectl describe ile olayları inceleyin.

Yükseltme ve Geri Alma

- Versiyon güncellemesi: helm upgrade uyg-app ./uyg-app -n prod
- Farkları görmek için: helm diff upgrade (helm-diff eklentisi).
- Sorun varsa: helm rollback uyg-app <REVISION> -n prod. Helm, geçmiş sürümleri sakladığından geri dönüşler saniyeler içinde tamamlanır.

Gizli Bilgiler ve Config Yönetimi

Şifreler, token’lar ve API anahtarlarını Secret içinde tutun. Git’te açık tutmamak için Sealed Secrets veya External Secrets Operator kullanın. Konfigürasyonlarınızı ConfigMap olarak versiyonlayın; uygulama yeniden başlatması gerektiren değişikliklerde checksum/config anotasyonuyla otomatik rollout sağlayın.

Otomatik Ölçeklendirme ve Sağlık

HPA (Horizontal Pod Autoscaler) ile CPU/Memory metriklerine göre pod sayısını otomatik artırıp azaltın. readinessProbe doğru ayarlı değilse HPA ölçeklense bile trafiğin başarısız olacağını unutmayın. Ayrıca PodDisruptionBudget ile planlı bakım sırasında minimum sağlıklı pod sayısını garanti altına alın.

Güvenlik ve RBAC

Uygulamaya özel bir ServiceAccount tanımlayın, yalnızca gerekli izinleri veren bir Role/RoleBinding ekleyin. PodSecurityContext ile kullanıcı/GRUP ID belirleyin, root olarak çalışmayın. Ağ tarafında NetworkPolicy ile trafik kısıtlaması yaparak saldırı yüzeyini daraltın.

CI/CD ve GitOps

- CI adımları: test → build → scan → push → helm lint → helm template/diff → deploy.
- GitOps için Argo CD veya Flux kullanın. Helm chart’ınızı bir Git deposuna koyun, values dosyalarını ortam bazlı dallarda yönetin. Her commit, küme durumunu deklaratif olarak günceller; manuel hataları azaltır.

Gözlemlenebilirlik: Log, Metrik ve İz

Log’lar için stdout/stderr yazın; kümede Loki/ELK ile toplayın. Metrikler için Prometheus, dashboard için Grafana kurun. Uygulama düzeyinde OpenTelemetry ile dağıtık izlemeyi etkinleştirerek istek gecikmelerini uçtan uca görünür kılın.

Yaygın Hatalar ve İpuçları

- imagePullPolicy yanlış: Geliştirme dışında IfNotPresent genelde yeterlidir; prod’da immutable tag kullanın (örn. SHA digest).
- resource tanımsız: Limit/Request yoksa scheduler tutarsız davranır; önceliklendirme zorlaşır.
- probe endpoint’leri: Uygulama hazır olmadan trafiğe açmayın; readiness’i gerçek bağımlılıklar sağlandığında başarılı olacak şekilde ayarlayın.
- config değişikliği rollout: ConfigMap değişikliğini pod’lara yansıtmak için anotasyon checksum tekniğini kullanın.

Sonuç

Helm ile Kubernetes’e geçiş, yalnızca bir orkestrasyon değişimi değil; aynı zamanda daha iyi sürümleme, güvenlik, otomasyon ve gözlemlenebilirlik kültürüne geçiştir. Compose dünyasındaki sadeliği, şablonlanabilir manifestler, values tabanlı yapılandırma ve GitOps süreçleriyle kaybetmeden; aksine kurumsal ölçekte yönetilebilirlik kazanırsınız. Küçük başlayın, her sürümde bir iyileştirme ekleyin ve dağıtımlarınızı otomatikleştirerek güvenle ölçekleyin.

Kubernetes’te GitOps: Argo CD ile Sıfırdan Kurulum, Yapılandırma ve En İyi Uygulamalar

GitOps Nedir ve Neden Argo CD?

GitOps, uygulama ve altyapı durumunu tek gerçek kaynak olarak Git deposunda tutup teslimatı otomatikleştiren bir yaklaşım. Kubernetes dünyasında bu modelin en pratik karşılığı Argo CD. Argo CD, Git’teki deklaratif manifestleri izler, kümeye uygular ve sapmaları sürekli olarak düzeltir. Bu sayede manuel kubectl komutları azalır, güvenlik artar ve geri dönüş (rollback) işlemleri kolaylaşır. Bu yazıda Argo CD’yi sıfırdan kurup ilk “Application” nesnemizi oluşturacak, ardından pratik ipuçları ve sorun giderme önerileriyle süreci üretim standartlarına yaklaştıracağız.

Önkoşullar

Başlamadan önce aşağıdaki araçlara ihtiyacınız olacak: Kubernetes kümesi (Minikube, Kind veya bulut), kubectl (1.25+), Helm (3.x) ve örnek bir Git deposu (GitHub/GitLab). Lokal bir deneme için Minikube idealdir: minikube start. Kümede cluster-admin yetkinizin olduğundan emin olun.

Argo CD Kurulumu (Helm ile)

Helm kullanarak Argo CD’yi kurmak, yapılandırmayı sürdürmek ve güncellemeleri yönetmek için en esnek yollardan biri. Aşağıdaki adımları izleyin:

1) Argo repo’yu ekleyin:
helm repo add argo https://argoproj.github.io/argo-helm
helm repo update

2) Namespace oluşturup yükleyin:
kubectl create namespace argocd
helm install argocd argo/argo-cd -n argocd

3) Arayüze erişim: Hızlı denemeler için port yönlendirme yapabilirsiniz:
kubectl port-forward svc/argocd-server -n argocd 8080:443
Arayüz: https://localhost:8080

4) İlk parola: Varsayılan kullanıcı admin’dir. Parolayı alın:
kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d; echo

İlk Uygulamanızı (Application) Tanımlayın

Argo CD’nin kalbi Application CRD’sidir. Git deposunu, hedef namespace’i ve senkronizasyon politikasını burada tanımlarsınız. Basit bir NGINX dağıtımı için örnek bir Application yaratabilirsiniz. Aşağıdaki içeriği app-nginx.yaml olarak kaydedip uygulayın:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: demo-nginx
  namespace: argocd
spec:
  project: default
  source:
   repoURL: https://github.com/kullanici/manifestler.git
   targetRevision: main
   path: k8s/nginx
  destination:
   server: https://kubernetes.default.svc
   namespace: demo
  syncPolicy:
   automated:
    prune: true
    selfHeal: true

Uygulamak için: kubectl apply -f app-nginx.yaml. Ardından Argo CD arayüzünde “demo-nginx” uygulamasını göreceksiniz. Automated sync sayesinde Git’e her push’ta küme otomatik güncellenecektir. “prune: true” ile Git’te çıkarılan kaynaklar kümeden de temizlenir; “selfHeal: true” ise drift (sapma) olduğunda durumu geri alır.

CLI ile Yönetim (Opsiyonel ama Önerilir)

Argo CD CLI, betiklenebilir ve hızlı yönetim için idealdir. Kurulum: macOS için brew install argocd. Giriş:
argocd login localhost:8080 --username admin --password <parola> --insecure
Uygulama oluşturma örneği:
argocd app create demo-nginx --repo https://github.com/kullanici/manifestler.git --path k8s/nginx --dest-server https://kubernetes.default.svc --dest-namespace demo --sync-policy automated --self-heal --auto-prune

Depo Yapısı ve Manifest Stratejileri

Üretimde depo düzeni, sürdürülebilirliğin anahtarıdır. Sıklıkla app-of-apps paterni tercih edilir: tek bir “root” uygulama, alt uygulamaları referans eder. Ortam ayrımı için Kustomize overlay’leri (dev/stage/prod) veya Helm chart’ları kullanın. “Config” ile “kod”u ayırın; hassas verileri Sealed Secrets veya External Secrets Operator ile yönetin.

En İyi Uygulamalar

- Şube stratejisi: Prod için korumalı branch kullanın; korumalı gözden geçirme (PR) olmadan birleşim yapmayın.
- RBAC ve SSO: Argo CD’yi OIDC/SAML ile kimlik sağlayıcınıza bağlayın; takım ve proje bazlı yetki verin.
- Sadece Git yazar: Manuel kubectl ile müdahaleyi sınırlayın; drift yaratır. Operasyonlar Git üzerinden ilerlesin.
- Health checks: Özel CRD’ler için sağlık kuralları tanımlayın; bekleme ve time-out eşiklerini ayarlayın.
- Namespace izolasyonu: Her ekip/ürün için ayrık namespace ve proje kullanın.
- Kaynak kotası ve limitler: Pod crash-loop ve aşırı kaynak kullanımını böyle önleyin.
- Audit ve izleme: Argo CD Event’lerini ve Kubernetes denetim izlerini toplayın; Prometheus/Grafana ve OpenTelemetry ile görünürlük sağlayın.

Yaygın Sorunlar ve Çözüm İpuçları

- OutOfSync ama Apply olmuyor: RBAC, mutating webhook veya admission policy engelliyor olabilir. kubectl describe ile olayları inceleyin.
- Image pull hatası: Registry kimlik bilgilerini Secret olarak tanımlayıp ServiceAccount’a bağlayın; repo başvurularını güncelleyin.
- Helm values uyuşmazlığı: Her ortam için ayrı values dosyası kullanın; Argo CD’de spec.source.helm.valueFiles ile belirtin.
- Finalizer takılması: Silinemeyen kaynaklarda finalizer’ları kaldırmadan önce bağımlılıkları temizleyin; Argo CD’nin “prune” davranışını kontrol edin.
- Sync dalgası (sync wave): Kaynak sırala(niyet)ması için argocd.argoproj.io/sync-wave anotasyonunu kullanın; CRD’ler CR’lardan önce uygulanmalı.

Güvenlik ve Güncelleme

Argo CD’yi düzenli olarak güncelleyin: helm upgrade argocd argo/argo-cd -n argocd --version <hedef>. Admin varsayılan parolasını kurulumdan sonra hemen değiştirin, mümkünse SSO zorunlu hale getirin. Arayüzü doğrudan internete açmak yerine Ingress + WAF arkasında ve mTLS/oidc ile koruyun.

Sonuç

GitOps ile operasyonel borç azalır, dağıtım tekrarlanabilirliği artar ve denetlenebilirlik kazanırsınız. Argo CD, Kubernetes üzerinde bu yaklaşımı benimsemek için olgun, topluluk tarafından desteklenen bir araç. İlk kurulumdan sonra depo yapınızı sağlamlaştırın, otomasyonu politikalarla çerçeveleyin ve her değişikliği Git üstünden yürütün. Böylece hem geliştirici deneyimi hem de üretim güvenilirliği belirgin şekilde iyileşir.

Kubernetes'te GitOps ile Canary Dağıtımı: Argo CD ve Istio ile Aşamalar ve İyi Uygulamalar

Giriş

Kubernetes üzerinde hizmet güncellemeleri yaparken "her şey ya hep ya hiç" yaklaşımı risklidir. Canary dağıtımı, yeni sürümü küçük bir kullanıcı kesimine açıp davranışı izleyerek ilerlemeye olanak verir. Bu rehberde GitOps yaklaşımıyla Argo CD kullanarak manifests tabanlı yönetim, Istio ile trafikte kademeli yönlendirme ve temel otomasyon-adımlarını ele alacağız. Amaç, tekrarlanabilir, gözlemlenebilir ve güvenli bir canary süreci kurmaktır.

Önkoşullar

Bu makaledeki adımları uygulayabilmek için aşağıdaki bileşenlere sahip olmalısınız: bir Kubernetes kümesi (1.20+ önerilir), Argo CD kurulumu, Istio servis mesh kurulumu (ingress/gateway dahil), Git deposu (manifests için) ve izleme için Prometheus/Grafana. Ayrıca kubectl, argocd CLI ve gerekli RBAC izinleri gereklidir.

1) Manifests ve GitOps Hazırlığı

Uygulamanızı Kustomize veya Helm ile paketleyin. İki ayrı sürüm manifesti tutmak faydalıdır: v1 ve v2. Git deposunda şunları organize edin: /overlays/stable (v1), /overlays/canary (v2) ve ortak base dosyalar. Argo CD bu repo'yu izleyerek kümedeki kaynakları senkronize eder. Argo CD Application manifesti ile otomatik senkronizasyon veya manuel onay tercih edilebilir.

2) Istio ile Trafik Yönlendirme

Istio VirtualService ve DestinationRule kaynakları ile servis içinde ağırlık bazlı dağıtım yapabilirsiniz. Örnek kısa yapı: bir VirtualService içinde canary için %10, %50 gibi ağırlıklar belirlenir. Örnek kontrol komutu: kubectl -n your-namespace get virtualservice. Canary sürecinde ağırlıkları Git üzerinden değiştirerek Argo CD ile otomatik olarak uygulayabilirsiniz; böylece tüm değişiklikler version kontrolünde kalır.

3) Otomasyon ve Güvenlik: Argo CD + Webhook

Manifests'te ağırlık değişiklikleri bir PR ile yapılır. CI pipeline'ınız bu PR'ı doğrular (lint, güvenlik taramaları). Merge sonrası Argo CD otomatik senkronize eder. Opsiyonel: bir webhook ile Argo CD sync tamamlandığında Prometheus sorguları tetikleyerek sağlık kontrolü başlatabilirsiniz. Eğer belirlenen SLO/SLA dışı metrikler tespit edilirse, otomatik rollback için Argo CD uygulamasına geri alma tetiklenebilir.

4) Gözlemlenebilirlik ve Karar Kriterleri

Canary'nin başarılı sayılması için ölçülebilir kriterler belirleyin: hata oranı, p99 gecikme, throughput ve kullanıcı deneyimi metrikleri. Prometheus'ta sorgular tanımlayın, Grafana panelleri oluşturun ve Alertmanager ile eşik aşımlarında uyarı üretin. Otomasyon için bu uyarılar webhook ile rollback sürecini başlatabilir.

5) İleri Seviye İpuçları

- İzolasyon: Canary pod'larını ayrı bir node pool veya kaynak sınırlamaları ile izole edin. - A/B test yerine istatistiksel güven: Trafik artışlarını küçük adımlarla yapın (örn. %5, %20, %50). - Trafik yönlendirme dışında shadowing ile gerçek üretim trafiğini yeni sürüme de gönderip yalnızca gözlemleyebilirsiniz. - Rollback kriterlerini mutlaka otomatik hale getirin; manuel müdahale süresini minimize edin. - Argo Rollouts kullanmak istiyorsanız, Rollout CRD'si ile Istio'yu entegre ederek daha ileri seviye deneyler ve analizler yapabilirsiniz.

Örnek Komut Akışı

Bir canary adımı için tipik komutlar: git checkout -b feature/canary-weight, manifests'te VirtualService ağırlığını değiştir, git commit && git push. PR merge sonrası Argo CD otomatik olarak uygulamayı senkronize eder: argocd app get my-app ve kubectl -n my-namespace get pods ile doğrulama yapabilirsiniz.

Sonuç

GitOps tabanlı canary dağıtımı, değişikliklerin izlenebilir, geri alınabilir ve tekrarlanabilir olmasını sağlar. Argo CD ile manifest kontrolünü elinizde tutarken Istio trafik yönlendirmesi sayesinde kademeli roll-out'lar yapabilirsiniz. Ancak başarının anahtarı güçlü gözlemlenebilirlik, net kabul kriterleri ve otomatik rollback mekanizmalarıdır. Bu temel adımları uygulayarak üretimde riskleri azaltabilir ve sürüm yayımlarını daha güvenilir hale getirebilirsiniz.