- 01CrashLoopBackOff, OOMKilled ve Node NotReady kök neden değil belirtidir; log, event, condition ve telemetry birlikte incelenmelidir.
- 02Resource request ve limit hataları OOMKilled, CPU throttling, pending pod ve dengesiz node kullanımının yaygın nedenleridir.
- 03Kubernetes DNS sorunlarında CoreDNS, kube-dns Service, EndpointSlice, resolv.conf ve NetworkPolicy zinciri birlikte kontrol edilmelidir.
- 04Production Kubernetes sağlığı yalnız CPU ve RAM ile ölçülmez; restart, deployment availability, DNS, storage, ingress ve application SLI'ları da izlenmelidir.
- 05Kubernetes upgrade, sertifika, yedekleme ve incident runbook'ları cluster kurulumundan sonra sürekli operasyon sorumluluğu olarak ele alınmalıdır.
Kısaca
Production Kubernetes ortamlarında en sık görülen operasyon sorunları genellikle uygulama kodundan çok kaynak yönetimi, node sağlığı, DNS, depolama, probe tasarımı, sürüm yaşam döngüsü ve gözlemlenebilirlik eksikliği etrafında oluşur. CrashLoopBackOff, OOMKilled, Node NotReady, Pending pod, CoreDNS problemi veya başarısız rollout gibi belirtiler tek başına kök nedeni göstermez. Dynamis Teknoloji, Raff platformunu sıfırdan geliştiren ekip olarak Kubernetes sorunlarını "komut çalıştır ve geç" yaklaşımıyla değil, belirtiyi doğru sinyallerle ilişkilendirip kalıcı nedeni ortadan kaldıracak production operasyon modeliyle ele alır.
Kubernetes production sorunları neden farklıdır?
Production ortamında sorun yalnız bir pod'un çalışmaması değildir.
Aynı problem müşteri trafiğini, deployment sürecini, database erişimini, node kapasitesini, yedekleme zincirini ve DNS çözümlemesini aynı anda etkileyebilir.
Bu nedenle troubleshooting sırasında yalnız tek kaynağa bakmak yeterli değildir.
İyi bir incident yaklaşımı şu sırayı izler:
- Kullanıcı etkisini belirle
- Belirtiyi sınıflandır
- Son değişiklikleri kontrol et
- Kubernetes event ve condition'larını incele
- Node ve workload kaynaklarını karşılaştır
- Kalıcı nedeni düzelt
- Aynı problemin tekrarını önle
CrashLoopBackOff nedir?
CrashLoopBackOff, bir konteynerin tekrar tekrar başlayıp kısa sürede kapanması ve Kubernetes'in yeniden başlatmalar arasında bekleme süresi uygulaması durumudur.
Bu durum şu nedenlerle ortaya çıkabilir:
- uygulama başlangıç hatası
- eksik environment variable
- yanlış secret
- ulaşılamayan database
- yanlış port
- başarısız liveness probe
- eksik dosya veya volume
- uygulamanın hemen kapanması
CrashLoopBackOff bir hata nedeni değil, tekrar eden restart davranışının belirtisidir.
CrashLoopBackOff nasıl teşhis edilir?
İlk bakılacak alanlar:
Pod durumu
Pod'un son termination reason bilgisini kontrol edin.
Container logları
Mevcut ve bir önceki container instance loglarını karşılaştırın.
Özellikle bir önceki instance logu restart sonrası kaybolan hatayı gösterebilir.
Events
Scheduling, image pull, volume veya probe hataları burada görünebilir.
Configuration
ConfigMap ve Secret değerlerinin doğru mount edildiğini kontrol edin.
Dependency
Application database veya external API'ye erişemiyorsa container sürekli kapanabilir.
Kalıcı çözüm restart sayısını sıfırlamak değil, uygulamanın neden kapanmaya devam ettiğini bulmaktır.
OOMKilled nedir?
OOMKilled, sürecin bellek yetersizliği nedeniyle işletim sistemi tarafından sonlandırıldığını gösterir.
Kubernetes ortamında iki yaygın senaryo vardır.
Container memory limit aşılıyor
Container tanımlı memory limit'in üzerine çıktığında process sonlandırılabilir.
Node genel olarak memory pressure yaşıyor
Node üzerindeki toplam workload bellek talebi kapasiteye yaklaşmışsa eviction ve OOM davranışları görülebilir.
Bu nedenle yalnız container limit'ine bakmak yeterli değildir.
OOMKilled olduğunda ne kontrol edilmeli?
Şu sırayla ilerleyin:
- Container memory request
- Container memory limit
- Gerçek memory working set
- Restart geçmişi
- Node memory pressure
- Uygulama memory leak ihtimali
Sorunu yalnız memory limit artırarak çözmek geçici olabilir.
Uygulama sürekli büyüyen heap veya cache kullanıyorsa daha yüksek limit yalnız hatayı geciktirir.
Resource request ve limit neden kritik?
Scheduler pod'u node'a yerleştirirken request değerlerini dikkate alır.
Limit ise workload'un kullanabileceği üst sınırı belirler.
Yanlış request node kapasitesinin verimsiz kullanılmasına, bazı node'larda aşırı yoğunluğa ve gereksiz pending pod'lara neden olabilir.
Yanlış limit OOMKilled, CPU throttling ve beklenmeyen latency oluşturabilir.
Production sizing tahmine değil, gerçek telemetry'ye dayanmalıdır.
CPU throttling nasıl fark edilir?
CPU limit çok düşükse container çalışmaya devam eder fakat CPU kullanım süresi kısıtlanabilir.
Belirtiler:
- latency artışı
- timeout
- request queue büyümesi
- CPU metriğinin beklenenden düşük görünmesi
olabilir.
Bu nedenle yalnız "CPU yüzde 100 değil" diyerek CPU problemi olmadığını varsaymayın.
Container throttling metric'lerini de izleyin.
Node NotReady ne anlama gelir?
Node NotReady, control plane'in node'u sağlıklı veya erişilebilir görmediğini gösterir.
Yaygın nedenler:
- kubelet durmuş
- container runtime çalışmıyor
- network bağlantısı kesilmiş
- node kaynak baskısı altında
- disk dolmuş
- kernel veya OS problemi
- node yeniden başlatılmış
Node NotReady olduğunda problem yalnız o node'u etkilemeyebilir.
Üzerindeki workload'ların başka node'lara taşınması gerekebilir.
Node pressure condition'ları nelerdir?
Kubernetes node condition'ları arasında MemoryPressure, DiskPressure, PIDPressure ve Ready önemlidir.
Node controller bu condition'lara göre taint uygulayabilir.
Örneğin disk pressure oluştuğunda yeni pod scheduling engellenebilir ve mevcut workload eviction riski yaşayabilir.
DiskPressure neden oluşur?
DiskPressure yalnız application data nedeniyle oluşmaz.
Yaygın nedenler:
- container logları
- kullanılmayan image'lar
- ephemeral storage
- temp file'lar
- container runtime data
- host logları
Bu nedenle disk alarmı geldiğinde yalnız PersistentVolume kullanımına bakmayın.
Node filesystem ve container runtime alanlarını ayrı izleyin.
Pending pod neden oluşur?
Pending pod, scheduler'ın pod için uygun node bulamadığını gösterebilir.
Yaygın nedenler:
- yetersiz CPU
- yetersiz RAM
- taint/toleration uyuşmazlığı
- nodeSelector
- affinity kuralı
- uygun PersistentVolume yok
- topology constraint
- PVC bekliyor
İlk kontrol Pod Events olmalıdır.
Scheduler çoğu zaman neden placement yapılamadığını event mesajında açıkça belirtir.
ImagePullBackOff neden olur?
ImagePullBackOff, node'un container image'ını registry'den çekemediğini gösterir.
Yaygın nedenler:
- image tag yanlış
- image yok
- registry credential hatalı
- private registry erişilemiyor
- DNS problemi
- rate limit
Kalıcı çözüm için image naming ve registry authentication pipeline içinde doğrulanmalıdır.
Production deployment'ın ilk kez cluster üzerinde image doğrulaması yapması gereksiz risk yaratır.
Probe hataları neden outage yaratabilir?
Liveness, readiness ve startup probe'ları yanlış tasarlanırsa sağlıklı uygulamayı production dışına çıkarabilir.
Readiness probe
Pod'un trafiğe hazır olup olmadığını belirler.
Liveness probe
Uygulamanın restart edilmesi gerekip gerekmediğini belirler.
Startup probe
Yavaş başlayan uygulamalarda liveness ve readiness kontrolleri başlamadan önce başlangıç süresi sağlar.
Liveness probe'a external database kontrolü koymak gibi tasarımlar database kısa süreli erişilemediğinde bütün pod'ların restart edilmesine neden olabilir.
Kubernetes DNS sorunları neden kritiktir?
Kubernetes workload'ları servisleri çoğu zaman DNS üzerinden bulur.
DNS bozulduğunda database hostname çözülmez, service-to-service trafik kesilir, external API erişimi etkilenir ve uygulama timeout üretebilir.
Application logları bu durumda yalnız "connection failed" gösterebilir.
Kök neden CoreDNS olabilir.
DNS troubleshooting nasıl yapılır?
İlk kontroller:
- Pod içinden hedef Service DNS adını sorgula
- resolv.conf içeriğini kontrol et
- kube-dns Service'i kontrol et
- CoreDNS pod durumunu kontrol et
- CoreDNS loglarını incele
- EndpointSlice kayıtlarını doğrula
- NetworkPolicy'nin DNS trafiğini engellemediğinden emin ol
Namespace kaynaklı DNS farklarını da kontrol edin.
my-service aynı namespace içinde çözülebilirken başka namespace'den FQDN gerekebilir.
Service var ama trafik neden gitmiyor?
Service objesinin varlığı backend'in çalıştığını garanti etmez.
Kontrol edin:
- selector doğru mu?
- EndpointSlice içinde pod IP'leri var mı?
- pod readiness başarılı mı?
- targetPort doğru mu?
- uygulama gerçekten o portta dinliyor mu?
- NetworkPolicy trafiği engelliyor mu?
Service troubleshooting'de Service YAML'dan sonra endpoint verisine bakmak gerekir.
Ingress veya Gateway 502/503 neden verir?
Yaygın nedenler:
- backend pod hazır değil
- Service endpoint yok
- yanlış port
- timeout
- TLS configuration
- ingress controller kaynak yetersizliği
- upstream application error
HTTP 502 veya 503 her zaman ingress controller arızası anlamına gelmez.
Request zincirini Load balancer → Ingress/Gateway → Service → Pod → Application sırasıyla takip edin.
PersistentVolume problemleri nasıl görünür?
Depolama sorunları şu belirtileri oluşturabilir:
- pod Pending
- mount timeout
- filesystem read-only
- attach failure
- StatefulSet rollout durması
- application I/O error
Kontrol alanları:
- PVC status
- StorageClass
- CSI driver
- volume attachment
- availability zone
- node placement
Özellikle zonal volume ile pod farklı availability zone'a schedule edilirse attach problemi oluşabilir.
StatefulSet sorunları neden daha risklidir?
Stateless pod yeniden yaratıldığında çoğu zaman trafik başka replica'ya yönlendirilebilir.
Stateful workload'da veri bütünlüğü, volume attachment, replica ordering ve quorum önemlidir.
Bu nedenle database gibi stateful servislerde self-healing ifadesi dikkatli kullanılmalıdır.
Kubernetes pod'u yeniden başlatabilir, ancak database'in veri consistency ve replication modelini sizin yerinize tasarlamaz.
Deployment rollout neden takılır?
Rollout şu nedenlerle tamamlanmayabilir:
- yeni pod readiness geçemiyor
- image pull başarısız
- kaynak kapasitesi yok
- config hatalı
- PodDisruptionBudget
- affinity constraint
- application startup süresi yüksek
Deployment status ve ReplicaSet dağılımını kontrol edin.
Yeni sürüm sağlıklı değilse rollout'u devam ettirmek yerine önce rollback kriterinizi uygulayın.
Kubernetes upgrade neden production riski taşır?
Kubernetes minor sürümleri sürekli yaşam döngüsü takibi gerektirir.
Yükseltme sırasında kontrol edilmesi gerekenler:
- kaldırılan API'ler
- ingress/controller compatibility
- CSI/CNI desteği
- Helm chart'lar
- admission webhook'lar
- node OS/runtime
- backup
- rollback
Production cluster'da doğrudan control plane yükseltmesi yapmadan önce staging veya düşük riskli cluster üzerinde doğrulama yapılmalıdır.
Kubernetes'e geçiş rehberi cluster yaşam döngüsünü migration sonrası sürekli operasyon olarak ele alır.
Certificate sorunları neden sessizce büyür?
Kubernetes ekosisteminde çok sayıda certificate bulunabilir:
- API server
- kubelet
- ingress TLS
- internal service certificate
- webhook certificate
Sona yaklaşan sertifika izlenmiyorsa problem doğrudan outage olarak ortaya çıkabilir.
Certificate expiration monitoring production baseline'ın parçası olmalıdır.
NetworkPolicy yanlışlığı nasıl anlaşılır?
NetworkPolicy sorunlarında pod sağlıklı görünür ancak belirli bağlantılar başarısız olabilir.
Örneğin API database'e erişemiyor, DNS sorgusu çıkamıyor veya monitoring agent telemetry gönderemiyor olabilir.
Policy değişikliklerini deployment gibi review edin.
Geniş kapsamlı deny kuralını doğrudan production'a uygulamak yerine kontrollü rollout yapın.
HPA neden beklediğiniz gibi scale etmiyor?
Horizontal Pod Autoscaler çalışsa bile uygulama doğru scale etmeyebilir.
Yaygın nedenler:
- resource request tanımlı değil
- metric gelmiyor
- yanlış target
- startup sırasında metric dalgalanıyor
- bottleneck CPU değil
- yeni pod hazır olmadan trafik artıyor
Örneğin application database connection limiti nedeniyle yavaşsa daha fazla pod açmak problemi büyütebilir.
Autoscaling metriği gerçek bottleneck ile ilişkili olmalıdır.
Gözlemlenebilirlik eksikliği neden en büyük operasyon sorunlarından biridir?
Yeterli telemetry yoksa incident sırasında ekip tahminle hareket eder.
Production Kubernetes için en az şu sinyaller görünür olmalıdır:
Node
- Ready durumu
- CPU
- memory
- disk
- network
Pod
- restart
- OOMKilled
- Pending
- readiness
- throttling
Deployment
- available replica
- rollout status
Platform
- API error
- CoreDNS
- ingress latency
- storage
Application
- request rate
- error rate
- latency
- kritik transaction
Observability nedir? telemetry katmanını ayrıntılı olarak açıklar.
Alert yorgunluğu Kubernetes ortamında nasıl oluşur?
Her pod restart'ına alarm açmak kısa sürede gürültü yaratabilir.
İyi alarm kullanıcı etkisiyle ilişkili, aksiyon alınabilir, owner'ı belli ve tekrarları gruplanmış olmalıdır.
Örneğin tek pod restart'ı yerine "Deployment available replica sayısı 10 dakika boyunca hedefin altında" daha anlamlı olabilir.
Incident sırasında hangi sırayla bakmalısınız?
Adım 1: Kullanıcı etkisini belirleyin
Hangi servis, müşteri veya endpoint etkileniyor?
Adım 2: Son değişikliği kontrol edin
Yeni deployment, config veya infrastructure değişikliği var mı?
Adım 3: Deployment ve pod durumuna bakın
Available replica, restart ve event'leri kontrol edin.
Adım 4: Node condition'larını kontrol edin
Problem tek pod değil node kaynaklı olabilir.
Adım 5: DNS ve network zincirini doğrulayın
Service ve endpoint katmanını kontrol edin.
Adım 6: Storage'ı kontrol edin
Stateful workload varsa volume ve CSI durumuna bakın.
Adım 7: Telemetry'yi korele edin
Metric, log ve trace sinyallerini aynı zaman aralığında inceleyin.
Adım 8: Stabilize edin
Rollback, scale veya traffic shift ile kullanıcı etkisini azaltın.
Adım 9: Kök nedeni kapatın
Incident sonrası kalıcı düzeltme ve preventif kontrol ekleyin.
Runbook neden gereklidir?
Tekrarlanan production sorunları kişisel hafızaya bırakılmamalıdır.
Runbook içinde belirti, kontrol sırası, dashboard, komut, rollback, escalation ve owner bulunmalıdır.
Örneğin Node NotReady için aynı ekip her seferinde sıfırdan araştırma yapmamalıdır.
Dynamis'te Kubernetes operasyon yaklaşımı
Dynamis'in DevOps hizmeti kapsamında production Kubernetes operasyonunu yalnız cluster kurulumu olarak ele almıyoruz.
İlk değerlendirmede:
- Kubernetes sürümü
- node yapısı
- resource request/limit
- CNI/CSI
- DNS
- ingress
- gözlemlenebilirlik
- yedekleme
- sertifikalar
- upgrade durumu
- incident geçmişi
incelenir.
Ardından operasyon açıkları için dashboard, alert, runbook, upgrade planı, capacity baseline, backup/restore ve incident ownership oluşturulur.
Kubernetes ekibi kurmak mı, operasyonu dış kaynak kullanmak mı? rehberi bu operasyon sahipliğinin kimde kalacağını ayrıca karşılaştırır.
Sık yapılan hatalar
CrashLoopBackOff'u kök neden sanmak: Restart davranışının nedenini log, event ve configuration ile bulun.
OOMKilled olduğunda yalnız limit artırmak: Gerçek memory kullanımı ve memory leak ihtimalini kontrol edin.
Node NotReady sorununu yalnız pod seviyesinde araştırmak: Kubelet, runtime ve node pressure condition'larına bakın.
DNS problemi varken application kodunu değiştirmek: Önce CoreDNS, Service ve resolv.conf zincirini doğrulayın.
Yalnız CPU/RAM izlemek: Restart, availability, DNS, storage ve application SLI'larını da takip edin.
Upgrade'i bir defalık proje sanmak: Kubernetes sürüm yaşam döngüsünü sürekli operasyon takvimine bağlayın.
Sırada ne var
- Kubernetes nedir?: pod, node, Service ve control plane kavramlarını temel seviyede inceleyin.
- Kubernetes'e geçiş rehberi: production'a geçmeden önce operasyon baseline'ını kurun.
- Kubernetes ekibi kurmak mı, operasyonu dış kaynak kullanmak mı?: production sahipliğini ve nöbet modelini belirleyin.
- DevOps hizmeti: mevcut Kubernetes operasyon sorunlarınızı değerlendirin.
Kaynaklar
Kaynaklar
- 1.Pod lifecycleKubernetes · 2026-09-22
- 2.Resource management for Pods and containersKubernetes · 2026-09-22
- 3.Node-pressure evictionKubernetes · 2026-09-22
- 4.Debugging DNS resolutionKubernetes · 2026-09-22
- 5.Debug ServicesKubernetes · 2026-09-22
Sık sorulan sorular
Kubernetes'te CrashLoopBackOff neden olur?
CrashLoopBackOff, bir konteynerin tekrar tekrar başlayıp kısa sürede kapanması ve Kubernetes'in yeniden başlatmalar arasında bekleme süresi uygulaması durumudur. Yaygın nedenler uygulama hatası, eksik yapılandırma, yanlış secret, başarısız liveness probe, erişilemeyen bağımlılık veya uygulamanın beklenen portta açılmamasıdır.
Kubernetes'te OOMKilled ne anlama gelir?
OOMKilled, konteyner veya node üzerindeki bellek baskısı nedeniyle Linux OOM killer'ın süreci sonlandırdığını gösterir. Container memory limit'i aşıldığında veya node genel olarak bellek baskısı yaşadığında oluşabilir. Requests, limits, gerçek bellek kullanımı ve uygulama davranışı birlikte incelenmelidir.
Kubernetes Node NotReady olduğunda ne kontrol edilmeli?
Önce node condition, kubelet durumu, ağ erişimi, disk ve bellek baskısı, container runtime ve node heartbeat kontrol edilmelidir. Kubernetes node controller not-ready, unreachable, memory-pressure ve disk-pressure gibi durumlarda taint uygulayabilir ve workload'ların başka node'lara taşınması gündeme gelebilir.
Kubernetes DNS sorunu nasıl teşhis edilir?
Pod içinden Service DNS adıyla sorgu yapın, resolv.conf içeriğini kontrol edin, kube-dns Service ve CoreDNS pod'larının çalıştığını doğrulayın ve DNS EndpointSlice kayıtlarını inceleyin. Namespace farkı, yanlış search domain, NetworkPolicy veya CoreDNS problemi servis çözümlemesini bozabilir.
Production Kubernetes için en önemli izleme sinyalleri nelerdir?
Node hazır olma durumu, CPU ve bellek doygunluğu, pod restart sayısı, OOMKilled olayları, pending pod'lar, deployment availability, API error rate, ingress latency, storage kullanımı ve kritik uygulama SLI'ları birlikte izlenmelidir. Yalnız altyapı metric'leri production sağlığını göstermek için yeterli değildir.