Vorbereitung von Wartungsupdates und Sicherheitsverbesserungen für den IBM Cloud-Host
Erfahren Sie, wie Sie Ihre IBM Cloud-Mitarbeiter auf Wartungsupdates des Hosts vorbereiten, Unterbrechungen minimieren und sicherstellen können, dass Sicherheitsverbesserungen reibungslos umgesetzt werden.
IBM Techniker führen Wartungsarbeiten an den Hosts durch, um die Stabilität zu verbessern, Sicherheitserweiterungen bereitzustellen und die Unterstützung für kommende neue Funktionen zu gewährleisten. IBM Cloud Infrastrukturanbieter führen Wartungsarbeiten an den Hosts durch, auf denen die Virtual Servers gehostet werden, die als Worker in Ihrem Cluster verwendet werden. Dies kann dazu führen, dass einige Ihrer Worker kurzzeitig offline gehen. Es gibt jedoch Aktionen, die Sie vor der Wartungszeit ausführen können, um Unterbrechungen der Workerknoten zu minimieren. Vor dem Wartungsfenster wird eine Benachrichtigung mit Wartungsdetails und einer Liste der betroffenen Mitarbeiter an Kunden gesendet. Führen Sie die folgenden Schritte aus, um Ihre Mitarbeiter auf einen bevorstehenden Wartungszeitraum vorzubereiten.
Betroffene Mitarbeiter identifizieren
Wenn für Ihre Mitarbeiter eine Wartung geplant ist, erhalten Sie eine Benachrichtigung, bevor das Wartungsfenster beginnt. Eine Liste der betroffenen Mitarbeiter ist in der Benachrichtigung enthalten.
Die Liste der betroffenen Komponenten könnte ähnlich wie im folgenden Beispiel aussehen. Die hier dokumentierten Schritte gelten für die Worker, die im Abschnitt IBM Kubernetes Service oder Red Hat OpenShift in IBM Cloud Workers aufgelistet sind.
**Virtual Server Instances scheduled for maintenance**
Virtual Server Instances in your account:
ID Name
1111_1a111aaa-1a1a-1aa1-1111-a11a111a1111 my_vpc_cluster_1
Virtual Server Instances in service accounts:
Application Load Balancer
alb-11aa111a-1111111
IBM Kubernetes Service or Red Hat OpenShift on IBM Cloud workers
kube-aaaa1aaa111aa11aa11a-aaaaaaaaaaa-aaaaaaa-00001a11
kube-aaaa2aaa222aa22aa22a-aaaaaaaaaaa-aaaaaaa-00002a22
kube-aaaa3aaa333aa33aa33a-aaaaaaaaaaa-aaaaaaa-00003a33
Aktionen, die vor der Wartungszeit ausgeführt werden müssen
Führen Sie die folgenden Schritte aus, um Ihre Mitarbeiter für den Wartungszeitraum vorzubereiten. Worker können nicht auf Hosts geplant werden, die für die Wartung geplant sind. Sie können Unterbrechungen Ihrer Workload vermeiden, indem Sie Ihre Worker neu starten oder ersetzen, sodass sie auf andere Hosts verschoben werden, die nicht gewartet werden.
Worker in Classic-Clustern
Führen Sie die Schritte zum Neustart des Workers aus, bevor der Wartungszeitraum beginnt.
-
Hängen Sie den Worker an.
oc adm cordon <worker_id> -
Bereinigen Sie den Worker.
Beispiel für einen Ablassbefehl
oc adm drain <worker_id>Beispiel Ablassbefehl für Cloud Pak for Data
oc adm drain <worker_id> --force --delete-emptydir-data --ignore-daemonsets -
Starten Sie den Worker neu. Achten Sie darauf, dass Sie die Option
--hardangeben.ibmcloud oc worker reboot --cluster <cluster_name_or_id> --worker <worker_id> --hard -
Markieren Sie den Worker als für die Planung verfügbar.
oc adm uncordon <worker_id>
Worker in VPC-Clustern
Für Worker in VPC-Clustern hängen die auszuführenden Schritte vom Typ des Workerknotens ab. Führen Sie ibmcloud oc worker get --worker <worker_id> --cluster <cluster_name_or_id> aus, um den Typ eines Workerknotens
zu überprüfen.
Für VPC-Virtual-Server-Instance-Worker (VSI-Worker) (Worker ohne lokalen Speicher):
-
Hängen Sie den Worker an.
oc adm cordon <worker_id> -
Bereinigen Sie den Worker. In einigen Fällen, wie z. B. Cloud Pak for Data, müssen Sie möglicherweise zusätzliche Abflussoptionen angeben.
Beispiel für einen Ablassbefehl
oc adm drain <worker_id>Beispiel Ablassbefehl für Cloud Pak for Data
oc adm drain <worker_id> --force --delete-emptydir-data --ignore-daemonsets -
Ersetzen Sie den Worker.
ibmcloud oc worker replace --cluster <cluster_name_or_id> --worker <worker_id> -
Markieren Sie den Worker als für die Planung verfügbar.
oc adm uncordon <worker_id>
Für VPC-Bare-Metal-Mitarbeiter:
VPC-Bare-Metal-Worker unterstützen den Befehl worker reload, der den Knoten an Ort und Stelle neu lädt, ohne einen neuen Worker-Knoten bereitzustellen. Der Knoten behält seine IP-Adresse und andere Identifikatoren bei. Wenn ein
Firmware-Update ansteht, wird es im Rahmen des Neustarts automatisch durchgeführt und kann die Gesamtdauer des Neustarts um 30 Minuten oder mehr verlängern. Wenn Ihr Bare-Metal-Worker über lokalen Speicher verfügt, sichern Sie alle Daten,
die nicht auf persistenten Speichermedien gespeichert sind, bevor Sie beginnen, da Daten auf lokalen Festplatten bei einem Reload verloren gehen.
Teil 1: Vorbereiten des Workers für die Wartung
-
Falls Ihr Worker über lokalen Speicher verfügt, sichern Sie alle Daten, die Sie behalten möchten, bevor Sie fortfahren. Daten auf lokalen Festplatten gehen bei einem Neuladen verloren.
-
Den Worker sperren, um zu verhindern, dass neue Workloads darauf eingeplant werden.
oc adm cordon <worker_id> -
Leeren Sie den Worker, um vorhandene Workloads zu entfernen. In einigen Fällen, wie z. B. Cloud Pak for Data, müssen Sie möglicherweise zusätzliche Abflussoptionen angeben.
Beispiel für einen Ablassbefehl
oc adm drain <worker_id>Beispiel Ablassbefehl für Cloud Pak for Data
oc adm drain <worker_id> --force --delete-emptydir-data --ignore-daemonsets
Teil 2: Wartung durchführen
-
Den Worker neu laden. Der Knoten wird an Ort und Stelle auf einem Host neu geladen, der sich nicht in Wartung befindet, und behält dabei seine IP-Adresse bei.
ibmcloud oc worker reload --cluster <cluster_name_or_id> --worker <worker_id>Alternativ können Sie den Worker ersetzen, anstatt ihn neu zu laden. Durch das Ersetzen des Workers wird der vorhandene Knoten gelöscht und ein neuer Knoten mit einer neuen IP-Adresse bereitgestellt.
ibmcloud oc worker replace --cluster <cluster_name_or_id> --worker <worker_id>