Work in Progress
"Komplexe Systeme neigen zu komplexen Fehlern..." war mal ein Zitat eines Informatik Professors. Das gilt leider auch für Kubernetes. Glücklicherweise gibt es aber Tools, mit denen man die Probleme zumindest bis auf Pod Ebene lokalisieren kann.
Wenn es in Kubernetes ein Problem gibt, dann wirkt sich das i.d.R. auf irgnedwelche Pods aus. Mit
kubectl get pods --all-namespaces
NAMESPACE NAME READY STATUS RESTARTS AGE
hello-zone hello-world-7764ddd79-fmb76 1/1 Running 0 69m
hello-zone hello-world-7764ddd79-lzfjq 1/1 Running 0 69m
kube-system calico-kube-controllers-744cfdf676-dxp9p 1/1 Running 0 75m
kube-system calico-node-wfn4c 1/1 Running 0 75m
kube-system coredns-694d7767d4-8zms6 1/1 Running 0 82m
kube-system coredns-694d7767d4-tmhlf 1/1 Running 0 82m
kube-system etcd-x1-kubic 1/1 Running 0 82m
kube-system kube-apiserver-x1-kubic 1/1 Running 0 82m
kube-system kube-controller-manager-x1-kubic 1/1 Running 0 82m
kube-system kube-proxy-q52mp 1/1 Running 0 82m
kube-system kube-scheduler-x1-kubic 1/1 Running 0 82m
metallb-system controller-65db86ddc6-6m7rx 1/1 Running 0 72m
metallb-system speaker-mlp2m 1/1 Running 0 72m
nginx-ingress-zone my-nginx-release-ingress-nginx-controller-865d5864b-82ltm 1/1 Running 0 37s
nginx-ingress-zone my-nginx-release-ingress-nginx-controller-865d5864b-dlbrp 1/1 Running 0 53s
Steht da etwas anderes als "running", dann hat man schon einen Überblick, was nicht läuft. Bei Pods, die aus dem Status "Pending" nicht rauskommen, lohnt sich ein näherer Blick. Kritisch wird es dann, wenn einer der Pods im Namespace "kube-system" oder auch hier "metallb-system"
Schauen wir uns einen Nginx Pod mal näher an:
kubectl describe pod/my-nginx-release-ingress-nginx-controller-865d5864b-82ltm -n nginx-ingress-zone
Name: my-nginx-release-ingress-nginx-controller-865d5864b-82ltm
Namespace: nginx-ingress-zone
Priority: 0
Node: x1-kubic/192.168.47.16
Start Time: Mon, 14 Dec 2020 19:05:14 +0000
Labels: app.kubernetes.io/component=controller
app.kubernetes.io/instance=my-nginx-release
app.kubernetes.io/name=ingress-nginx
pod-template-hash=865d5864b
redeploy=1607972698
role=ingress-nginx
Annotations: cni.projectcalico.org/podIP: 10.99.248.15/32
cni.projectcalico.org/podIPs: 10.99.248.15/32
Status: Running
IP: 10.99.248.15
IPs:
IP: 10.99.248.15
Controlled By: ReplicaSet/my-nginx-release-ingress-nginx-controller-865d5864b
Containers:
controller:
Container ID: cri-o://b1adce49e69f334a3af1ecb4451c3b5be0109be1a215cd9b9652846c966b1bd2
Image: k8s.gcr.io/ingress-nginx/controller:v0.41.2@sha256:1f4f402b9c14f3ae92b11ada1dfe9893a88f0faeb0b2f4b903e2c67a0c3bf0de
Image ID: k8s.gcr.io/ingress-nginx/controller@sha256:1f4f402b9c14f3ae92b11ada1dfe9893a88f0faeb0b2f4b903e2c67a0c3bf0de
Ports: 80/TCP, 443/TCP, 8443/TCP
Host Ports: 0/TCP, 0/TCP, 0/TCP
Args:
/nginx-ingress-controller
--publish-service=$(POD_NAMESPACE)/my-nginx-release-ingress-nginx-controller
--election-id=ingress-controller-leader
--ingress-class=nginx
--configmap=$(POD_NAMESPACE)/my-nginx-release-ingress-nginx-controller
--validating-webhook=:8443
--validating-webhook-certificate=/usr/local/certificates/cert
--validating-webhook-key=/usr/local/certificates/key
State: Running
Started: Mon, 14 Dec 2020 19:05:15 +0000
Ready: True
Restart Count: 0
Requests:
cpu: 100m
memory: 90Mi
Liveness: http-get http://:10254/healthz delay=10s timeout=1s period=10s #success=1 #failure=5
Readiness: http-get http://:10254/healthz delay=10s timeout=1s period=10s #success=1 #failure=3
Environment:
POD_NAME: my-nginx-release-ingress-nginx-controller-865d5864b-82ltm (v1:metadata.name)
POD_NAMESPACE: nginx-ingress-zone (v1:metadata.namespace)
LD_PRELOAD: /usr/local/lib/libmimalloc.so
Mounts:
/usr/local/certificates/ from webhook-cert (ro)
/var/run/secrets/kubernetes.io/serviceaccount from my-nginx-release-ingress-nginx-token-xswbh (ro)
Conditions:
Type Status
Initialized True
Ready True
ContainersReady True
PodScheduled True
Volumes:
webhook-cert:
Type: Secret (a volume populated by a Secret)
SecretName: my-nginx-release-ingress-nginx-admission
Optional: false
my-nginx-release-ingress-nginx-token-xswbh:
Type: Secret (a volume populated by a Secret)
SecretName: my-nginx-release-ingress-nginx-token-xswbh
Optional: false
QoS Class: Burstable
Node-Selectors: kubernetes.io/os=linux
Tolerations: node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 16m default-scheduler Successfully assigned nginx-ingress-zone/my-nginx-release-ingress-nginx-controller-865d5864b-82ltm to x1-kubic
Normal Pulled 16m kubelet Container image "k8s.gcr.io/ingress-nginx/controller:v0.41.2@sha256:1f4f402b9c14f3ae92b11ada1dfe9893a88f0faeb0b2f4b903e2c67a0c3bf0de" already present on machine
Normal Created 16m kubelet Created container controller
Normal Started 16m kubelet Started container controller
Normal RELOAD 15m nginx-ingress-controller NGINX reload triggered due to a change in configuration
Interessant sind dabei insbesondere die Events. Wenn etwas schief gegangen ist, dann findet sich dort meist die Antwort, was nicht geklappt hat. Die Angaben unter den Labels können z.B. für das Debugging von Network-Policies interessant sein. Oft ist ein Type im Label die Ursache dafür, wenn eine Policy nicht greift.
Im Abschnitt Debugging wird gezeigt, wie man an die Nginx Logs kommt.
Falls die Anwendung innerhalb des Pods Probleme macht, dann merkt das Kubernetes wahrscheinlich nicht, so lang der Pod dadurch nicht terminiert. Wenn die Anwendung nicht in ihrem Log schon sagt, was ihr fehlt, dann muss man in den Pod rein gehen. Auch das geht mit Kubernetes:
kubectl get pods -n hello-zone kubectl exec -it hello-world-5bcbc5f697-4dbj9 -n hello-zone -- /bin/bash
Nun kann man mit der bash nachsehen, was los ist.