Drehung der Red Hat OpenShift Zertifikate

Red Hat OpenShift für VMware verwendet Kubelet-Client-Zertifikate, die zu Sicherheitszwecken regelmäßig rotiert werden müssen. Red Hat OpenShift automatisiert den Rotationsprozess weitgehend, erfordert aber eine manuelle Genehmigung von Zertifikatsignierungsanforderungen (CSRs).Daher ist es wichtig, dass Sie den Zeitplan für die Rotation der Zertifikate auf Red Hat OpenShift kennen, um ablaufende Zertifikate zu vermeiden.

Die Anfangszertifikate, die bei der Installation erstellt werden, laufen 24 Stunden nach ihrer Erstellung ab.IBM der Automatisierungsprozess von Red Hat OpenShift übernimmt die Genehmigung der CSRs für diese erste Rotation, indem ein Skript auf der Bastion für die ersten 30 Stunden ausgeführt wird.Das Script hat den Namen /root/approve-csr.sh und die zugehörige Protokolldatei den Namen /root/approve-csr.log.

Für die erfolgreiche Ausführung des Scripts müssen die Anfangsberechtigungsnachweise von kubeadmin bis zum Abschluss der Anfangszertifikatsrotation gleich bleiben.Ändern Sie die Berechtigungsnachweise für 'kubeadmin' für die ersten 24 Stunden nicht.Wenn die Berechtigungsnachweise geändert werden, müssen Sie die CSRs für die Anfangszertifikatsrotation überwachen und genehmigen.Weitere Informationen finden Sie unter Genehmigen der CSRs für Ihre Maschinen.

Starten Sie keine der virtuellen Maschinen (VMs) des Clusters Red Hat OpenShift oder die Bastion VM neu, bevor die erste Zertifikatsrotation abgeschlossen ist.

Nach der Anfangszertifikatsrotation werden Zertifikate alle 30 Tage erneuert.Sie müssen einen Prozess für die Genehmigung der CSRs für jede Zertifikatsrotation einrichten.Laut Red Hat® können Sie CSRs genehmigen, wenn sie 80 % ihres Verfallszeitraums erreicht haben, d. h. etwa 25 Tage nach Ablauf der Lebensdauer der CSRs.

Wenn Sie CSRs nicht rechtzeitig genehmigen und die Zertifikate ablaufen, können Sie abgelaufene Steuerebenen-Zertifikate wiederherstellen und den Red Hat OpenShift-Cluster wieder betriebsbereit machen. Weitere Informationen finden Sie unter Wiederherstellung nach Ablauf von Zertifikaten für die Steuerungsebene.

Größenänderung Ihrer Red Hat OpenShift VMs

1. Melden Sie sich mit SSH bei der Bastion-VM an.
2. Werden Sie rootUser: sudo -i
3. Fahren Sie die Ziel-VM herunter: ssh core@<vm-ip> sudo shutdown -h 0
4. Nachdem die VM ausgeschaltet wurde, ändern Sie die Größe der VM in vCenter Server.
5. Schalten Sie die VM ein.
6. Gehen Sie in der Konsole Red Hat OpenShift zu Compute > Nodes und warten Sie, bis der VM, der neu gestartet wurde, wieder in den Bereitschaftsstatus übergeht.
7. Führen Sie die vorherigen Schritte für alle VMs aus.

Ändern des SSH-Schlüssels auf der Bastion Red Hat OpenShift VM

Das SSH-Schlüsselpaar, das während der Installation erzeugt wird, befindet sich auf der Red Hat OpenShift bastion VM.Der Speicherort des SSH-Schlüsselpaars wird auf der Seite Red Hat OpenShift service details angezeigt. Dieser SSH-Schlüssel wurde auf allen Cluster-VMs installiert, um SSH-Anmeldungen aus der Bastion zu ermöglichen, ohne dass ein Kennwort erforderlich ist.

Es empfiehlt sich, ein neues SSH-Schlüsselpaar zu generieren und als Ersatz für den vorhandenen Schlüssel zu verwenden.Weitere Informationen über die Erzeugung eines neuen SSH-Schlüsselpaares finden Sie unter Wie man ssh-Schlüssel nach der Installation auf Red Hat OpenShift aktualisiert. Sie müssen die Befehle mithilfe der Bastions-VM ausführen. Weitere Informationen zur Anmeldung bei der Bastion enthält der Abschnitt Bastionsdetails.

Erweiterung des Clusters Red Hat OpenShift um weitere Mitarbeiter

Um Ihren Red Hat OpenShift-Cluster durch Hinzufügen weiterer Worker-VMs zu erweitern, führen Sie die folgenden Schritte aus:

1. Erstellen Sie einen Worker VM aus der RHCOREOS-Vorlage:

   1. Stellen Sie sicher, dass die VM mit demselben Netzwerk verbunden ist wie die anderen Red Hat OpenShift Worker-VMs.
   2. Schalten Sie diese VM noch nicht ein, da weitere Konfigurationsschritte erforderlich sind.

