Kubernetes Pod Pending Hatası: 6 Sebep ve Çözümleri (2025 Rehber)

Pending Durumunu Kontrol Etme (Check Pending Status)

kubectl get pods

# Çıktı örneği:
NAME                     READY   STATUS    RESTARTS   AGE
my-app-7d4b8c9f5-xkzlp   0/1     Pending   0          5m

Gördüğünüz gibi (as you can see), pod "Pending" durumunda ve READY kolonu 0/1 gösteriyor. Bu sorun çözülmeli (this issue needs to be resolved).

Pod Detaylarını İnceleyin (Inspect Pod Details)

kubectl describe pod <pod-name>

# Örnek:
kubectl describe pod my-app-7d4b8c9f5-xkzlp

Bu komut size çok detaylı bilgi verir (gives you very detailed information). En önemlisi "Events" bölümü!

Events Bölümü Örneği (Events Section Example)

Events:
  Type     Reason            Message
  ----     ------            -------
  Warning  FailedScheduling  0/3 nodes are available: insufficient cpu.
  Warning  FailedScheduling  0/3 nodes are available: 1 node(s) had taint {key=value},
                             that the pod didn't tolerate.

İşte sorunun kaynağı! (Here's the source of the problem!) Yukarıdaki örnekte CPU yetersiz (insufficient CPU) veya node taint sorunu var.

Node Kaynaklarını Kontrol Edin (Check Node Resources)

kubectl describe nodes

# Özet bilgi için:
kubectl top nodes

Bu komutlar size her node'un CPU ve memory kullanımını gösterir (shows CPU and memory usage of each node).

Çözüm Seçenekleri / Solution Options:

Seçenek 1: Pod Resource Request'lerini Azaltın

# deployment.yaml dosyasını düzenleyin
apiVersion: apps/v1
kind: Deployment
spec:
  template:
    spec:
      containers:
      - name: my-app
        image: my-app:1.0
        resources:
          requests:
            memory: "256Mi"  # 4Gi yerine 256Mi
            cpu: "250m"      # 1000m yerine 250m

Seçenek 2: Cluster'a Yeni Node Ekleyin (Add New Node to Cluster)

# Eğer cloud provider kullanıyorsanız:
# AWS EKS
eksctl scale nodegroup --cluster=my-cluster --name=my-nodegroup --nodes=5

# GKE
gcloud container clusters resize my-cluster --num-nodes=5

# Azure AKS
az aks scale --resource-group myRG --name myCluster --node-count 5

Yeni node ekleyince (after adding new nodes) Kubernetes otomatik olarak pending pod'ları oraya yerleştirecektir.

Node Taint'lerini Kontrol Edin (Check Node Taints)

kubectl describe node <node-name> | grep Taints

# Örnek çıktı:
Taints: dedicated=gpu:NoSchedule

Bu durumda (in this case), sadece GPU tolerasyonu olan pod'lar bu node'a atanabilir (only pods with GPU toleration can be assigned).

Çözüm: Toleration Ekleyin (Add Toleration)

# deployment.yaml
apiVersion: apps/v1
kind: Deployment
spec:
  template:
    spec:
      tolerations:
      - key: "dedicated"
        operator: "Equal"
        value: "gpu"
        effect: "NoSchedule"
      containers:
      - name: my-app
        image: my-app:1.0

Artık pod bu taint'li node'a atanabilir (now pod can be assigned to this tainted node).

Alternatif: Taint'i Kaldırın (Remove Taint)

kubectl taint nodes <node-name> dedicated=gpu:NoSchedule-

# '-' işareti taint'i kaldırır (minus sign removes taint)

Ancak dikkatli olun! Eğer node özel bir amaç için (for a special purpose) ayrılmışsa taint'i kaldırmak sorun yaratabilir.

PVC Durumunu Kontrol Edin (Check PVC Status)

kubectl get pvc

# Çıktı:
NAME        STATUS    VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   AGE
my-pvc      Pending   ...      ...        ...            standard       5m

Eğer PVC "Pending" durumundaysa (if PVC is in pending state), pod da başlayamaz (pod also cannot start).

PVC Detaylarını İnceleyin (Inspect PVC Details)

kubectl describe pvc my-pvc

# Events bölümüne bakın:
Events:
  Type     Reason              Message
  ----     ------              -------
  Warning  ProvisioningFailed  Failed to provision volume: no volume plugin matched

Çözüm Yöntemleri / Solution Methods:

1. StorageClass Var mı Kontrol Edin (Check if StorageClass Exists)

kubectl get storageclass

# Eğer yoksa oluşturun (if not exists, create):
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: standard
provisioner: kubernetes.io/aws-ebs  # Cloud provider'a göre değişir
parameters:
  type: gp2

2. Manuel PersistentVolume Oluşturun (Create Manual PV)

apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-pv
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: "/mnt/data"

Ama dikkat! hostPath sadece test için uygun (hostPath only suitable for testing). Production'da cloud storage kullanın (use cloud storage in production).

NodeSelector Kontrolü (NodeSelector Check)

kubectl get pod <pod-name> -o yaml | grep -A 5 nodeSelector

# Çıktı:
nodeSelector:
  disktype: ssd
  region: us-east

Pod sadece "disktype=ssd" ve "region=us-east" label'lı node'lara atanabilir (pod can only be assigned to nodes with these labels).

Uygun Node Var mı? (Is There a Matching Node?)

kubectl get nodes --show-labels | grep "disktype=ssd"

# Eğer çıktı boşsa, uygun node yok!

Çözüm 1: Node'a Label Ekleyin (Add Label to Node)

kubectl label nodes <node-name> disktype=ssd region=us-east

Çözüm 2: NodeSelector'ı Kaldırın veya Değiştirin (Remove or Modify NodeSelector)

kubectl edit deployment my-app

# nodeSelector kısmını silin veya düzenleyin
# Sonra kaydedin (:wq)

Image Pull Durumu (Image Pull Status)

kubectl describe pod <pod-name> | grep -A 10 Events

Events:
  Warning  Failed     Failed to pull image "my-registry/my-app:latest":
           rpc error: code = Unknown desc = Error response from daemon:
           pull access denied

Çözüm: ImagePullSecret Ekleyin (Add ImagePullSecret)

# Önce secret oluşturun
kubectl create secret docker-registry my-registry-secret \
  --docker-server=my-registry.com \
  --docker-username=myuser \
  --docker-password=mypassword

# Sonra deployment'a ekleyin:
spec:
  template:
    spec:
      imagePullSecrets:
      - name: my-registry-secret

Scheduler Durumu (Scheduler Status)

kubectl get pods -n kube-system | grep scheduler

# Çıktı:
kube-scheduler-master-1   1/1   Running   0   5d

Eğer scheduler "Running" değilse (if scheduler is not running), sorun burada!

Scheduler Log'larını İnceleyin (Check Scheduler Logs)

kubectl logs -n kube-system kube-scheduler-master-1

Log'larda error mesajları arayın (search for error messages in logs).

Çözüm: Scheduler'ı Yeniden Başlatın (Restart Scheduler)

kubectl delete pod -n kube-system kube-scheduler-master-1

# Kubernetes otomatik olarak yenisini oluşturur
# (Kubernetes automatically creates a new one)