Kubernetes eğitimlerinde her şey zarif görünür - bir YAML deploy edersiniz ve sihir gerçekleşir. Peki ya production? O bambaşka bir hikâye. Yıllardır kurumsal müşteriler için cluster yönettikten sonra, yeni başlayanları sahada pişmiş mühendislerden gerçekten ayıran 15 senaryoyu bir araya getirdik. İşte fiilen karşılaşacaklarınız ve çözüm yolları.

Debugging Kâbusları

1. Pod CrashLoopBackOff'ta Takılı ve Log Yok

Bu, Kubernetes debugging'inin sessiz katilidir. Pod'unuz sürekli yeniden başlıyor ama loglarda hiçbir şey yok. Bakmanız gereken yerler:

  • Önceki container'ın loglarına bakın - container henüz hiçbir şey yazamadan çökmüş olabilir
  • Init container'ları inceleyin - ana container'ınız daha başlamadan çoğu zaman sessizce başarısız olurlar
  • OOMKilled kontrolü yapın - bellek yüzünden öldürülen container'lar her zaman arkalarında log bırakmaz
  • İmajı lokalde test edin - bazen entrypoint, eksik env değişkenleri veya config'ler yüzünden anında çıkar
  • Debug container kullanın - pod ortamını incelemek için bir busybox sidecar'ı ekleyin

2. Node Çökmesinden Sonra StatefulSet Pod'u Depolamasına Yeniden Bağlanamıyor

Node'unuz düştü ve pod artık PVC'sini bekleyerek takılı kaldı. Veri güvende ama Kubernetes onu yeniden bağlayamıyor. Yaygın çözümler:

  • Takılan pod'u force-delete edin - bazen Kubernetes'in bırakması için bir dürtme gerekir
  • VolumeAttachment nesnelerini kontrol edin - ölen node'dan kalan bayat attachment'lar yenilerini engelleyebilir
  • CSI driver sağlığını doğrulayın - kube-system'deki storage driver pod'ları ilgi bekliyor olabilir
  • Son çare: PV'yi patch'leyin - yeniden bağlanmaya izin vermek için claimRef'i kaldırın

3. Pod'lar Pending'de Ama Cluster Autoscaler Ölçeklenmiyor

Bekleyen pod'larınız var, bütçeniz de var ama yeni node gelmiyor. İşte debugging kontrol listesi:

  • Autoscaler loglarına bakın - scale-up isteğini neden reddettiğini size tam olarak söyleyecektir
  • Node group limitlerini doğrulayın - farkında olmadan maksimum node sayısına ulaşmış olabilirsiniz
  • Pod gereksinimlerini inceleyin - hiçbir node group'un karşılayamadığı nodeSelector, affinity kuralları veya taint'ler olabilir
  • PodDisruptionBudget'lara bakın - autoscaler'ın karar döngüsünü bloklayabilirler
  • Cloud kotalarını kontrol edin - sağlayıcınızın o bölgede kapasitesi kalmamış olabilir

4. Pod'lar Sonsuza Kadar ContainerCreating'de Takılı

Pod schedule edildi ama bir türlü başlamıyor. Bu genellikle bir CNI veya depolama sorunudur:

  • CNI eklentisi sorunları - Calico, Cilium veya kullandığınız CNI pod'larının sağlıklı olup olmadığına bakın
  • IP adresi tükenmesi - subnet dolmuş olabilir
  • Container runtime sorunları - containerd takılmış veya aşırı yüklenmiş olabilir
  • Storage mount hataları - PVC bağlama sorunları veya CSI driver problemleri
  • Overlay dosya sistemi bozulması - bazen temizlik yapıp containerd'yi yeniden başlatmanız gerekir

5. Pod'larda Rastgele DNS Hataları

Bazı istekler çalışıyor, diğerleri rastgele timeout alıyor. DNS sorunlarının debug edilmesi meşhur derecede zordur:

  • CoreDNS pod'larını kontrol edin - aşırı yüklenmiş veya çöküyor olabilirler
  • Conntrack limitlerine bakın - bağlantı izleme tablosunun tükenmesi rastgele hatalara yol açar
  • UDP race condition - dnsConfig'inize single-request-reopen ekleyin
  • NodeLocal DNSCache'i değerlendirin - DNS kaynaklı sorunların çoğunu ortadan kaldırır
  • ndots ayarını kontrol edin - yüksek değerler gereksiz DNS sorgularına neden olur