2. Bereiten Sie eine Datei zur Zündung der Arbeiter auf der Bastion vor:

   1. Weitere Informationen zur Anmeldung bei der Bastion enthält der Abschnitt Bastionsdetails.
   2. Suchen Sie im Installationsverzeichnis auf der Bastion die Worker-Ignition-Datei mit dem Namen worker.ign. Erstellen Sie eine Base64-Version dieser Datei, indem Sie den Befehl base64 -w0 worker.ign > worker.ign.b64 verwenden. Sie werden den Inhalt der neu erstellten worker.ign.b64-Datei im nächsten Schritt verwenden.

3. Stellen Sie die Attribute VM ein:

   1. Bevor Sie beginnen, schalten Sie das VM aus. Gehen Sie dann zum Fenster Konfigurationsparameter, wählen Sie den neuen Worker VM und klicken Sie auf Aktionen > Einstellungen bearbeiten.
   2. Klicken Sie im Fenster 'Einstellungen bearbeiten' auf die Registerkarte VM-Optionen. Klicken Sie auf der linken Seite auf Erweitert, um den Abschnitt Erweitert im Fenster einzublenden. Blättern Sie anschließend auf der linken Seite abwärts zu Konfigurationsparameter.  Klicken Sie auf Konfiguration bearbeiten.
   3. Das Fenster 'Konfigurationsparameter' enthält möglicherweise eine umfangreiche Liste der vorhandenen Parameter für die VM. Um einen Wert hinzuzufügen, klicken Sie auf die Option Konfigurationsparameter hinzufügen. Zwei leere Felder mit den Bezeichnungen Name und Wert, die Sie ausfüllen können, werden angezeigt. Verwenden Sie dieses Verfahren für die folgenden 3 Schritte.
   4. Erstellen Sie einen Wert namens guestinfo.ignition.config.data und setzen Sie ihn auf den Inhalt der zuvor erstellten base64-encoded ignition config-Datei worker.ign.b64.
   5. Erstellen Sie einen Wert namens guestinfo.ignition.config.data.encoding und setzen Sie ihn auf die Zeichenkette base64.
   6. Erstellen Sie einen Wert namens disk.EnableUUID und setzen Sie ihn auf die Zeichenkette TRUE.
   7. Nachdem Sie die neuen Parameter erstellt haben, klicken Sie zweimal auf OK, um die geöffneten Fenster zu schließen.

4. Erstellen Sie eine DHCP-Bindung für die Worker-VM:

   1. Melden Sie sich bei NSX-T™ an.
   2. Wechseln Sie zu Netzbetrieb > Segmente.
   3. Bearbeiten Sie das Segment ocp-internal.
   4. Erweitern Sie Statische DHCP-Bindungen und klicken Sie auf Festlegen, um das Fenster 'Statische Bindungen festlegen' zu öffnen.
   5. Sehen Sie die Liste der vorhandenen Bindungen durch und notieren Sie sich die nächste verfügbare IP-Adresse.
   6. Untersuchen Sie eine der vorhandenen Worker-Bindungen auf Informationen, die Sie später benötigen. Notieren Sie sich die Gateway-Adresse und die DHCP-Optionen. Klicken Sie zum Anzeigen der DHCP-Optionen auf Festlegen neben DHCP-Optionen. Wählen Sie im Fenster Optionen die Option Allgemeine Optionen aus der Liste DHCP-Option auswählen. Notieren Sie sich die Optionen, die festgelegt sind.
   7. Schließen Sie die vorhandene Bindung, die Sie untersucht haben, um zum Fenster 'Statische Bindungen festlegen' zurückzukehren.
   8. Klicken Sie auf Statische IPV4-Bindung hinzufügen. Vervollständigen Sie die Details für den neuen Worker, einschließlich der DHCP-Optionen, die Sie zuvor notiert haben.
   9. Wenn Sie fertig sind, klicken Sie auf Speichern, um die Änderungen festzuschreiben.

5. Fügen Sie einen Worker zum Pool für die Lastausgleichsfunktion hinzu:

   1. Wechseln Sie zu Netzbetrieb > Lastausgleichsfunktion > Server-Pools.
   2. Bearbeiten Sie den Serverpool ocp-apps.
   3. Klicken Sie im Bearbeitungsfenster unter Mitglieder/Gruppe auf den blauen numerischen Link. Der Standardwert ist "3".
   4. Wenn das Fenster 'Server-Pool-Mitglieder konfigurieren' geöffnet wird, klicken Sie auf Mitglied hinzufügen.
   5. Geben Sie den Namen und die IP-Adresse des neuen Workers ein. Lassen Sie die Portnummer leer.
   6. Klicken Sie auf Speichern und dann auf Übernehmen.

6. Erstellen Sie DNS-Einträge für den neuen Mitarbeiter:

   1. Melden Sie sich bei dem AD NS-Server für Ihre VCF for Classic - Automated-Instanz an.
   2. Fügen Sie mithilfe von DNS Manager einen neuen A-Datensatz in der entsprechenden Zone ocp hinzu.Achten Sie beim Erstellen des A-Eintrags darauf, dass die Option zum Erstellen eines zugehörigen PTR-Eintrags aktiviert ist.

