CKA Troubleshooting: 15 häufige Cluster-Probleme lösen

1. Was ist der aktuelle Status?     */} kubectl get / kubectl describe
2. Was sagen die Events?            */} kubectl describe (Events-Sektion)
3. Was sagen die Logs?              */} kubectl logs / journalctl
4. Was ist die Ursache?             */} Konfiguration pruefen
5. Fix anwenden und verifizieren    */} kubectl apply / systemctl restart

# Pod-Status pruefen
kubectl get pod pending-pod -o wide

# Events pruefen -- hier steht fast immer die Ursache
kubectl describe pod pending-pod

# Ursache 1: Nicht genuegend Ressourcen
# Event: "Insufficient cpu" oder "Insufficient memory"
# Fix: Requests/Limits anpassen oder Nodes hinzufuegen
kubectl edit pod pending-pod  # Wenn moeglich
# Oder: Deployment anpassen
kubectl edit deployment my-app

# Ursache 2: Node-Selector oder Affinity passt nicht
# Event: "0/3 nodes are available: 3 node(s) didn't match node selector"
# Fix: Label auf Node setzen
kubectl label node worker-1 disktype=ssd

# Ursache 3: Taints verhindern Scheduling
# Event: "0/3 nodes are available: 3 node(s) had taint {key: value}"
# Fix: Toleration im Pod hinzufuegen oder Taint entfernen
kubectl taint nodes worker-1 key=value:NoSchedule-

# Status und Restart-Count pruefen
kubectl get pod crash-pod

# Container-Logs pruefen (aktueller Versuch)
kubectl logs crash-pod

# Logs des vorherigen Versuchs
kubectl logs crash-pod --previous

# Detaillierte Informationen
kubectl describe pod crash-pod

# Ursache 1: Fehlerhafter Command oder Args
kubectl get pod crash-pod -o yaml | grep -A5 "command:"
# Fix: Command korrigieren

# Ursache 2: Fehlende Umgebungsvariablen oder ConfigMap
kubectl describe pod crash-pod | grep -A10 "Environment:"
# Fix: ConfigMap oder Secret erstellen/korrigieren

# Ursache 3: Liveness Probe schlaegt fehl
kubectl describe pod crash-pod | grep -A5 "Liveness:"
# Fix: Probe-Konfiguration anpassen (initialDelaySeconds erhoehen)

# Ursache 4: Anwendung braucht eine Datenbank-Verbindung, die nicht verfuegbar ist
kubectl logs crash-pod | grep -i "connection\|error\|failed"

kubectl describe pod image-pod | grep -A10 "Events:"
# Typische Events:
# "Failed to pull image": Image existiert nicht oder Tag falsch
# "unauthorized": Fehlende Zugangsdaten fuer private Registry

# Ursache 1: Image-Name oder Tag falsch
kubectl get pod image-pod -o jsonpath='{.spec.containers[0].image}'
# Fix: Image-Name korrigieren
kubectl set image pod/image-pod app=nginx:1.27

# Ursache 2: Private Registry ohne imagePullSecret
kubectl create secret docker-registry regcred \
  --docker-server=registry.example.com \
  --docker-username=user \
  --docker-password=pass

# Secret im Pod referenzieren (YAML editieren)
# spec.imagePullSecrets:
#   - name: regcred

# Service pruefen
kubectl get svc my-service
kubectl describe svc my-service

# Endpoints pruefen -- DAS ist der entscheidende Check
kubectl get endpoints my-service

# Wenn Endpoints leer: Label-Mismatch!
kubectl get pods --show-labels

# Ursache 1: Label-Selector stimmt nicht ueberein
# Service-Selector pruefen
kubectl get svc my-service -o jsonpath='{.spec.selector}'
# Pod-Labels pruefen
kubectl get pods -l app=my-app

# Fix: Label anpassen
kubectl label pod my-pod app=my-app --overwrite

# Ursache 2: Falscher targetPort
kubectl get svc my-service -o yaml | grep -A3 "ports:"
# Fix: targetPort muss mit dem containerPort uebereinstimmen

