Allgemeinzustand, Status und Zustand des Masters überprüfen

Cluster- und Master-Staaten

Erläuterungen zu den Auswirkungen eines Masterausfalls

Der Red Hat OpenShift-Master ist die Hauptkomponente, die für die Betriebsbereitschaft des Clusters sorgt. Der Master speichert Clusterressourcen und ihre Konfigurationen in der etcd-Datenbank, die als Single Point of Truth für Ihren Cluster dient. Der Red Hat OpenShift-API-Server dient als Haupteinstiegspunkt für alle Anforderungen der Clusterverwaltung von den Workerknoten zum Master oder wird für die Interaktion mit den Clusterressourcen verwendet.

Wenn ein Masterfehler auftritt, werden Ihre Workloads weiterhin auf den Workerknoten ausgeführt, aber Sie können keine oc-Befehle verwenden, um mit Ihren Clusterressourcen zu arbeiten oder den Clusterzustand anzuzeigen, bis der Red Hat OpenShift-API-Server im Master wieder aktiv ist. Wenn ein Pod während des Masterausfalls inaktiv wird, kann der Pod erst neu geplant werden, wenn der Workerknoten den Red Hat OpenShift-API-Server wieder erreichen kann.

Während eines Ausfalls des Masters können Sie ibmcloud oc-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.