1. GİRİŞ

Kubernetes üretim ortamlarında çalışan uygulamalar için güçlü bir orkestrasyon platformu sağlar ancak platformun kendisi ve üzerinde çalışan uygulamalar çok çeşitli başarısızlık senaryolarına açıktır. Bu makale, Kubernetes kaynaklı ve çevresel arıza türlerini mühendis perspektifiyle sınıflandırır, olası root cause'ları ve tespit yöntemlerini anlatır, operasyonel playbook'lar ile recovery adımlarını sunar. Amaç, okuyucuya arıza önleme, hızlı tespit ve güvenli kurtarma için gerçekçi, uygulanabilir tavsiyeler vermektir.

Bu neden bugün önemli?

• Dağıtık sistemlerin büyüyen karmaşıklığı, arızaların etkisini ve tespit zorluğunu artırıyor.
• Servis kesintilerinin maliyeti (iş kaybı, müşteri memnuniyeti) kritik organizasyon hedeflerini etkiliyor.
• Cloud ve Kubernetes altyapılarının doğru operasyonu için SRE ve platform ekiplerinin arıza senaryolarına hazırlığı zorunlu.

Kimler için önemli?

• SRE ve platform mühendisleri
• DevOps ekipleri ve altyapı yöneticileri
• Uygulama mühendisleri — üretim anomalileriyle karşılaşanlar

2. KAVRAMSAL TEMELLER

2.1 Arıza sınıflandırması

Kubernetes arızalarını genel olarak şu kategorilere ayırmak faydalıdır:

• Control plane arızaları: API Server, controller manager, scheduler, etcd kaynaklı problemlerdir.
• Node / runtime arızaları: Kubelet, container runtime (containerd/Docker), node donanımı veya işletim sistemi hataları.
• Ağ arızaları: CNI, DNS, ingress/egress, network partition ve latency problemleri.
• Storage ve veri katmanı arızaları: PV/PVC, CSI, snapshot ve backend storage sorunları.
• Uygulama katmanı arızaları: Memory leak, deadlock, resource starvation, sürüm uyuşmazlıkları.
• Pipeline ve tedarik zinciri arızaları: CI/CD hataları, bozuk imajlar, supply‑chain saldırıları.

2.2 Terminoloji

• DR (Disaster Recovery): Büyük çaplı arızalardan kurtarma planı ve prosesleri.
• RTO / RPO: Recovery Time Objective / Recovery Point Objective — kabul edilebilir downtime ve veri kaybı hedefleri.
• Mitigation vs Remediation: Kısa vadeli hafifletme adımları (mitigate) ile kalıcı düzeltme (remediate) arasındaki fark.

3. NASIL ÇALIŞIR? — MEKANİZMALAR VE ARIZA AKIŞLARI

3.1 Control plane arızaları ve etcd

Control plane, Kubernetes'in yönetim omurgasıdır. etcd ise tüm cluster'ın source‑of‑truth'u olduğundan; etcd erişim veya veri bozulması durumları cluster'ın tamamını felce uğratabilir. Yaygın senaryolar:

• etcd quorum kaybı: etcd node'larının bir kısmı down olduğunda quorum kaybolursa API Server yazma işlemleri başarısız olur; cluster read-only veya tamamen çalışmaz hale gelebilir.
• etcd veri bozulması: yanlış snapshot restore, disk arızası veya yetkisiz erişim sonucu veri tutarsızlığı oluşabilir.
• API Server erişim sorunu: API Server TLS sorunları, yanlış network kuralı veya load balancer probleminden dolayı erişilemez olabilir.

3.2 Node ve runtime arızaları

Node'larda donanım arızası, kernel panic, kubelet crash veya container runtime hataları gözlenebilir. Sonuçlar:

• Pod'ların Eviction (kendi kendine) veya CrashLoopBackOff durumuna düşmesi.
• Scheduler'ın pod'ları takas etmesi; ancak yetersiz kapasite varsa pod'lar pending olur.
• Node tarafında kernel yükseltme veya config değişiklikleri sonrası uyumsuzluk ve yeniden başlatma döngüleri.

3.3 Ağ arızaları ve partitioning

Network partition (split‑brain) özellikle dağıtık controller ve etcd'yi etkileyebilir. DNS veya CNI hataları uygulamalar arasında iletişim kopmalarına ve service discovery problemlerine yol açar. Örnek etkiler:

• Service'ler birbirini çözemiyor (DNS failure) → istekler hata alıyor.
• Network latency artışı → request timeout ve retry storm'lar.

3.4 Storage ve veri kaybı senaryoları