Güvenlik ve Mimari

6. Çok Kiracılı (Multi-Tenant) Bir Cluster İşletmek

Birden fazla ekip, tek cluster. Herkesi nasıl izole ve güvende tutarsınız?

  • Kiracı başına namespace - izolasyonun temeli
  • Namespace ile sınırlı RBAC rolleri - ekipler yalnızca kendi kaynaklarını görebilir
  • Resource quota'lar - tek bir kiracının tüm kaynakları tüketmesini önler
  • NetworkPolicy default-deny - açıkça izin verilmedikçe namespace'ler arası trafik yok
  • PodSecurityAdmission - namespace başına kısıtlı güvenlik politikaları uygulayın
  • Hassas iş yükleri için - kiracı başına ayrılmış node pool'ları düşünün

7. NetworkPolicy Namespace'ler Arası Trafiği Blokluyor

NetworkPolicy'leri etkinleştirdiniz ve artık her şey bozuk. Onları doğru tasarlamanın yolu:

  • Audit moduyla başlayın - Cilium gibi araçlar neyin bloklanacağını önceden görmenizi sağlar
  • Önce default deny - sonra gerekenlere açıkça izin verin
  • Namespace label'ları kullanın - tek tek pod'lara değil, namespace'lerden gelen trafiğe izin verin
  • Netcat ile test edin - bir debug pod'u deploy edip bağlantıyı doğrulayın
  • Hubble ile görselleştirin - gerçek trafik akışlarını gerçek zamanlı izleyin

8. Yalnızca Güvenilir Container İmajlarını Zorunlu Kılmak

Yalnızca dahili registry'nizden onaylı imajların çalışabildiğinden emin olmanız gerekiyor. Seçenekleriniz:

  • Kyverno - basit YAML tabanlı politikalar, çoğu ekip için harika
  • OPA Gatekeeper - daha güçlü ama öğrenme eğrisi daha dik
  • Özel Admission Webhook - yalnızca harici sistem entegrasyonu gerekiyorsa
  • Profesyonel ipucu: İmaj imzalama ekleyin - tedarik zinciri güvenliği için Cosign + policy engine kullanın

9. VPN Üzerinden Harici Veritabanına Bağlanmak

Uygulamanızın yalnızca VPN üzerinden erişilebilen bir veritabanına ulaşması gerekiyor. Mimari seçenekleri:

  • Sidecar VPN container'ı - iyi izolasyon, ama bağlantıları çoğaltır
  • Ayrılmış VPN gateway pod'ları - merkezi, yönetimi daha kolay
  • Node seviyesinde VPN (önerilen) - yüksek erişilebilirlik için hostNetwork'lü DaemonSet
  • Güvenlik olmazsa olmazları - kimlik bilgilerini Secret'larda saklayın, erişimi NetworkPolicy ile kısıtlayın, mTLS'i etkinleştirin

Performans ve Güvenilirlik

10. Kritik Pod, Node Baskısı Yüzünden Evict Edildi

En önemli pod'unuz, node'un kaynakları tükendiği için öldürüldü. QoS sınıflarını anlamak burada kilit önemde:

  • BestEffort (ilk evict edilen) - request veya limit tanımlanmamış
  • Burstable (ikinci sırada evict edilen) - request'ler limitlerden düşük
  • Guaranteed (en son evict edilen) - tüm container'lar için request'ler limitlere eşit
  • Kritik iş yükleri için - her zaman Guaranteed QoS + yüksek PriorityClass kullanın
  • Eviction eşiklerini yapılandırın - kubelet'in bellek ve disk baskısı ayarlarını ince ayarlayın

11. Rolling Update Kesintiye Neden Oldu

Yeni bir sürüm deploy ettiniz ve kullanıcılar hata gördü. Ne ters gitti?

  • Eksik readiness probe - uygulama hazır olmadan trafik gönderildi
  • Fazla agresif probe - yavaş açılan uygulamalar için initialDelaySeconds çok kısa
  • Yanlış probe endpoint'i - timeout'a düşen ağır bir endpoint kullanılıyor
  • Deployment ayarları önemli - maxUnavailable'ı 0'a çekin, minReadySeconds ekleyin
  • preStop hook'larını unutmayın - pod'lara zarif kapanış (graceful shutdown) için zaman tanıyın

