📌 Hızlı Özet & Temel Çıkarım:
Production Seviyesinde Kubernetes Mimarisi, container’ların salt ayağa kaldırılmasından öte; trafik dalgalanmalarına göre otomatik ölçeklenen (HPA), cert-manager ile Let’s Encrypt TLS sertifikalarını otomatik yenileyen, Pod Disruption Budget ile sıfır kesintili güncelleme (zero-downtime rolling update) sunan ve NGINX Ingress Controller ile uç güvenliği sağlayan yüksek dayanımlı bir küme orkestrasyonudur.

1. Kubernetes Kümesinde Yüksek Erişilebilirlik (HA) Temelleri

Bir Kubernetes kümesini canlıya alırken en kritik hedef tek arıza noktası (SPOF) bırakmamaktır:

  • Control Plane (Master Düğümler): etcd veritabanının quorum sağlayabilmesi için en az 3 tek sayılı master düğüm çalıştırılmalıdır.
  • Worker Düğümleri: Servis pod’ları farklı fiziksel sunuculara veya bulut kullanılabilirlik bölgelerine (Availability Zones) podAntiAffinity kurallarıyla dağıtılmalıdır.
  • Sağlık Probları (Probes): Kubernetes’in arızalı pod’ları otomatik tespit edip yeniden başlatması için livenessProbe ve trafiği kesmesi için readinessProbe mutlaka tanımlanmalıdır.

2. Production NGINX Ingress ve Otomatik TLS Yapılandırması

Dış dünyadan gelen HTTP/HTTPS isteklerini küme içindeki doğru servislere yönlendiren katman Ingress Controller’dır.

Aşağıdaki bildirim (manifest), modern NGINX Ingress kuralları ile otomatik Let’s Encrypt TLS entegrasyonunu sergiler:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: core-api-ingress
  namespace: production
  annotations:
    kubernetes.io/ingress.class: "nginx"
    cert-manager.io/cluster-issuer: "letsencrypt-prod"
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
    nginx.ingress.kubernetes.io/proxy-body-size: "10m"
    nginx.ingress.kubernetes.io/proxy-connect-timeout: "15"
    nginx.ingress.kubernetes.io/proxy-read-timeout: "60"
    nginx.ingress.kubernetes.io/limit-rps: "50" # Rate limiting korumasi
spec:
  tls:
  - hosts:
    - api.aksoy.com
    secretName: aksoy-api-tls-cert
  rules:
  - host: api.aksoy.com
    http:
      paths:
      - path: /v1
        pathType: Prefix
        backend:
          service:
            name: core-api-service
            port:
              number: 8080

Bu yapılandırma ile cert-manager arka planda ACME challenge döngüsünü tamamlar, sertifikayı çeker ve Secret olarak bağlar. Süresi dolmadan 30 gün önce sertifika otomatik olarak sıfır kesintiyle yenilenir.

3. Horizontal Pod Autoscaler (HPA) ve Kaynak Rezervasyonları

Kubernetes scheduler’ının pod’ları doğru yerleştirebilmesi için her container’ın resources.requests ve resources.limits değerleri açıkça belirlenmelidir.

HPA, CPU veya bellek tüketimi belirlenen eşiği (örneğin %70) aştığında saniyeler içinde yeni pod replikaları başlatır:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: core-api-hpa
  namespace: production
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: core-api-deployment
  minReplicas: 3
  maxReplicas: 20
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

4. İlgili Konular ve İç Bağlantılar

5. Sıkça Sorulan Sorular

Pod Disruption Budget (PDB) neden zorunludur?

Düğüm bakım çalışmaları veya Kubernetes sürüm güncellemeleri sırasında kubectl drain çalıştırıldığında, PDB tanımlanmamışsa tüm pod’lar aynı anda sonlandırılabilir ve geçici kesinti yaşanır. PDB, “en az 2 pod her an ayakta kalmalıdır” garantisi verir.

Ingress ile API Gateway (Kong, Envoy) arasındaki fark nedir?

Ingress temel seviyede yönlendirme (routing), TLS sonlandırma ve basit rate-limit sağlar. Eğer detaylı JWT doğrulama, dinamik eklentiler ve gelişmiş metrik toplama gerekiyorsa Ingress arkasında veya yerine Kong / Envoy tabanlı bir API Gateway konuşlandırılır.

6. Pod Security Standards (PSS) ve Ağ İlkeleri (NetworkPolicies) ile Sıfır Güven (Zero-Trust)

Kubernetes kümesinde varsayılan olarak her pod, aynı kümedeki diğer tüm pod’larla kısıtlamasız haberleşebilir. Bu durum bir frontend pod’u ele geçirildiğinde saldırganın doğrudan iç veritabanı portlarına (örneğin port 5432) erişebilmesi anlamına gelir.

Bunu önlemek için Kubernetes NetworkPolicy uygulanarak katı izolasyon sağlanır:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: database-access-policy
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: postgres-db
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: backend-api # Sadece backend pod'larindan gelen trafige izin ver
    ports:
    - protocol: TCP
      port: 5432

Bu kural sayesinde frontend veya analiz servisleri veritabanı IP’sine ping dahi atamaz; ağ seviyesinde paketler çekirdek (iptables/eBPF) tarafından sessizce düşürülür.

7. Kubernetes Kümesinde Graceful Shutdown ve PreStop Kancaları

Canlı sistemlerde pod’lar yeniden başlatılırken veya HPA ile pod sayısı azaltılırken (scale down), o anda pod üzerinde işlem gören kullanıcı isteklerinin yarıda kesilmemesi gerekir.

Kubernetes bir pod’u sonlandırırken önce SIGTERM sinyali gönderir, 30 saniye sonra yanıt alamazsa SIGKILL ile zorla kapatır.

Trafik kaybını sıfırlamak için Deployment yapılandırmasına preStop Lifecycle Hook eklenmelidir:

lifecycle:
  preStop:
    exec:
      command: ["/bin/sh", "-c", "sleep 10"]

Bu 10 saniyelik bekleme komutu, Ingress ve yük dengeleyicinin (kube-proxy) ilgili pod’un IP adresini yönlendirme tablosundan çıkarması için yeterli süreyi tanır. Yeni gelen istekler diğer sağlıklı pod’lara aktarılırken, mevcut pod elindeki son işlemleri tamamlar ve temiz bir şekilde kapanır.

8. Kubernetes Kümesinde Kaynak Limitleri ve OOM-Killed Senaryolarının Yönetimi

Container’lar bellek sınırını (memory limit) aştığında Linux çekirdeği anında Out of Memory (OOM) Killer mekanizmasını devreye sokarak pod’u 137 çıkış koduyla sonlandırır.

Bu beklenmedik çöküşleri engellemek için:

  1. Bellek Profili Çıkarma: Pod’un normal çalışma anındaki ve ani yük altındaki RAM tüketimi Prometheus üzerinde en az 7 gün boyunca izlenmelidir.
  2. Limit Marjı (%25 Kuralı): memory.limit değeri, gözlemlenen tepe tüketimin en az %25-30 üzerinde tanımlanmalıdır.
  3. CPU Throttle İncelemesi: CPU limitleri pod’u öldürmez ancak işlemciyi yavaşlatır (throttling). container_cpu_cfs_throttled_periods_total metriği izlenerek mikroservisin haksız yere frenlenip frenlenmediği doğrulanmalıdır. Bu dikkatli kapasite planlaması, Kubernetes kümesinin fırtınalı trafik günlerinde bile sarsılmadan ayakta kalmasını sağlar.