# Ursache 3: Pod ist nicht Ready (Readiness Probe schlaegt fehl)
kubectl get pods -o wide | grep -v Running
kubectl describe pod my-pod | grep -A5 "Readiness:"

# Node-Status pruefen
kubectl get nodes
kubectl describe node worker-1

# Conditions pruefen
kubectl get node worker-1 -o jsonpath='{.status.conditions}' | python3 -m json.tool

# Auf dem betroffenen Node (per SSH):

# Ursache 1: Kubelet laeuft nicht
sudo systemctl status kubelet
sudo journalctl -u kubelet --no-pager | tail -30
# Fix:
sudo systemctl start kubelet
sudo systemctl enable kubelet

# Ursache 2: Container Runtime gestoppt
sudo systemctl status containerd
# Fix:
sudo systemctl start containerd

# Ursache 3: Festplatte voll
df -h
# Fix: Nicht benoetigte Images und Logs entfernen
sudo crictl rmi --prune
sudo journalctl --vacuum-size=500M

# etcd-Pod pruefen (kubeadm-Cluster)
kubectl get pods -n kube-system | grep etcd
kubectl logs -n kube-system etcd-controlplane

# etcd-Health-Check
ETCDCTL_API=3 etcdctl endpoint health \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key

# Ursache 1: etcd-Datenverzeichnis beschaedigt
# Backup wiederherstellen
ETCDCTL_API=3 etcdctl snapshot restore /tmp/etcd-backup.db \
  --data-dir=/var/lib/etcd-restored

# etcd-Manifest anpassen (Datenverzeichnis aendern)
sudo vi /etc/kubernetes/manifests/etcd.yaml
# volumes.hostPath.path auf /var/lib/etcd-restored aendern

# Ursache 2: Falsche Zertifikate
ls -la /etc/kubernetes/pki/etcd/
# Zertifikate pruefen
openssl x509 -in /etc/kubernetes/pki/etcd/server.crt -noout -dates

# SSH auf den Node
# kubelet-Status pruefen
sudo systemctl status kubelet
sudo journalctl -u kubelet --no-pager | tail -50

# Haeufige Fehler in den Logs:

# Fehler 1: Falsche kubelet-Konfiguration
# "unable to load bootstrap kubeconfig"
sudo cat /var/lib/kubelet/config.yaml
# Fix: Konfiguration korrigieren

# Fehler 2: Swap ist aktiviert
sudo swapon --show
# Fix: Swap deaktivieren
sudo swapoff -a
# Dauerhaft: /etc/fstab editieren und Swap-Zeile auskommentieren

# Fehler 3: Container Runtime Socket nicht erreichbar
# "connection refused" fuer containerd
sudo systemctl restart containerd
sudo systemctl restart kubelet

# Alle Zertifikate und Ablaufdaten pruefen
sudo kubeadm certs check-expiration

# Einzelnes Zertifikat pruefen
openssl x509 -in /etc/kubernetes/pki/apiserver.crt -noout -dates

# Alle Zertifikate erneuern
sudo kubeadm certs renew all

# Control-Plane-Komponenten neu starten
sudo systemctl restart kubelet

# Alternativ: Static Pods werden automatisch neu gestartet, wenn sich
# die Manifeste aendern. Pruefen, ob die Pods neu starten:
kubectl get pods -n kube-system

# CoreDNS-Status pruefen
kubectl get pods -n kube-system -l k8s-app=kube-dns
kubectl logs -n kube-system -l k8s-app=kube-dns

# DNS-Test aus einem Pod heraus
kubectl run dns-test --image=busybox:1.36 --rm -it --restart=Never -- nslookup kubernetes.default

# CoreDNS-ConfigMap pruefen
kubectl get configmap coredns -n kube-system -o yaml

# Ursache 1: CoreDNS-Pods im CrashLoopBackOff
kubectl describe pod -n kube-system -l k8s-app=kube-dns
# Haeufig: Loop-Detection-Problem
# Fix: "loop" Plugin aus CoreDNS-ConfigMap entfernen
kubectl edit configmap coredns -n kube-system
# "loop" Zeile entfernen und CoreDNS-Pods neu starten
kubectl rollout restart deployment coredns -n kube-system

