--- # source: blog-content: posts/de/iaas-control-plane-api-inaccessible.md # route: /de/insights/iaas-control-plane-api-inaccessible/ title: IaaS Control Plane – API inaccessible date: 2024-11-12 author: matthias-grasmueck locale: de summary: 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. capabilities: [containers, cloud] vendors: [vmware] series: lessons-learned hero: /blog-assets/iaas-control-plane-api-inaccessible/hero.webp legacySlug: iaas-control-plane-api-inaccessible migrated: 2026-08-24 draft: false --- In unserem Lab wurde vor kurzem der [Supervisor Cluster](https://docs.vmware.com/en/VMware-vSphere/8.0/vsphere-with-tanzu-concepts-planning/GUID-3E4E6039-BD24-4C40-8575-5AA0EECBBBEC.html) unserer [VMware IaaS Control Plane](https://docs.vmware.com/en/VMware-vSphere/8.0/vsphere-with-tanzu-concepts-planning/GUID-70CAF0BB-1722-4526-9CE7-D5C92C15D7D0.html#GUID-70CAF0BB-1722-4526-9CE7-D5C92C15D7D0) Plattform (ehem. vSphere with Tanzu) auf die Version [vSphere 8.0 Update 3](https://docs.vmware.com/en/VMware-vSphere/8.0/rn/vmware-vsphere-with-tanzu-80-release-notes/index.html#What's%20New-What's%20New%20June%2025,%202024) 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 wurden, 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 Services 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: ```bash crictl ps | grep -iE 'etcd|kube-api' ``` Da der kube-api Service nur läuft, wenn auch der etcd Service aktiv ist, habe ich die Logs des etcd Service verifiziert: ```bash 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: ```bash 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: ```bash 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: ```bash 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: ```bash 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: | VM | Rolle | Management-IP | VIP | etcd Member | | --- | --- | --- | --- | --- | | 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: 1. Remove first non-leader cpVM via vCenter UI > Administration > vCenter Server Extensions > vSphere ESX Agent Manager > Configure > vmware-vcs-apiserver-hv4ntr > Delete Agency 2. Wait until new cpVM SupervisorControlPlaneVM (4) is provisioned and cluster is healthy state. 3. 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 4. Wait until new cpVM SupervisorControlPlaneVM (5) is provisioned and cluster is healthy state. 5. 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 6. 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.