12. Ingress Controller Yük Altında Çöküyor

Trafik dalgası geldi ve ingress'iniz darboğaza dönüştü. Çözüm yolu:

  • Config reload fırtınalarını kontrol edin - sık Ingress değişiklikleri performans düşüşüne neden olur
  • Yatay ölçeklendirin - anti-affinity ile daha fazla replica
  • Worker process'leri ayarlayın - ConfigMap'te auto'ya çekin
  • Keep-alive'ı etkinleştirin - bağlantı ek yükünü azaltın
  • Ayırmayı düşünün - iç ve dış trafik için ayrı controller'lar

13. Istio Sidecar'ı Uygulamanızdan Fazla CPU Tüketiyor

Service mesh ek yükü kaynaklarınızı yiyor. Optimizasyon stratejileri:

  • Sidecar kapsamını sınırlayın - egress'i yalnızca gerekli namespace'lere yapılandırın
  • Kaynak limitlerini ince ayarlayın - sidecar'lar varsayılanların önerdiği kadarına ihtiyaç duymaz
  • Kullanılmayan özellikleri kapatın - access logging'i kapatın, tracing örneklemesini azaltın
  • Ambient mesh'i değerlendirin - L4 trafiği için Istio'nun sidecar'sız modu

14. etcd Control Plane'i Yavaşlatıyor

API server yanıtları yavaş ve her şey hantal hissettiriyor. Suçlu genellikle etcd'dir:

  • Disk I/O kritik - etcd, milisaniyenin altında gecikmeye sahip SSD'lere ihtiyaç duyar
  • Çok fazla nesne - secret'lar, configmap'ler ve event'ler zamanla birikir
  • Üyeler arası ağ gecikmesi - etcd node'larını aynı availability zone'da tutun
  • Auto-compaction'ı etkinleştirin - veritabanının sonsuza kadar büyümesini önler
  • Düzenli defragmentasyon planlayın - ama yalnızca bakım pencerelerinde

15. Kubelet Tek Bir Node'da Sürekli Yeniden Başlıyor

Bir node huysuzluk yapıyor, diğerleri sorunsuz. Bakılacak yerler:

  • Systemd durumunu kontrol edin - kubelet logları journalctl üzerinden
  • OOM kill'lere bakın - kubelet'in kendisi bellek yüzünden öldürülüyor olabilir
  • Container runtime'ı doğrulayın - containerd yanıt vermiyor olabilir
  • Cgroup driver'ı kontrol edin - kubelet ve runtime arasında eşleşmesi şart
  • Disk baskısı - /var/lib/kubelet'te yer tükeniyor olabilir
  • Sertifika süresi dolması - sıkça gözden kaçan ama yaygın bir neden

Temel Çıkarımlar

Yüzlerce production olayında sorun giderdikten sonra öğrendiklerimiz şunlar:

  • Önce veri toplayın - değişiklik yapmadan önce event'ler, loglar, metrikler ve node durumu
  • Savunmalarınızı katmanlayın - RBAC + NetworkPolicy + Resource Quota + Pod Security
  • Arıza için tasarlayın - doğru QoS sınıfları, priority class'lar ve PodDisruptionBudget'lar
  • Control plane'i izleyin - etcd ve kubelet sağlığı kritik göstergelerdir
  • Zorlamadan önce test edin - politikalar için audit modu, değişiklikler için canary deployment'lar

Production Kubernetes bir varış noktası değil, bir yolculuktur. Bu 15 senaryo işin temelidir - bunlarda ustalaşın, cluster'larınız ne fırlatırsa fırlatsın hazır olursunuz. Böyle senaryolar için nöbette deneyimli mühendisler olsun isterseniz, yönetilen hizmetler ekibimiz her gün production cluster'ları işletiyor.

Bunu production'da mı çalıştırıyorsunuz? AWS Yönetilen Hizmetler ekibimiz böyle ortamları 7/24 işletiyor — izleme, olay müdahalesi, yama ve maliyet kontrolü, ismen bildiğiniz kıdemli mühendislerle, aylık €3.000'den başlayan fiyatlarla.

Etiketler: #Kubernetes #K8s #DevOps #Debugging #EKS #Güvenlik #CloudNative