# Ursache 2: CoreDNS-Service fehlt oder hat falsche ClusterIP
kubectl get svc kube-dns -n kube-system
# Fix: Service neu erstellen falls noetig

# Ursache 3: Node DNS-Konfiguration fehlerhaft
cat /etc/resolv.conf  # Auf dem Node pruefen

# PVC-Status pruefen
kubectl get pvc
kubectl describe pvc my-pvc

# Verfuegbare PersistentVolumes pruefen
kubectl get pv

# StorageClass pruefen
kubectl get storageclass

# Ursache 1: Kein passendes PV vorhanden
# PV erstellen (bei statischer Provisionierung)
kubectl apply -f - << 'PVEOF'
apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-pv
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: /data/my-pv
PVEOF

# Ursache 2: StorageClass existiert nicht
kubectl get storageclass
# Fix: StorageClass erstellen oder PVC auf existierende StorageClass aendern

# Ursache 3: Access Mode stimmt nicht ueberein
# PV hat ReadWriteOnce, PVC verlangt ReadWriteMany
# Fix: Access Mode im PV oder PVC anpassen

# Ingress-Status pruefen
kubectl get ingress
kubectl describe ingress my-ingress

# Ingress Controller pruefen
kubectl get pods -n ingress-nginx
kubectl logs -n ingress-nginx -l app.kubernetes.io/name=ingress-nginx

# Backend-Service pruefen
kubectl get svc my-service
kubectl get endpoints my-service

# Ursache 1: Ingress Controller nicht installiert
# Ingress-Controller installieren
kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.10.0/deploy/static/provider/baremetal/deploy.yaml

# Ursache 2: Service-Name oder Port im Ingress falsch
kubectl get ingress my-ingress -o yaml
# Fix: backend.service.name und backend.service.port.number pruefen

# Ursache 3: IngressClass nicht angegeben
# Fix: ingressClassName im Ingress-Spec setzen
kubectl edit ingress my-ingress
# spec.ingressClassName: nginx

# Berechtigungen pruefen
kubectl auth can-i get pods --as system:serviceaccount:default:my-sa
kubectl auth can-i list secrets --as developer -n production

# Alle Berechtigungen eines Users pruefen
kubectl auth can-i --list --as developer -n production

# Vorhandene Roles und Bindings pruefen
kubectl get roles,rolebindings -n production
kubectl get clusterroles,clusterrolebindings | grep my-role

# Role erstellen
kubectl create role pod-reader \
  --verb=get,list,watch \
  --resource=pods \
  -n production

# RoleBinding erstellen
kubectl create rolebinding pod-reader-binding \
  --role=pod-reader \
  --serviceaccount=production:my-sa \
  -n production

# ClusterRole und ClusterRoleBinding (clusterweite Berechtigung)
kubectl create clusterrole node-reader \
  --verb=get,list,watch \
  --resource=nodes

kubectl create clusterrolebinding node-reader-binding \
  --clusterrole=node-reader \
  --user=developer

# Scheduler-Status pruefen
kubectl get pods -n kube-system | grep scheduler
kubectl logs -n kube-system kube-scheduler-controlplane

# Scheduler-Manifest pruefen (kubeadm)
sudo cat /etc/kubernetes/manifests/kube-scheduler.yaml

# Ursache 1: Scheduler-Pod im CrashLoopBackOff
kubectl logs -n kube-system kube-scheduler-controlplane --previous
# Fix: Manifest pruefen und korrigieren
sudo vi /etc/kubernetes/manifests/kube-scheduler.yaml
# Haeufig: Falscher Pfad zur kubeconfig oder falsche Port-Konfiguration

# Ursache 2: Scheduler-Manifest fehlt
ls /etc/kubernetes/manifests/kube-scheduler.yaml
# Fix: Manifest neu erstellen (von Backup oder kubeadm)

# Ursache 3: Falscher kubeconfig-Pfad
# Im Manifest pruefen:
# --kubeconfig=/etc/kubernetes/scheduler.conf
# Datei muss existieren und korrekt sein
ls -la /etc/kubernetes/scheduler.conf

