Allgemeinzustand, Status und Zustand des Masters überprüfen

Cluster- und Master-Staaten

Erläuterungen zu den Auswirkungen eines Masterausfalls

Der Kubernetes-Master ist die Hauptkomponente, die den Cluster betriebsbereit hält. Der Master speichert Clusterressourcen und ihre Konfigurationen in der etcd-Datenbank, die als Single Point of Truth für Ihren Cluster dient. Der Kubernetes-API-Server dient als Haupteinstiegspunkt für alle Anforderungen der Clusterverwaltung von den Workerknoten zum Master oder wenn Sie mit Ihren Clusterressourcen interagieren möchten.

Wenn der Master ausfällt, werden Ihre Workloads auf den Workerknoten weiterhin ausgeführt, Sie können jedoch keine Befehle kubectl verwenden, um mit Ihren Clusterressourcen zu arbeiten oder den Clusterzustand anzuzeigen, bis der Kubernetes-API-Server im Master wieder betriebsbereit ist. Wenn beim Ausfall des Masters ein Pod inaktiv wird, kann der Pod erst neu geplant werden, wenn der Workerknoten den Kubernetes-API-Server wieder erreichen kann.

Während eines Masterausfalls können Sie ibmcloud ks-Befehle weiterhin für die IBM Cloud Kubernetes Service-API ausführen, um mit Ihren Infrastrukturressourcen zu arbeiten (z. B. Workerknoten oder VLANs). Wenn Sie die aktuelle Clusterkonfiguration ändern, indem Sie Workerknoten zum Cluster hinzufügen oder entfernen, werden Ihre Änderungen erst wirksam, wenn der Master wieder aktiv ist.

Ein Workerknoten darf während eines Masterausfalls nicht neu gestartet werden. Durch diese Aktion werden die Pods aus dem Workerknoten entfernt. Da der Kubernetes-API-Server nicht verfügbar ist, können die Pods nicht auf anderen Workerknoten im Cluster neu geplant werden.