DIABOLIKSS
RehberlerKubernetes/OpenShift Pod Hataları: CrashLoopBackOff, PVC Binding ve Çözümleri
Sorun Giderme · Kubernetes / OpenShift

Kubernetes/OpenShift Pod Hataları:CrashLoopBackOff, PVC Binding ve Çözümleri

Kubernetes 1.2xOpenShift 4.xTemmuz 2026

Pod sürekli yeniden başlıyor, ImagePullBackOff hatası veriyor ya da PVC "Pending" durumunda takılı kalıyor. Bu rehber, en sık karşılaşılan pod ve storage hatalarını kök nedenleriyle sıralıyor.

01

CrashLoopBackOff

Bu, en sık karşılaşılan pod hatasıdır: konteyner başlıyor, hemen çöküyor, Kubernetes yeniden başlatmayı deniyor ve bu döngü tekrarlanıyor.

Olası NedenKontrol
Uygulama başlangıç hatası (config, bağımlılık eksik)kubectl logs <pod> --previous ile çökme öncesi logu inceleyin
Liveness probe çok agresifUygulama tam başlamadan liveness probe onu öldürüyor olabilir, initialDelaySeconds ayarını artırın
Kaynak yetersizliğiPod, tanımlı CPU/memory limitini aşıyor olabilir
02

ImagePullBackOff / ErrImagePull

  • İmaj adı ve tag'in doğru yazıldığını doğrulayın (yaygın hata: typo)
  • Private registry kullanılıyorsa, imagePullSecrets tanımının pod spec'inde doğru olduğunu kontrol edin
  • Registry'ye node'lardan ağ erişimi olduğunu doğrulayın (firewall, DNS çözümleme)
  • İmajın gerçekten o tag ile registry'de mevcut olduğunu doğrulayın
  • 03

    PVC Pending Durumu

    PersistentVolumeClaim (PVC), talep edilen depolamayı bir PersistentVolume'a bağlayamadığında "Pending" durumunda kalır.

    NedenÇözüm
    Uygun StorageClass tanımlı değilPVC'nin talep ettiği StorageClass'ın cluster'da var olduğunu doğrulayın
    Dynamic provisioning başarısız[Kubernetes persistent storage](/rehber/kubernetes-persistent-storage-longhorn-ceph-portworx) katmanının (Longhorn, Rook-Ceph, Portworx) sağlıklı çalıştığını doğrulayın
    Talep edilen kapasite mevcut depolamadan büyükDepolama havuzunun gerçek boş kapasitesini kontrol edin
    04

    OOMKilled Hatası

    Pod, tanımlı bellek limitini aştığında Kubernetes tarafından zorla sonlandırılır ve "OOMKilled" (Out Of Memory Killed) olarak işaretlenir.

    ⚠️
    Limit mi Gerçek İhtiyaç mı? OOMKilled hatası iki şekilde çözülür: ya uygulamanın gerçek bellek sızıntısı (memory leak) sorunu giderilir, ya da tanımlı memory limit gerçek ihtiyaca göre yeniden ayarlanır. Sadece limiti artırmak, altta yatan sızıntı sorununu maskeler.
    05

    Log ve Event Okuma Metodolojisi

    kubectl describe pod <pod-adı> -n <namespace>
    kubectl logs <pod-adı> -n <namespace> --previous
    kubectl get events -n <namespace> --sort-by='.lastTimestamp'

    describe komutunun sonundaki "Events" bölümü, genelde hatanın gerçek nedenini (scheduling başarısızlığı, volume mount hatası, probe hatası) doğrudan gösterir; log dosyalarına bakmadan önce her zaman buradan başlanmalıdır.

    ESH Bilişim

    Kubernetes/OpenShift Operasyonel Destek

    ESH Bilişim, Kubernetes ve OpenShift ortamlarında storage, kaynak yönetimi ve operasyonel süreç tasarımında saha deneyimiyle destek sağlar.

    KubernetesOpenShiftSorun Giderme
    ↑ Başa Dön

    Adım Takibi

    0/5
    Paylas

    Bu Rehberle İlgili AI Araçlar