# Controller Manager Status pruefen
kubectl get pods -n kube-system | grep controller-manager
kubectl logs -n kube-system kube-controller-manager-controlplane

# Manifest pruefen
sudo cat /etc/kubernetes/manifests/kube-controller-manager.yaml

# Ursache 1: Controller Manager Pod stuerzt ab
kubectl logs -n kube-system kube-controller-manager-controlplane --previous

# Haeufige Probleme im Manifest:
# - Falscher Pfad zu Zertifikaten
# - Fehlende oder falsche Flag-Werte
# - Volume-Mount zeigt auf falsches Verzeichnis

# Ursache 2: Zertifikatsproblem
sudo openssl x509 -in /etc/kubernetes/pki/controller-manager.crt -noout -dates
# Fix: Zertifikat erneuern
sudo kubeadm certs renew controller-manager.conf

# Controller Manager neu starten (Static Pod)
# Manifest kurz verschieben und zurueck:
sudo mv /etc/kubernetes/manifests/kube-controller-manager.yaml /tmp/
# 10 Sekunden warten
sudo mv /tmp/kube-controller-manager.yaml /etc/kubernetes/manifests/

# CoreDNS-Status pruefen
kubectl get pods -n kube-system -l k8s-app=kube-dns
kubectl logs -n kube-system -l k8s-app=kube-dns
kubectl describe pods -n kube-system -l k8s-app=kube-dns

# Ursache 1: Loop-Detection (haeufigste Ursache)
# CoreDNS erkennt eine DNS-Weiterleitung, die zurueck auf sich selbst zeigt
# Fix: "loop" Plugin entfernen
kubectl edit configmap coredns -n kube-system
# Zeile "loop" entfernen

# CoreDNS neu starten
kubectl rollout restart deployment coredns -n kube-system

# Ursache 2: ConfigMap beschaedigt oder geloescht
kubectl get configmap coredns -n kube-system
# Falls fehlend: ConfigMap neu erstellen
kubectl apply -f - << 'DNSEOF'
apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns
  namespace: kube-system
data:
  Corefile: |
    .:53 {
        errors
        health {
          lameduck 5s
        }
        ready
        kubernetes cluster.local in-addr.arpa ip6.arpa {
          pods insecure
          fallthrough in-addr.arpa ip6.arpa
          ttl 30
        }
        prometheus :9153
        forward . /etc/resolv.conf {
          max_concurrent 1000
        }
        cache 30
        reload
        loadbalance
    }
DNSEOF

# Ursache 3: Nicht genuegend Ressourcen
kubectl describe pods -n kube-system -l k8s-app=kube-dns | grep -A5 "Resources:"
# Fix: Resource Requests/Limits anpassen
kubectl edit deployment coredns -n kube-system

# === ALLGEMEINE DIAGNOSE ===
kubectl get pods -A                        # Alle Pods ueber alle Namespaces
kubectl get pods -o wide                   # Mit Node-Zuordnung
kubectl describe pod POD_NAME              # Details und Events
kubectl logs POD_NAME                      # Container-Logs
kubectl logs POD_NAME --previous           # Logs des vorherigen Containers
kubectl get events --sort-by=.lastTimestamp # Alle Events chronologisch

# === NODE-DIAGNOSE ===
kubectl get nodes                          # Node-Status
kubectl describe node NODE_NAME            # Node-Details
kubectl top nodes                          # Ressourcen-Auslastung

# === CONTROL PLANE ===
kubectl get pods -n kube-system            # Control-Plane-Pods
sudo systemctl status kubelet              # Kubelet-Status
sudo journalctl -u kubelet --no-pager -l   # Kubelet-Logs
sudo crictl ps                             # Container-Runtime-Status

# === NETZWERK ===
kubectl get svc                            # Services
kubectl get endpoints                      # Endpoints (Label-Match!)
kubectl get networkpolicies                # NetworkPolicies

# === STORAGE ===
kubectl get pv,pvc                         # Volumes
kubectl get storageclass                   # StorageClasses

# === RBAC ===
kubectl auth can-i VERB RESOURCE --as USER # Berechtigung pruefen
kubectl get roles,rolebindings -n NS       # Namespace-RBAC