PV/PVC ilişkilendirmesi, CSI sürücüsü veya cloud storage API hataları veri erişimini bozabilir. Snapshot dönüşüm hataları veya backup stratejisi eksiklikleri veri kaybına neden olabilir.

3.5 Uygulama katmanı arızaları

Uygulama seviyesinde memory leak, thread deadlock, database connection leak veya yanlış konfigürasyon (örn. environment variable eksikliği) sık görülen sebeplerdir. Bu hatalar genelde logs ve traces analizinde ortaya çıkar.

3.6 CI/CD ve supply‑chain arızaları

Bozuk imajlar, eksik migration'lar, hatalı manifest'ler veya imza doğrulama eksikliği production incident'larına yol açar. Supply‑chain saldırıları (image poisoning) sistem güvenliğini doğrudan tehlikeye sokar.

4. GERÇEK DÜNYA SENARYOLARI — ÖRNEKLER VE ANALİZ

4.1 etcd quorum kaybı — nedenler ve kurtarma

Senaryo: Üç üyeli etcd cluster'ından biri disk arızası nedeniyle düşer, ikinci üyede network sorunu oluşur — quorum kaybolur. Sonuç: API Server yazma işlemleri reddeder, controller'lar yeni state üretemez.

Kurtarma adımları:

1. Hızlı analiz: etcd member list, member health komutları ile quorum durumunu doğrulayın.
2. Eğer bir member geri getirilemiyorsa, sağlıklı üyelerden snapshot alıp yeni etcd cluster'ı bootstrap edin (but be careful with data loss).
3. Restore sonrası API Server'ları yeniden başlatarak cluster stabilitesini kontrol edin; uygulama katmanında reschedule gerekip gerekmediğini değerlendirin.

4.2 Network partition ve DNS çözümleme hatası

Senaryo: CNI güncellemesi sonrası belirli node'larda pod'lar DNS sorgularında zaman aşımına uğruyor. Uygulamalar downstream servislere bağlanamıyor.

Tespit ve müdahale:

• CoreDNS pod'larındaki logları ve readiness durumunu kontrol edin; CoreDNS resource'larını scaling gerekebilir.
• Node seviyesinde /etc/resolv.conf ve kubelet DNS config'lerini inceleyin; CNI konfigurasyon rollback gerekebilir.
• Anomaly detection: sudden increase in DNS latency metric'leriyle hızlı alarm kurun.

4.3 Stateful service storage corruption

Senaryo: Storage backend'te bir region outage oluşur, PV'ler erişilemez hâle gelir. Veritabanı replica set'leri degrade olur.

Adımlar:

1. Failover planı çalıştırın: read replica'ları promoted etmek veya DR bölgesinde restore başlatmak.
2. Snapshot'lar ile veri tutarlılığı kontrol edilerek restore işlemi yapılmalı.
3. Post‑mortem: snapshot frequency, replication ve RPO hedefleri gözden geçirilmelidir.

5. AVANTAJLAR VE SINIRLAMALAR — DAYANIKLILIK TASARIMININ SINIRLARI

Avantajlar

• Kubernetes ile built‑in recovery mekanizmaları (restart, reschedule) birçok transient hatayı otomatik çözer.
• Declarative altyapı ve GitOps ile hızlı rollback ve sürüm takibi mümkündür.
• Operator'lar ve controllers ile domain‑specific recovery otomasyonu oluşturulabilir.

Sınırlamalar

• etcd veya control plane bozulmaları tüm cluster'ı etkiler — platform bağımlılığı yüksek.
• Complex failure modes: cascading failures (ör. network→API→autoscaler) tanımlanması zor olabilir.
• Recovery süreçleri çoğunlukla insan müdahalesi ve coordination gerektirir; otomasyon her şeyin yerini alamaz.

6. ALTERNATİFLER VE KARŞILAŞTIRMA

7. EN İYİ PRATİKLER — PREVENTION, DETECTION, RECOVERY

7.1 Prevention (Önleme)

• etcd için HA ve quorum korunması; düzenli snapshot ve restore testleri.
• Immutable infrastructure, immutability-first deployment ve image signing ile supply‑chain risklerini azaltma.
• NetworkPolicy ve konsept olarak default‑deny yaklaşımı ile lateral movement'ı engelleme.

7.2 Detection (Tespit)

• Comprehensive observability: metrics, logs, traces; high‑quality SLI/SLO'lar.
• Health checks (readiness/liveness), kube‑state‑metrics ve node exporter ile altyapı izleme.
• Alert engineering: meaningful alerts, avoid alert fatigue.

7.3 Recovery (Kurtarma)

