Tipik Hata Ekranı / Typical Error Screen

NAME                     READY   STATUS             RESTARTS   AGE
my-app-deployment-xyz    0/1     CrashLoopBackOff   5          3m

Bu ekranda RESTARTS sayısı sürekli artıyorsa ve STATUS kısmında "CrashLoopBackOff" yazıyorsa, container çöküş döngüsündedir.

Adım 1: Pod Durumunu Kontrol Edin / Check Pod Status

kubectl get pods
kubectl get pods -n <namespace>

CrashLoopBackOff durumundaki pod'ları listeler. RESTARTS sütununa bakın, kaç kez restart olduğunu görürsünüz.

Adım 2: Pod Detaylarını İnceleyin / Describe Pod

kubectl describe pod <pod-adi> -n <namespace>

Bu komut size çok değerli bilgi verir:

• Events bölümünde hata mesajları (error messages)
• Resource limits (kaynak limitleri)
• Container durumları (container states)
• Liveness/readiness probe bilgileri

Adım 3: Container Loglarını Okuyun / Read Container Logs

# Mevcut container logları
kubectl logs <pod-adi> -n <namespace>

# Önceki crash'ten kalan loglar (ÇOK ÖNEMLİ!)
kubectl logs --previous <pod-adi> -n <namespace>

# Birden fazla container varsa
kubectl logs <pod-adi> -c <container-adi> -n <namespace>

Alesta Web İpucu: --previous parametresi çok kritik! Crash olan container'ın son loglarını gösterir.

Crash'ten Önceki Logları Okuma / Read Crash Logs

kubectl logs --previous my-app-xyz -n production

Örnek çıktı:

Error: Unable to connect to database
Connection refused: postgresql://db:5432
panic: runtime error

İşte! Database'e bağlanamıyor. Sorun network veya connection string'te.

OOMKilled (Out Of Memory) Kontrolü

kubectl describe pod <pod-adi>

Events bölümünde şunu arayın:

Reason: OOMKilled
Container killed due to memory limit exceeded

Eğer bu yazıyorsa, memory limit yetersiz demektir.

Kaynak Limitlerini Artırma / Increase Resource Limits

Deployment YAML dosyanızda:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  template:
    spec:
      containers:
      - name: my-app-container
        image: my-app:latest
        resources:
          requests:
            memory: "256Mi"    # Başlangıç talebi (initial request)
            cpu: "250m"
          limits:
            memory: "512Mi"    # Maksimum limit (maximum limit)
            cpu: "500m"

Değişiklik sonrası:

kubectl apply -f deployment.yaml

ConfigMap/Secret Var mı Kontrol Edin / Check If ConfigMap Exists

kubectl get configmaps -n <namespace>
kubectl get secrets -n <namespace>

Beklediğiniz ConfigMap/Secret listede yoksa oluşturun:

# ConfigMap oluştur
kubectl create configmap my-config --from-file=config.yaml -n production

# Secret oluştur
kubectl create secret generic my-secret --from-literal=password=abc123 -n production

Pod'da ConfigMap Kullanımı / Using ConfigMap in Pod

apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  containers:
  - name: app
    image: my-app:latest
    envFrom:
    - configMapRef:
        name: my-config      # ConfigMap adı (ConfigMap name)
    volumeMounts:
    - name: config-volume
      mountPath: /etc/config
  volumes:
  - name: config-volume
    configMap:
      name: my-config

Yanlış Liveness Probe Örneği / Incorrect Liveness Probe

livenessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 5      # ⚠️ Çok kısa! (Too short!)
  periodSeconds: 5             # ⚠️ Çok sık kontrol (Too frequent)
  timeoutSeconds: 1            # ⚠️ Çok kısa timeout
  failureThreshold: 2          # ⚠️ 2 başarısızlıkta öldürür

Sorun: Uygulama başlatması 10 saniye sürüyor ama probe 5 saniyede kontrol ediyor. Uygulama henüz hazır değilken "sağlıksız" deyip öldürüyor!

Düzeltilmiş Liveness Probe / Corrected Liveness Probe

livenessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 30     # ✅ Uygulamaya başlama zamanı tanı (allow startup time)
  periodSeconds: 10            # ✅ Her 10 saniyede kontrol
  timeoutSeconds: 5            # ✅ 5 saniye timeout
  failureThreshold: 3          # ✅ 3 başarısızlık toleransı

Özellikle Java, .NET gibi ağır uygulamalarda initialDelaySeconds değeri yüksek olmalı!

Network Connectivity Test (Ağ Bağlantısı Testi)

# Pod içinde shell açın
kubectl exec -it <pod-adi> -n <namespace> -- /bin/bash

# Database'e ping atın
ping postgres-service.default.svc.cluster.local

# Port açık mı kontrol edin
nc -zv postgres-service 5432

# DNS çözümleme
nslookup postgres-service

Eğer bağlantı yoksa network policy veya service configuration hatası var demektir.

Init Container ile Dependency Bekleme / Wait for Dependencies

spec:
  initContainers:
  - name: wait-for-db
    image: busybox:latest
    command: ['sh', '-c', 'until nc -z postgres-service 5432; do echo waiting for db; sleep 2; done']
  containers:
  - name: my-app
    image: my-app:latest

Bu init container, database hazır olana kadar bekler. Uygulama container'ı ancak o zaman başlar.

Entrypoint/Command Kontrolü / Check Entrypoint

kubectl describe pod <pod-adi>

Command ve Args bölümüne bakın:

Command:
  /bin/sh
Args:
  -c
  ./start-app.sh

Eğer "./start-app.sh" dosyası image'de yoksa veya executable değilse crash olur!

Image Doğrulama / Verify Image

# Image locally çalışıyor mu?
docker run -it my-app:latest /bin/bash

# Container başlatıyor mu?
docker run my-app:latest

# Logları kontrol et
docker logs <container-id>

Eğer local'de çalışmıyorsa Kubernetes'te de çalışmaz!

1. Events Monitörleme / Monitor Events

kubectl get events --sort-by=.metadata.creationTimestamp -n <namespace>

Tüm Kubernetes event'lerini zaman sırasına göre gösterir. CrashLoopBackOff ile ilgili tüm olayları görürsünüz.

2. Debug Container Başlatma / Start Debug Container

# Kubernetes 1.23+
kubectl debug <pod-adi> -it --image=busybox --target=<container-adi>

Crash olan container'a "ephemeral container" (geçici container) ekler, debug yapmanızı sağlar.

3. Resource Usage Monitörleme / Monitor Resource Usage

kubectl top pod <pod-adi> -n <namespace>
kubectl top node

Pod'un ne kadar CPU/memory kullandığını görürsünüz. Limit aşımı varsa hemen anlaşılır.

4. Restart Policy Kontrolü / Check Restart Policy

spec:
  restartPolicy: Always    # Default - sürekli restart
  # restartPolicy: OnFailure  # Sadece hata durumunda
  # restartPolicy: Never      # Hiç restart etme

CrashLoopBackOff varsa "Always" veya "OnFailure" olmalı.