7. Genehmigen Sie alle von der Bastion stammenden Zertifikatssignieranforderungen (Certificate Signing Requests, CSRs). Während der Bereitstellung des neuen Mitarbeiters müssen Sie möglicherweise cSRs genehmigen von der Bastion aus ansteuern:

   1. Melden Sie sich bei bastion als Benutzer root an und wechseln Sie in das bastion-Installationsverzeichnis. Weitere Informationen finden Sie unter Bastion Details.

   2. Bevor Sie irgendwelche Befehle ausführen können, müssen Sie sich bei Red Hat OpenShift authentifizieren:

      • Falls die Authentifizierung nicht konfiguriert ist und Sie das Standardkonto kubeadmin mit dem zugehörige Kennwort verwenden, führen Sie den Befehl export KUBECONFIG=auth/kubeconfig aus und überprüfen Sie mit dem Befehl ./oc whoami, ob Sie authentifiziert sind.
      • Wenn andere Backends oder Benutzer authentifiziert sind, melden Sie sich mit einem dieser Konten an, wie in der Dokumentation Red Hat OpenShift beschrieben, indem Sie beispielsweise den Befehl ./oc login ausführen.

   3. Führen Sie den Befehl ./oc get nodes aus, um den neuen Worker anzuzeigen. Wenn er sich nicht im Zustand "Bereit" befindet, prüfen Sie wiederholt mit dem Befehl ./oc get csr, ob noch CSRs ausstehen, und genehmigen Sie die CSRs dann mit dem Befehl ./oc adm certificate approve <csr_name>.Fahren Sie mit der Überprüfung fort, bis die Konfiguration abgeschlossen ist und sich der neue Mitarbeiter im Zustand " Bereit" befindet.

      Nachdem der neue Worker im Zustand Ready ist, kann er von Red Hat OpenShift verwendet werden.

8. Schalten Sie die VM ein:

   • Nachdem die VM eingeschaltet worden ist, können Sie durch eine Überwachung der VM feststellen, ob ein Problem besteht.Die VM ruft eine IP-Adresse ab, verarbeitet anschließend die Ignition-Datei und öffnet danach einen Anmeldedialog.

   • Nachdem der Anmeldedialog aufgerufen worden ist, ist er möglicherweise mit Nachrichten aus dem Konsolenprotokoll gefüllt.Drücken Sie bei Bedarf einige Male die Eingabetaste auf der Konsole. Wenn die Anmeldeaufforderung vorhanden ist, aber von Konsolenprotokollmeldungen verdeckt wird, drücken Sie die Eingabetaste, um die Anmeldeaufforderung erneut anzuzeigen.

   • Wenn die Anmeldeaufforderung nicht angezeigt wird, ist es möglich, dass:

     • Die VM erhält keine IP-Adresse. Überprüfen Sie das Netz, mit dem die VM verbunden ist. Überprüfen Sie auch die Einstellungen der DHCP-Bindung.
     • Der Wert base64 von worker.ign.64 ist nicht korrekt. Es werden möglicherweise einige Zeichen fehlen oder es werden zusätzliche Zeichen verwendet. Überprüfen Sie den zu bestätigenden Wert.

     Wenn Sie Einstellungen ändern müssen, weil die VM keine Anmeldeaufforderung anzeigte, schalten Sie die VM aus, ändern Sie die erforderlichen Einstellungen und schalten Sie sie wieder ein.

Überlegungen beim Löschen von Red Hat OpenShift für VMware

• Bevor Sie Red Hat OpenShift für VMware löschen, müssen Sie alle zusätzlichen VMs entfernen, die Sie im Verzeichnis ocp auf VMware erstellt haben. Die VMware Solutions Automatisierung entfernt nur die Elemente, die bei der Erstinstallation von Red Hat OpenShift bereitgestellt wurden (VMs, Speicher und NSX). Alle Knoten, die nach der Installation bereitgestellt wurden, werden nicht gelöscht.
• Das VXLAN, das DLR und das Edge Gateway, die bei der ersten Bereitstellung von Red Hat OpenShift für VMware erstellt wurden, werden gelöscht. Die VMs, die Sie auf VXLAN bereitgestellt haben, verlieren die Konnektivität nach der Entfernung von Red Hat OpenShift für VMware.
• Wenn Ihr Cluster den Speicher NFS verwendet, wird durch das Löschen von Red Hat OpenShift der Datenspeicher NFS gelöscht, der während der Installation hinzugefügt wurde.
• Wenn Sie einen vSAN Datenspeicher verwenden, löschen Sie alle persistenten Volumes, die Sie nicht mehr benötigen, bevor Sie Red Hat OpenShift deinstallieren.Alle Volumes, die nicht gelöscht werden, verbleiben nach der Deinstallation von Red Hat OpenShift im Speicher vSAN.
• Bevor Sie den Dienst löschen, müssen Sie alle persönlichen VMs, die mit diesem Dienst bereitgestellt wurden, aus dem Speicher entfernen. Red Hat OpenShift bestellt nur persönliche VMs, die nicht vSAN-based sind.