• Runbook'lar, playbook'lar ve otomatik remediation script'leri; insan müdahalesi için checklists.
• Failover testleri, chaos engineering ile proaktif arıza keşfi ve iyileştirme.
• Disaster Recovery planları: RTO/RPO hedefleri netleştirilmiş olmalı.

8. SIK YAPILAN HATALAR

• etcd snapshot alıp restore testini yapmadan sadece snapshot'a güvenmek.
• Observability eksikliği: logs/trace bağlantılarının olmaması root cause analysis'i geciktirir.
• CI/CD'de imaj taraması ve imza doğrulama olmadan üretime geçmek.
• PR ve değişiklik yönetimi eksikliği: control plane veya CNI gibi kritik bileşenlerde doğrudan değişiklik yapmak.

9. GELECEK TRENDLER

1. AI‑assisted RCA: Telemetry verilerinden anomali ve root cause önerileri üreten modeller yaygınlaşacak.
2. eBPF tabanlı hızla tespit: Kernel seviyesinde gözlem ile sorun tespiti daha hızlı ve doğruluklu olacak.
3. Policy as code ve otomatik healing: Rego/OPA temelli kurallar ile belirli arızalara otomatik müdahale pattern'leri artacak.

EK BÖLÜMLER

Sık Sorulan Sorular (FAQ)

1. 1. etcd quorum kaybı nasıl önlenir?

   etcd üyelerini tek bir availability zone'a yerleştirmemek, düzenli snapshot ve restore testleri, quorum sayısını cluster boyutuna göre planlamak ve monitoring ile erken uyarı kurmak gerekir.

2. 2. Node failure durumunda uygulamalar hemen kurtarılır mı?

   Scheduler, uygun kaynak varsa pod'ları başka node'lara yeniden planlar; ancak resource yetersizse pod'lar pending olur. Bu nedenle node pool kapasitesi ve Cluster Autoscaler konfigürasyonu kritik.

3. 3. Network partition tespitini nasıl otomatikleştirebilirim?

   Service mesh telemetry, CNI metrikleri, CoreDNS latency, ve synthetic checks (canary probes) ile network partition veya yüksek latency erken tespit edilebilir.

4. 4. CI/CD kaynaklı hatalardan nasıl korunurum?

   Image scanning, SBOM, image signing, ve staging/canary rollout ile hatalı imajların prod'a ulaşması engellenir. Ayrıca admission controller ile imzalı olmayan image'lara izin vermeyin.

5. 5. Backup ve restore testlerini ne sıklıkla yapmalıyım?

   Critical sistemler için haftalık veya günlük restore testi önerilir; restore adımlarının otomatikleştirilmiş bir test matrisine dahil edilmesi en iyisidir.

6. 6. Chaos engineering arıza hazırlığında nasıl yardımcı olur?

   Öngörülemeyen failure mode'ları ortaya çıkarır; runbook'ların yeterliliğini test eder ve otomatik remediation tetiklerini doğrular.

7. 7. Arıza sonrası postmortem'de hangi veriler önemlidir?

   Timeline (event sequence), logs/traces, metrics snapshot, değişiklik geçmişi (deploy/manifest commits) ve operator action kayıtları postmortem için temel veri setidir.

8. 8. Production güvenliğini garanti edebilir miyiz?

   Hiçbir sistem %100 güvenli değildir. Ama defense‑in‑depth, testing, automation, ve SRE pratikleri ile riskleri kabul edilebilir seviyeye çekmek mümkündür.

Anahtar Kavramlar

etcd quorum

etcd cluster'ında karar için gereken minimum üye sayısı; quorum kaybı cluster'ı etkiler.

RTO / RPO

Recovery Time Objective / Recovery Point Objective — kurtarma zaman ve veri kaybı hedefleri.

Descheduler

Node dengesizliği veya bin‑packing sonrası podları yeniden dağıtan yardımcı araç.

Chaos engineering

Sistem dayanıklılığını test etmek için kontrollü arıza üretme pratiği.

Admission controller

API Server isteklerini doğrulayan veya değiştiren modüller — supply‑chain güvenliği için kullanılabilir.

Öğrenme Yol Haritası

1. 0–1 ay: Kubernetes temel bileşenleri, etcd, API Server, kubelet ve CNI hakkında bilgi edinin.
2. 1–3 ay: Observability kurulumu (Prometheus, OpenTelemetry), temel recovery adımları ve snapshot/restore pratiği yapın.
3. 3–6 ay: Chaos engineering uygulamaları, DR planlama, canary rollout ve otomatik remediation senaryoları üzerinde çalışın.
4. 6–12 ay: Büyük ölçekli arıza senaryoları, multi‑region DR ve AI‑assisted RCA araçlarıyla deneyim kazanın.