IaaS Control Plane – API inaccessible
In unserem Lab wurde vor kurzem der Supervisor Cluster unserer VMware IaaS Control Plane Plattform (ehem. vSphere with Tanzu) auf die Version vSphere 8.0 Update 3 aktualisiert. Dabei hat während dem Upgrade alles wie erwartet funktioniert und der Supervisor Cluster, wie auch die Kubernetes (Guest) Cluster waren funktionstüchtig.
Das Problem
Nach einiger Zeit war der kubectl Zugriff auf unsere Kubernetes Cluster nicht mehr möglich. Der Config Status des Supervisor Cluster meldete zudem folgende Fehlermeldung:
Initialized vSphere resources Deployed Control Plane VMs Configured Control Plane VMs Configured Load Balancer fronting the kubernetes API Server Configured Core Supervisor Services Service: velero.vsphere.vmware.com. Status: Configuring Service: tkg.vsphere.vmware.com. Reason: Reconciling. Message: Reconciling.
Sämtliche Services, welche auf den Kubernetes (Guest) Cluster betrieben wurde, waren weiterhin erreichbar. Auch waren die kube-api VIPs der Kubernetes Cluster weiterhin adressierbar.
Bei genauerer Betrachtung stellte ich fest, dass die Authentifizierung an unserem Supervisor Cluster nicht mehr funktionierte. Daraufhin wollte ich via kubectl auf den Supervisor Control Plane VMs (kurz: cpVM) prüfen, ob alle Service noch wie erwartet aktiv sind. Allerdings konnte ich mich nicht über die Supervisor VIP anmelden, woraufhin ich mich direkt über eine Management IP-Adresse einer der drei cpVMs via SSH einwählte.
Zum Erstaunen stellte ich fest, dass weder der kube-api noch der etcd Service aktiv waren:
crictl ps | grep -iE 'etcd|kubec-api'
Da der kube-api Service nur läuft, wenn auch der etcd Service aktiv ist, habe ich die Logs des etcd Service verifiziert:
cat /var/log/pods/kube-system_etcd-4233ab1d5ddccf36bc5bba316d1972b0_654c066164da8fbdd6d33ad93af301dc/etcd/10364.log
stderr F {"level":"warn","ts":"2024-10-08T18:22:39.077642Z","caller":"wal/repair.go:81","msg":"failed to copy","from":"/var/lib/etcd/member/wal/0000000000000181-000000001c149b6d.wal.broken","to":"/var/lib/etcd/member/wal/0000000000000181-000000001c149b6d.wal","error":"write /var/lib/etcd/member/wal/0000000000000181-000000001c149b6d.wal.broken: no space left on device"}
Der Fehler […]no space left on device[…] lieferte dabei den ausschlaggebenden Punkt.
Daraufhin habe ich überprüft, ob genügend Speicherplatz auf der vDisk der cpVM vorhanden ist:
df -h | grep /dev/root /dev/root 32G 32G 0 100% /
Somit konnte ich annehmen, dass eine mögliche Ursache für das Problem, dass die Services nicht starteten, auf den fehlenden Speicherplatz zurückzuführen ist. Ich habe den Speicherplatz auf allen drei cpVMs überprüft und auf allen war die Auslastung bei 100% oder 99%.
Die Lösung
Damit die Services wieder starten können, musste ich Speicherplatz zurückgewinnen. Eine einfache Suche nach den 10 grössten Files ergab folgendes:
find / -path /proc -prune -o -type f -exec du -Sh {} + | sort -rh | head -n 10
1.1G /var/log/vmware/upgrade-ctl-cli.log.1
884M /var/log/vmware/svchost/stderr.log
730M /var/log/vmware/upgrade-ctl-cli.log
385M /var/log/vmware/audit/kube-apiserver.log
307M /var/log/vmware/fluentbit/consolidated.log
250M /storage/container-registry/docker/registry/v2/blobs/sha256/a0/a0dd531132ecd058d0b0249cf2f32cecccdfbe8d13cfb93b75101aafcd2a50a6/data
248M /var/lib/containerd/io.containerd.content.v1.content/blobs/sha256/4364e490859d064c9434f9e480d74bc62402a0d812480201d644a4ea9d7ff6c3
248M /storage/container-registry/docker/registry/v2/blobs/sha256/43/4364e490859d064c9434f9e480d74bc62402a0d812480201d644a4ea9d7ff6c3/data
234M /var/lib/containerd/io.containerd.content.v1.content/blobs/sha256/fcb275778b51abf28182241bffffc6f9a25861f29ed844d71364f59e4485fb1e
234M /storage/container-registry/docker/registry/v2/blobs/sha256/fc/fcb275778b51abf28182241bffffc6f9a25861f29ed844d71364f59e4485fb1e/data
Danach habe ich die Log Files überschrieben:
echo > /var/log/vmware/upgrade-ctl-cli.log.1 echo > /var/log/vmware/svchost/stderr.log echo > /var/log/vmware/upgrade-ctl-cli.log echo > /var/log/vmware/audit/kube-apiserver.log echo > /var/log/vmware/fluentbit/consolidated.log
Das Löschen der Log Files hat auf allen drei cpVMs genügend Speicherplatz zurückgewonnen, damit der etcd und kube-api Service gestartet werden konnten. Allerdings verringerte sich der Speicherplatz und nach einiger Zeit war das Problem wieder da. Daraufhin habe ich dieselbe Prozedur durchgeführt und gewartet bis der Cluster wieder in einem healthy Status war.
Anschliessend habe ich den etcd Status verifiziert und den Leader ermittelt:
etcdctl member list -w table +------------------+---------+----------------------------------+----------------------------+----------------------------+------------+ | ID | STATUS | NAME | PEER ADDRS | CLIENT ADDRS | IS LEARNER | +------------------+---------+----------------------------------+----------------------------+----------------------------+------------+ | 10a00138f3a1ed4f | started | 421dd5792ebae985affbca516bb385c7 | https://172.16.100.11:2380 | https://172.16.100.11:2379 | false | | 7546e437eef94d66 | started | 421d85be9b7ab8b9dad06f0c6487d976 | https://172.16.100.12:2380 | https://172.16.100.12:2379 | false | | dec23b7a3b3cc58a | started | 421d411b9b2dca2e5176b3ff2dd4b66f | https://172.16.100.13:2380 | https://172.16.100.13:2379 | false | +------------------+---------+----------------------------------+----------------------------+----------------------------+------------+ # Check the endpoint status of all members and get the leader. etcdctl --endpoints=https://172.16.100.11:2379,https://172.16.100.12:2379,https://172.16.100.13:2379 -w table endpoint status +----------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+ | ENDPOINT | ID | VERSION | DB SIZE | IS LEADER | IS LEARNER | RAFT TERM | RAFT INDEX | RAFT APPLIED INDEX | ERRORS | +----------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+ | https://172.16.100.11:2379 | 10a00138f3a1ed4f | 3.5.11 | 164 MB | false | false | 318 | 668808659 | 668808659 | | | https://172.16.100.12:2379 | 7546e437eef94d66 | 3.5.11 | 164 MB | true | false | 318 | 668808659 | 668808659 | | | https://172.16.100.13:2379 | dec23b7a3b3cc58a | 3.5.11 | 165 MB | false | false | 318 | 668808659 | 668808659 | | +----------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+ # Check the endpoint health of all members. etcdctl --endpoints=https://172.16.100.11:2379,https://172.16.100.12:2379,https://172.16.100.13:2379 -w table endpoint health +----------------------------+--------+-------------+-------+ | ENDPOINT | HEALTH | TOOK | ERROR | +----------------------------+--------+-------------+-------+ | https://172.16.100.11:2379 | true | 15.673792ms | | | https://172.16.100.11:2379 | true | 17.78887ms | | | https://172.16.100.11:2379 | true | 15.571392ms | | +----------------------------+--------+-------------+-------+
Um das Problem nachhaltig zu lösen, habe ich anschliessend alle cpVM neu erstellen lassen, in dem ich die EAM Agency nacheinander entfernt habe.
Das Entfernen der EAM Agency hat die Löschung der referenzierten Supervisor Control Plane VM zur Folge. Daher sollte diese Aktion in einer produktiven Umgebung nur unter Regie und auf ausdrücklicher Anweisung des VMware Supports durchgeführt werden.
Dazu habe ich mir alle Infos von den cpVM zusammengetragen:
vmware-vsc-apiserver-hv4ntr SupervisorControlPlaneVM (1) 172.16.100.11 421dd5792ebae985affbca516bb385c7
vmware-vsc-apiserver-dhpm69 SupervisorControlPlaneVM (2) 172.16.100.12 172.16.100.10 421d85be9b7ab8b9dad06f0c6487d976 <— etcd Leader
vmware-vsc-apiserver-dfll6t SupervisorControlPlaneVM (3) 172.16.100.13 421d411b9b2dca2e5176b3ff2dd4b66f
Dazu habe ich eine cpVM nach der anderen gem. nachfolgender Prozedur entfernt:
- Remove first non-leader cpVM via vCenter UI > Administration > vCenter Server Extensions > vSphere ESX Agent Manager > Configure > vmware-vcs-apiserver-hv4ntr > Delete Agency
- Wait until new cpVM SupervisorControlPlaneVM (4) is provisioned and cluster is healthy state.
- Repeat with step 1 by removing second non-leader cpVM via vCenter UI > Administration > vCenter Server Extensions > vSphere ESX Agent Manager > Configure > vmware-vcs-apiserver-dfll6t > Delete Agency
- Wait until new cpVM SupervisorControlPlaneVM (5) is provisioned and cluster is healthy state.
- Repeat with step 1 by removing leader cpVM via vCenter UI > Administration > vCenter Server Extensions > vSphere ESX Agent Manager > Configure > vmware-vcs-apiserver-dhpm69 > Delete Agency
- Wait until new cpVM SupervisorControlPlaneVM (6) is provisioned and cluster is healthy state.
Nach dem alle drei cpVM neu erstellt waren, hat sich auch deren Diskauslastung normalisiert und das Problem war gelöst.
Leave a Reply