Ersetzen eines Steuerungsebenenknotens
ZUSAMMENFASSUNG Erfahren Sie, wie Sie einen fehlerhaften Knoten in einem OpenShift-Cluster identifizieren und ersetzen.
Um einen Knoten der Steuerungsebene zu ersetzen, müssen Sie zunächst den fehlerhaften Knoten identifizieren und entfernen. Nachdem Sie den fehlerhaften Knoten entfernt haben, können Sie den neuen Ersatzknoten hinzufügen.
Wir stellen diese Beispielverfahren rein zu Informationszwecken zur Verfügung. Informationen zum offiziellen Verfahren finden Sie in der Red Hat OpenShift-Dokumentation (https://docs.openshift.com/).
Entfernen eines fehlerhaften Knotens der Steuerungsebene
Gehen Sie wie folgt vor, um einen fehlerhaften Knoten der Steuerungsebene zu identifizieren und zu entfernen.
- Überprüfen Sie den Status der Knoten der Steuerungsebene, um das fehlerhafte Element zu identifizieren.
user@ai-client:~# oc get nodes -l node-role.kubernetes.io/master NAME STATUS ROLES AGE VERSION ocp1.mycluster.contrail.lan Ready master 16d v1.21.6+bb8d50a ocp2.mycluster.contrail.lan Ready master 16d v1.21.6+bb8d50a ocp3.mycluster.contrail.lan NotReady master 16d v1.21.6+bb8d50a
In diesem Beispiel ist ocp3 der fehlerhafte Knoten. - Sichern Sie die etcd-Datenbank auf einem der fehlerfreien Knoten, indem Sie das Verfahren unter Sichern der etcd-Datenbank befolgen.
- Listen Sie die etcd-Mitglieder auf.
user@ai-client:~# oc get pods -n openshift-etcd -o wide | grep -v etcd-quorum-guard | grep etcd etcd-ocp1 4/4 Running 0 18d 172.16.0.11 ocp1 <none> <none> etcd-ocp2 4/4 Running 0 18d 172.16.0.12 ocp2 <none> <none> etcd-ocp3 4/4 Running 0 18d 172.16.0.13 ocp3 <none> <none>
- Öffnen Sie eine Remote-Shell für einen etcd-Pod auf einem fehlerfreien Knoten (z. B. ocp1).
user@ai-client:~# oc rsh -n openshift-etcd etcd-ocp1 Defaulted container "etcdctl" out of: etcdctl, etcd, etcd-metrics, etcd-health-monitor, setup (init), etcd-ensure-env-vars (init), etcd-resources-copy (init)
- Listen Sie die etcd-Mitglieder auf.
sh-4.4# etcdctl member list -w table +------------------+---------+------+--------------------------+--------------------------+------------+ | ID | STATUS | NAME | PEER ADDRS | CLIENT ADDRS | IS LEARNER | +------------------+---------+------+--------------------------+--------------------------+------------+ | 19faf45778a1ddd3 | started | ocp3 | https://172.16.0.13:2380 | https://172.16.0.13:2379 | false | | ad4840148f3f241c | started | ocp1 | https://172.16.0.11:2380 | https://172.16.0.11:2379 | false | | b1f7a55fb3caa3b6 | started | ocp2 | https://172.16.0.12:2380 | https://172.16.0.12:2379 | false | +------------------+---------+------+--------------------------+--------------------------+------------+
- Entfernen Sie das etcd-Element auf dem fehlerhaften Knoten.
sh-4.4# etcdctl member remove 19faf45778a1ddd3 Member 19faf45778a1ddd3 removed from cluster 60f3fdb1b921fd7
- Zeigen Sie die Mitgliederliste erneut an.
sh-4.4# etcdctl member list -w table +------------------+-----------+------+--------------------------+--------------------------+------------+ | ID | STATUS | NAME | PEER ADDRS | CLIENT ADDRS | IS LEARNER | +------------------+-----------+------+--------------------------+--------------------------+------------+ | ad4840148f3f241c | started | ocp1 | https://172.16.0.11:2380 | https://172.16.0.11:2379 | false | | b1f7a55fb3caa3b6 | started | ocp2 | https://172.16.0.12:2380 | https://172.16.0.12:2379 | false | +------------------+-----------+------+--------------------------+--------------------------+------------+
- Geben Sie exit ein, um die Remote-Shell zu beenden.
- Entfernen Sie auf dem KI-Clientknoten die alten Geheimnisse für das fehlerhafte etcd-Mitglied.
- Listen Sie die Geheimnisse für das fehlerhafte (entfernte) Element auf.
user@ai-client:~# oc get secrets -n openshift-etcd | grep ocp3 etcd-peer-ocp3 kubernetes.io/tls 2 18d etcd-serving-metrics-ocp3 kubernetes.io/tls 2 18d etcd-serving-ocp3 kubernetes.io/tls 2 18d
- Löschen Sie die geheimen Peerschlüssel.
user@ai-client:~# oc delete secret -n openshift-etcd etcd-peer-ocp3 secret "etcd-peer-ocp3" deleted
- Löschen Sie die Metrikgeheimnisse.
user@ai-client:~# oc delete secret -n openshift-etcd etcd-serving-metrics-ocp3 secret "etcd-serving-metrics-ocp3" deleted
- Löschen Sie die Bereitstellungsgeheimnisse.
user@ai-client:~# oc delete secret -n openshift-etcd etcd-serving-ocp3 secret "etcd-serving-ocp3" deleted
- Listen Sie die Geheimnisse für das fehlerhafte (entfernte) Element auf.
- Löschen Sie abschließend den fehlerhaften Knoten.
- Kordonieren Sie den fehlerhaften Knoten.
user@ai-client:~# oc adm cordon ocp3 node/ocp3 cordoned
- Entleeren Sie den fehlerhaften Knoten.
user@ai-client:~# oc adm drain ocp3 --ignore-daemonsets=true --delete-emptydir-data --force node/ocp3 already cordoned <trimmed>
- Löschen Sie den fehlerhaften Knoten.
user@ai-client:~# oc delete node ocp3 node "ocp3" deleted
- Listen Sie die Knoten auf.
user@ai-client:~# oc get nodes NAME STATUS ROLES AGE VERSION ocp1 Ready master 19d v1.21.6+bb8d50a ocp2 Ready master 19d v1.21.6+bb8d50a ocp4 Ready worker 18d v1.21.6+bb8d50a ocp5 Ready worker 18d v1.21.6+bb8d50a
Sie haben nun den fehlerhaften Knoten identifiziert und entfernt. - Kordonieren Sie den fehlerhaften Knoten.
Hinzufügen eines Ersatzknotens für die Steuerungsebene
Gehen Sie wie folgt vor, um einem vorhandenen OpenShift-Cluster einen Ersatzknoten für die Steuerungsebene hinzuzufügen. Ein OpenShift-Cluster hat genau 3 Knoten der Steuerungsebene. Sie können dieses Verfahren nicht verwenden, um einen Knoten zu einem Cluster hinzuzufügen, der bereits über 3 Knoten der Steuerungsebene verfügt.
Diese Prozedur zeigt ein Beispiel für eine späte Bindung. Bei der späten Bindung generieren Sie eine ISO-Datei und starten den Knoten mit dieser ISO-Datei. Nachdem der Knoten gestartet wurde, binden Sie ihn an den vorhandenen Cluster.
Dies bewirkt, dass eine oder mehrere CertificateSigningRequests (CSRs) vom neuen Knoten an den vorhandenen Cluster gesendet werden. Ein CSR ist einfach eine Anforderung zum Abrufen der Clientzertifikate für den (vorhandenen) Cluster. Sie müssen diese Anforderungen explizit genehmigen. Nach der Genehmigung stellt der vorhandene Cluster die Clientzertifikate für den neuen Knoten bereit, und der neue Knoten kann dem vorhandenen Cluster beitreten.
- Melden Sie sich bei dem Computer (VM oder BMS) an, den Sie als Client für das unterstützte Installationsprogramm verwenden. Auf dem Assisted Installer-Clientcomputer können Sie API-Aufrufe für Assisted Installer an den von Red Hat gehosteten Server für Assisted Installer senden.
- Bereiten Sie die Bereitstellung vor, indem Sie die Umgebungsvariablen festlegen, die Sie in späteren Schritten verwenden werden.
- Richten Sie denselben SSH-Schlüssel ein, den Sie für den vorhandenen Cluster verwenden.
In diesem Beispiel rufen wir diesen SSH-Schlüssel von seinem Standardspeicherort ~/.ssh/id_rsa.pub ab und speichern ihn in einer Variablen.
export CLUSTER_SSHKEY=$(cat ~/.ssh/id_rsa.pub)
- Wenn Sie den geheimen Image-Pull-Schlüssel nicht mehr haben, laden Sie den geheimen Image-Pull-Schlüssel von Ihrem Red Hat-Konto auf Ihren lokalen Computer herunter. Der geheime Pullschlüssel ermöglicht Ihrer Installation den Zugriff auf Dienste und Registrierungen, die Containerimages für OpenShift-Komponenten bereitstellen.
Wenn Sie den von Red Hat gehosteten Assisted Installer verwenden, können Sie die Pull-Secret-Datei (pull-secret) von der https://console.redhat.com/openshift/downloads-Seite herunterladen. Kopieren Sie die Pull-Secret-Datei auf den Clientcomputer des unterstützten Installationsprogramms. In diesem Beispiel speichern wir den geheimen Pull-Schlüssel in einer Datei namens pull-secret.txt.
Entfernen Sie alle Leerzeichen, konvertieren Sie den Inhalt in das JSON-Zeichenfolgenformat, und speichern Sie ihn wie folgt in einer Umgebungsvariablen:
export PULL_SECRET=$(sed '/^[[:space:]]*$/d' pull-secret.txt | jq -R .)
- Wenn Sie Ihr Offline-Zugriffstoken nicht mehr haben, kopieren Sie das Offline-Zugriffstoken aus Ihrem Red Hat-Konto. Das OpenShift Cluster Manager API-Token ermöglicht es Ihnen (auf dem Clientcomputer des unterstützten Installationsprogramms), mit dem von Red Hat gehosteten API-Dienst für den unterstützten Installationsassistenten zu interagieren.
Das Token ist eine Zeichenfolge, die Sie kopieren und in eine lokale Umgebungsvariable einfügen können. Wenn Sie den von Red Hat gehosteten Assisted Installer verwenden, können Sie das API-Token aus https://console.redhat.com/openshift/downloads kopieren.
export OFFLINE_ACCESS_TOKEN='<paste offline access token here>'
- Generieren (aktualisieren) Sie das Token aus dem OFFLINE_ACCESS_TOKEN. Sie verwenden dieses generierte Token immer dann, wenn Sie API-Befehle ausgeben.
export TOKEN=$(curl --silent --data-urlencode "grant_type=refresh_token" --data-urlencode "client_id=cloud-services" --data-urlencode "refresh_token=${OFFLINE_ACCESS_TOKEN}" https://sso.redhat.com/auth/realms/redhat-external/protocol/openid-connect/token | jq -r .access_token)Anmerkung:Dieses Token läuft regelmäßig ab. Wenn dieses Token abläuft, erhalten Sie eine HTTP 4xx-Antwort, wenn Sie einen API-Befehl ausgeben. Aktualisieren Sie das Token, wenn es abläuft, oder aktualisieren Sie es alternativ regelmäßig vor dem Ablauf. Es schadet nicht, das Token zu aktualisieren, wenn es noch nicht abgelaufen ist.
- Rufen Sie die OpenShift-Cluster-ID des vorhandenen Clusters ab.
Zum Beispiel:
oc get clusterversion -o jsonpath='{.items[].spec.clusterID}{"\n"}' 1777102a-1fe1-407a-9441-9d0bad4f5968export $OS_CLUSTER_ID="1777102a-1fe1-407a-9441-9d0bad4f5968"
- Richten Sie die restlichen Umgebungsvariablen ein.
In Tabelle 1 sind alle Umgebungsvariablen aufgeführt, die Sie in diesem Verfahren festlegen müssen, einschließlich der in den vorherigen Schritten beschriebenen.
Tabelle 1: Umgebungsvariablen Beispiel für eine Variablenbeschreibung CLUSTER_SSHKEY Der (öffentliche) SSH-Schlüssel, den Sie für den vorhandenen Cluster verwenden. Sie müssen denselben Schlüssel für den neuen Knoten verwenden, den Sie hinzufügen. – PULL_SECRET Das Pull-Geheimnis des Bildes, das Sie heruntergeladen, entfernt und in das JSON-Zeichenfolgenformat konvertiert haben. – OFFLINE_ACCESS_TOKEN Das OpenShift Cluster Manager-API-Token, das Sie kopiert haben. – ZEICHEN Das Token, das Sie aus dem OFFLINE_ACCESS_TOKEN generiert (aktualisiert) haben. – CLUSTER_NAME Der Name des vorhandenen Clusters. meincluster CLUSTER_DOMAIN Die Basisdomäne des vorhandenen Clusters. contrail.lan OS_CLUSTER_ID Die OpenShift-Cluster-ID des vorhandenen Clusters. 1777102A-1FE1-407A-9441-9D0Bad4F5968 AI_URL Die URL des Assisted Installer-Dienstes. In diesem Beispiel wird der von Red Hat gehostete unterstützte Installationsassistent verwendet. https://api.openshift.com
- Richten Sie denselben SSH-Schlüssel ein, den Sie für den vorhandenen Cluster verwenden.
- Generieren Sie die Discovery-Boot-ISO. Sie verwenden diese ISO-Datei, um den Knoten zu starten, den Sie dem Cluster hinzufügen.
Die ISO-Datei wird basierend auf der Infrastrukturumgebung, die Sie einrichten, an Ihre Infrastruktur angepasst.
- Erstellen Sie eine Datei, die die Infrastrukturumgebung beschreibt. In diesem Beispiel nennen wir es infra-envs-addhost.json.
cat << EOF > ./infra-envs-addhost.json { "name": "<InfraEnv Name>", "ssh_authorized_key": "$CLUSTER_SSHKEY", "pull_secret": $PULL_SECRET, "openshift_version": "4.8", "user_managed_networking": <same as for existing cluster>, "vip_dhcp_allocation": <same as for existing cluster>, "base_dns_domain": "$CLUSTER_DOMAIN", } EOF- InfraEnv Name ist der Name, den Sie InfraEnv nennen möchten.
user_managed_networkingundvip_dhcp_allocationwerden auf die gleichen Werte wie für den vorhandenen Cluster festgelegt.
- Registrieren Sie die InfraEnv. Als Reaktion darauf weist der Assisted Installer-Dienst eine InfraEnv-ID zu und erstellt die Ermittlungsstart-ISO-Datei basierend auf der angegebenen Infrastrukturumgebung.
curl -X POST "$AI_URL/api/assisted-install/v2/infra-envs" -H "accept: application/json" -H "Content-Type: application/json" -H "Authorization: Bearer $TOKEN" -d @infra-envs-addhosts.json
Wenn Sie die InfraEnv registrieren, gibt der Dienst für unterstützte Installationsprogramme eine InfraEnv-ID zurück. Suchen Sie sorgfältig nach der InfraEnv-ID, die in die Antwort eingebettet ist. Zum Beispiel:
"id":"5c858ed9-26cf-446d-817c-4c4261541657"
Speichern Sie die InfraEnv-ID in einer Variablen. Zum Beispiel:
export INFRA_ENV_ID="5c858ed9-26cf-446d-817c-4c4261541657"
- Rufen Sie die URL zum Herunterladen des Bildes ab.
curl -s $AI_URL/api/assisted-install/v2/infra-envs/$INFRA_ENV_ID/downloads/image-url -H "accept: application/json" -H "Content-Type: application/json" -H "Authorization: Bearer $TOKEN" | jq '.url'
- Laden Sie die ISO-Datei herunter und speichern Sie sie in einer Datei. In diesem Beispiel speichern wir sie in ai-liveiso-addhosts.iso.
curl -L "<image URL>" -H "Authorization: Bearer $TOKEN" -o ./ai-liveiso-addhosts.iso
- Erstellen Sie eine Datei, die die Infrastrukturumgebung beschreibt. In diesem Beispiel nennen wir es infra-envs-addhost.json.
- Starten Sie den neuen Knoten mit der Discovery-Boot-ISO. Wählen Sie die Boot-Methode, die für Ihre Infrastruktur am besten geeignet ist. Stellen Sie sicher, dass der neue Knoten an ein Netzwerk angeschlossen ist, das Zugriff auf den von Red Hat gehosteten unterstützten Installer hat.
Überprüfen Sie den Status des Hosts:
curl -s -X GET --header "Content-Type: application/json" -H "Authorization: Bearer $TOKEN" $AI_URL/api/assisted-install/v2/infra-envs/$INFRA_ENV_ID/hosts | jq '.'
export HOST_ID=$(curl -s -X GET --header "Content-Type: application/json" -H "Authorization: Bearer $TOKEN" $AI_URL/api/assisted-install/v2/infra-envs/$INFRA_ENV_ID/hosts | jq -r '.[].id')
- Konfigurieren Sie den neuen Knoten als Steuerungsebenenknoten.
curl -X PATCH --header "Content-Type: application/json" "$AI_URL/api/assisted-install/v2/infra-envs/$INFRA_ENV_ID/hosts/$HOST_ID" -H "Authorization: Bearer $TOKEN" -d "{ \"machine_config_pool_name\": \"master\"}" | jq -r"machine_config_pool_name": "master",
- Importieren Sie den vorhandenen Cluster.
curl -X POST "$AI_URL/api/assisted-install/v2/clusters/import" -H "accept: application/json" -H "Content-Type: application/json" -H "Authorization: Bearer $TOKEN" -d "{\"name\":\"$CLUSTER_NAME\",\"openshift_cluster_id\":\"$OS_CLUSTER_ID\",\"api_vip_dnsname\":\"api.$CLUSTER_NAME.$CLUSTER_DOMAIN\"}"Wenn Sie den Cluster importieren, gibt der Assisted Installer-Dienst eine Cluster-ID für AddHostsCluster zurück. Suchen Sie sorgfältig nach der Cluster-ID, die in die Antwort eingebettet ist. Zum Beispiel:
"id":"c5bbb159-78bc-41c9-99b7-d8a4727a3890"
- Binden Sie den neuen Host an den Cluster, und verweisen Sie dabei auf die Cluster-ID von AddHostsCluster.
curl -X POST "$AI_URL/api/assisted-install/v2/infra-envs/$INFRA_ENV_ID/hosts/$HOST_ID/actions/bind" -H "accept: application/json" -H "Content-Type: application/json" -H "Authorization: Bearer $TOKEN" -d '{"cluster_id":"c5bbb159-78bc-41c9-99b7-d8a4727a3890"}'curl -s -X GET --header "Content-Type: application/json" -H "Authorization: Bearer $TOKEN" $AI_URL/api/assisted-install/v2/infra-envs/$INFRA_ENV_ID/hosts | jq '.'
"status": "known", "status_info": "Host is ready to be installed",
- Installieren Sie den neuen Knoten.
curl -X POST -H "accept: application/json" -H "Content-Type: application/json" -H "Authorization: Bearer $TOKEN" "$AI_URL/api/assisted-install/v2/infra-envs/$INFRA_ENV_ID/hosts/$HOST_ID/actions/install"
curl -s -X GET --header "Content-Type: application/json" -H "Authorization: Bearer $TOKEN" $AI_URL/api/assisted-install/v2/infra-envs/$INFRA_ENV_ID/hosts | jq '.'
"status_info": "Host has rebooted and no further updates will be posted. Please check console for progress and to possibly approve pending CSRs",
- Sobald der neue Knoten neu gestartet wurde, versucht er, dem vorhandenen Cluster beizutreten. Dies bewirkt, dass eine oder mehrere CertificateSigningRequests (CSRs) vom neuen Knoten an den vorhandenen Cluster gesendet werden. Sie müssen die CSRs genehmigen.
- Suchen Sie nach den CSRs.
Zum Beispiel:
root@ai-client:~/contrail# oc get csr -A NAME AGE SIGNERNAME REQUESTOR CONDITION csr-gblnm 20s kubernetes.io/kube-apiserver-client-kubelet system:serviceaccount:openshift-machine-config-operator:node-bootstrapper Pending
Möglicherweise müssen Sie diesen Befehl regelmäßig wiederholen, bis ausstehende CSRs angezeigt werden.
- Genehmigen Sie die CSRs.
Zum Beispiel:
root@ai-client:~/contrail# oc adm certificate approve csr-gblnm certificatesigningrequest.certificates.k8s.io/csr-gblnm approved
- Suchen Sie nach den CSRs.
- Stellen Sie sicher, dass der neue Knoten im vorhandenen Cluster ausgeführt wird.
oc get nodes