Migration von Version 3 zu 4

OpenShift Container Platform 4.10

Migration zu OpenShift Container Platform 4

Zusammenfassung

Dieses Dokument enthält Anweisungen für die Migration Ihres OpenShift Container Platform-Clusters von Version 3 zu Version 4.

Kapitel 1. Überblick über die Migration von OpenShift Container Platform 3 zu 4

OpenShift Container Platform 4-Cluster unterscheiden sich von OpenShift Container Platform 3-Clustern. OpenShift Container Platform 4-Cluster enthalten neue Technologien und Funktionalitäten, die dafür sorgen, dass der Cluster sich selbst verwaltet, flexibel und automatisiert ist. Mehr zur Migration von OpenShift Container Platform 3 zu 4 finden Sie unter Informationen zur Migration von OpenShift Container Platform 3 zu 4.

1.1. Unterschiede zwischen OpenShift Container Platform 3 und 4

Bevor Sie von OpenShift Container 3 zu 4 migrieren, können Sie sich die Unterschiede zwischen OpenShift Container Platform 3 und 4 näher ansehen. Sehen Sie sich die folgenden Informationen an:

1.2. Überlegungen zur Netzwerkplanung

Bevor Sie von OpenShift Container Platform 3 zu 4 migrieren, sollten Sie sich die Unterschiede zwischen OpenShift Container Platform 3 und 4 ansehen, um Informationen zu den folgenden Bereichen zu erhalten:

Sie können zustandsbehaftete Anwendungs-Workloads mit der Granularität eines Namespaces von OpenShift Container Platform 3 zu 4 migrieren. Mehr über das MTC erfahren Sie unter Informationen zum MTC.

1.3. Installation des MTC

Gehen Sie die folgenden Schritte zur Installation des MTC durch:

1.4. Upgrade des MTC

Sie aktualisieren das Migration Toolkit for Containers (MTC) auf OpenShift Container Platform 4.10 mithilfe von OLM. Sie aktualisieren MTC auf OpenShift Container Platform 3, indem Sie den alten Migration Toolkit for Containers Operator neu installieren.

1.5. Überprüfen der Checklisten zur Migrationsvorbereitung

Bevor Sie Ihre Anwendungs-Workloads mit dem Migration Toolkit for Containers (MTC) migrieren, sollten Sie die Checklisten zur Migrationsvorbereitung überprüfen.

1.6. Migration von Anwendungen

Sie können Ihre Anwendungen über die MTC-Webkonsole oder die Befehlszeile migrieren.

1.7. Erweiterte Migrationsoptionen

Sie können Ihre Migrationen automatisieren und die benutzerdefinierten MTC-Ressourcen anpassen, um die Leistung umfangreicher Migrationen zu verbessern, indem Sie die folgenden Optionen verwenden:

1.8. Problembehandlung bei Migrationen

Sie können die folgenden Schritte zur Problembehandlung durchführen:

1.9. Zurücksetzen einer Migration

Sie können eine Migration über die MTC-Webkonsole, über die Befehlszeilenschnittstelle (CLI) oder manuell zurücksetzen.

1.10. Deinstallation des MTC und Löschen von Ressourcen

Sie können das MTC deinstallieren und seine Ressourcen löschen, um den Cluster zu bereinigen.

Kapitel 2. Informationen zur Migration von OpenShift Container Platform 3 zu 4

OpenShift Container Platform 4 enthält neue Technologien und Funktionalitäten, die dafür sorgen, dass der Cluster sich selbst verwaltet, flexibel und automatisiert ist. OpenShift Container Platform 4-Cluster werden anders bereitgestellt und verwaltet wie in OpenShift Container Platform 3.

Der effektivste Weg, um von OpenShift Container Platform 3 zu 4 zu migrieren, ist die Verwendung einer CI/CD-Pipeline zur Automatisierung von Bereitstellungen in einem Framework zum Application Lifecycle Management.

Wenn Sie nicht über eine CI/CD-Pipeline verfügen oder wenn Sie zustandsbehaftete Anwendungen migrieren, können Sie das Migration Toolkit for Containers (MTC) verwenden, um Ihre Anwendungs-Workloads zu migrieren.

Um erfolgreich auf OpenShift Container Platform 4 umzusteigen, lesen Sie bitte die folgenden Informationen:

Unterschiede zwischen OpenShift Container Platform 3 und 4
  • Architektur
  • Installation und Upgrade
  • Überlegungen zu Speicher, Netzwerk, Protokollierung, Sicherheit und Überwachung
Informationen zum Migration Toolkit for Containers
  • Workflow
  • Dateisystem- und Schnappschuss-Kopiermethoden für Persistent Volumes (PVs)
  • Direct Volume Migration
  • Direct Image Migration
Erweiterte Migrationsoptionen
  • Automatisieren Ihrer Migration mit Hooks für die Migration
  • Verwendung der MTC API
  • Ausschluss von Ressourcen aus einem Migrationsplan
  • Konfigurieren der benutzerdefinierten Ressource MigrationController für umfangreiche Migrationen
  • Aktivieren der automatischen PV-Größenänderung für die Direct Volume Migration
  • Aktivieren von zwischengespeicherten Kubernetes-Clients für verbesserte Leistung

Neue Funktionen und Erweiterungen, technische Änderungen und bekannte Probleme finden Sie in den MTC-Versionshinweisen.

Kapitel 3. Unterschiede zwischen OpenShift Container Platform 3 und 4

OpenShift Container Platform 4.10 führt architektonische Änderungen und Erweiterungen ein. Die Verfahren, die Sie für die Verwaltung Ihres OpenShift Container Platform 3-Clusters verwendet haben, gelten möglicherweise nicht für OpenShift Container Platform 4.

Informationen zur Konfiguration Ihres OpenShift Container Platform 4-Clusters finden Sie in den entsprechenden Abschnitten der OpenShift Container Platform-Dokumentation. Informationen über neue Features und andere nennenswerte technische Änderungen finden Sie in den OpenShift Container Platform 4.10 Versionshinweise.

Es ist nicht möglich, Ihren bestehenden OpenShift Container Platform 3-Cluster auf OpenShift Container Platform 4 zu aktualisieren. Sie müssen mit einer neuen Installation von OpenShift Container Platform 4 beginnen. Es stehen Tools zur Verfügung, die Sie bei der Migration Ihrer Kontrollebenen-Einstellungen und Anwendungs-Workloads unterstützen.

3.1. Architektur

Mit OpenShift Container Platform 3 haben Administratoren Red Hat Enterprise Linux(RHEL)-Hosts einzeln bereitgestellt und dann OpenShift Container Platform auf diesen Hosts installiert, um einen Cluster zu bilden. Die Administratoren waren für die ordnungsgemäße Konfiguration dieser Hosts und die Durchführung von Updates verantwortlich.

OpenShift Container Platform 4 stellt eine bedeutende Veränderung in der Art und Weise dar, wie OpenShift Container Platform-Cluster bereitgestellt und verwaltet werden. OpenShift Container Platform 4 enthält neue Technologien und Funktionalitäten wie Operatoren, Machine Sets und Red Hat Enterprise Linux CoreOS (RHCOS), die für den Betrieb des Clusters von zentraler Bedeutung sind. Dieser technologische Wandel ermöglicht es Clustern, einige Funktionen selbst zu verwalten, die zuvor von Administratoren ausgeführt wurden. Dies gewährleistet auch die Stabilität und Konsistenz der Plattform und vereinfacht die Installation und Skalierung.

Weitere Informationen finden Sie unter OpenShift Container Platform-Architektur.

Unveränderliche Infrastruktur

OpenShift Container Platform 4 verwendet Red Hat Enterprise Linux CoreOS (RHCOS), das für die Ausführung von containerisierten Anwendungen entwickelt wurde und eine effiziente Installation, eine operatorenbasierte Verwaltung und vereinfachte Upgrades bietet. RHCOS ist ein unveränderlicher Container-Host und kein anpassbares Betriebssystem wie RHEL. RHCOS ermöglicht OpenShift Container Platform 4 die Verwaltung und Automatisierung der Bereitstellung des zugrunde liegenden Container-Hosts. RHCOS ist ein Teil der OpenShift Container Platform, was bedeutet, dass alles innerhalb eines Containers läuft und mit der OpenShift Container Platform bereitgestellt wird.

In OpenShift Container Platform 4 müssen die Knoten der Kontrollebene RHCOS ausführen, um sicherzustellen, dass die vollständige Automatisierung der Kontrollebene beibehalten wird. Dies macht das Ausrollen von Updates und Upgrades wesentlich einfacher als in OpenShift Container Platform 3.

Weitere Informationen finden Sie unter Red Hat Enterprise Linux CoreOS (RHCOS).

Operatoren

Operatoren sind eine Methode zum Verpacken, Bereitstellen und Verwalten einer Kubernetes-Anwendung. Die Operatoren können die Komplexität des Betriebs einer weiteren Software verringern. Sie überwachen Ihre Umgebung und nutzen den aktuellen Zustand, um in Echtzeit Entscheidungen zu treffen. Erweiterte Operatoren sind so konzipiert, dass sie automatisch Upgrades durchführen und auf Störungen reagieren.

Weitere Informationen finden Sie unter Informationen zu Operatoren.

3.2. Installation und Upgrade

Installationsvorgang

Um OpenShift Container Platform 3.11 zu installieren, haben Sie Ihre Red Hat Enterprise Linux(RHEL)-Hosts vorbereitet, alle für Ihren Cluster erforderlichen Konfigurationswerte festgelegt und dann ein Ansible-Playbook zur Installation und Einrichtung Ihres Clusters ausgeführt.

In OpenShift Container Platform 4.10 verwenden Sie das OpenShift-Installationsprogramm, um eine Mindestmenge an Ressourcen zu erstellen, die für einen Cluster erforderlich sind. Nachdem der Cluster in Betrieb ist, verwenden Sie Operatoren, um Ihren Cluster weiter zu konfigurieren und neue Dienste zu installieren. Nach dem ersten Start werden Red Hat Enterprise Linux CoreOS(RHCOS)-Systeme vom Machine Config Operator (MCO) verwaltet, der im OpenShift Container Platform-Cluster ausgeführt wird.

Weitere Informationen finden Sie unter Installationsvorgang.

Wenn Sie Ihrem OpenShift Container Platform 4.10-Cluster Red Hat Enterprise Linux(RHEL)-Worker-Maschinen hinzufügen möchten, verwenden Sie ein Ansible-Playbook, um die RHEL-Worker-Maschinen zusammenzuführen, nachdem der Cluster ausgeführt wurde. Weitere Informationen finden Sie unter Hinzufügen von RHEL-Rechenmaschinen zu einem OpenShift Container Platform-Cluster.

Infrastruktur-Optionen

In OpenShift Container Platform 3.11 haben Sie Ihren Cluster auf einer Infrastruktur installiert, die Sie vorbereitet und gewartet haben. Neben der Bereitstellung einer eigenen Infrastruktur bietet OpenShift Container Platform 4 die Möglichkeit, einen Cluster auf einer Infrastruktur bereitzustellen, die vom OpenShift Container Platform-Installationsprogramm bereitgestellt und vom Cluster verwaltet wird.

Weitere Informationen finden Sie unter OpenShift Container Platform Installationsübersicht.

Upgrade Ihres Clusters

In OpenShift Container Platform 3.11 haben Sie Ihren Cluster durch die Ausführung von Ansible-Playbooks aktualisiert. In OpenShift Container Platform 4.10 verwaltet der Cluster seine eigenen Updates, einschließlich Updates für Red Hat Enterprise Linux CoreOS (RHCOS) auf den Cluster-Knoten. Sie können Upgrades für Ihren Cluster ganz einfach über die Webkonsole oder mit dem Befehl oc adm upgrade in der OpenShift-CLI durchführen und die Operatoren aktualisieren sich automatisch. Wenn Ihr OpenShift Container Platform 4.10-Cluster über RHEL-Worker-Maschinen verfügt, müssen Sie dennoch ein Ansible-Playbook ausführen, um diese Worker-Maschinen zu aktualisieren.

Weitere Informationen finden Sie unter Aktualisieren von Clustern.

3.3. Überlegungen zur Migration

Überprüfen Sie die Änderungen und andere Überlegungen, die Ihren Umstieg von OpenShift Container Platform 3.11 zu OpenShift Container Platform 4 beeinflussen könnten.

3.3.1. Überlegungen zum Speicher

Prüfen Sie die folgenden Speicheränderungen, die beim Übergang von OpenShift Container Platform 3.11 auf OpenShift Container Platform 4.10 zu berücksichtigen sind.

Lokaler persistenter Volume-Speicher

Lokaler Speicher wird in OpenShift Container Platform 4.10 nur durch die Verwendung des Local Storage Operator unterstützt. Es wird nicht unterstützt, die lokale Provisionierungsmethode von OpenShift Container Platform 3.11 zu verwenden.

Weitere Informationen finden Sie unter Persistenter Speicher mit lokalen Volumes.

Persistenter FlexVolume-Speicher

Der Speicherort des FlexVolume-Plug-ins in OpenShift Container Platform 3.11 wurde geändert. Der neue Speicherort in OpenShift Container Platform 4.10 ist /etc/kubernetes/kubelet-plugins/volume/exec. Anfügbare FlexVolume-Plug-ins werden nicht mehr unterstützt.

Weitere Informationen finden Sie unter Persistenter Speicher mit FlexVolume.

Container Storage Interface (CSI) – persistenter Speicher

Der persistente Speicher unter Verwendung des Container Storage Interface (CSI) war eine Technologievorschau in OpenShift Container Platform 3.11. OpenShift Container Platform 4.10 enthält mehrere CSI-Treiber. Sie können auch einen eigenen Treiber installieren.

Weitere Informationen finden Sie unter Persistenter Speicher mit dem Container Storage Interface (CSI).

Red Hat OpenShift Container Storage

Red Hat OpenShift Container Storage 3 kann mit OpenShift Container Platform 3.11 verwendet werden und nutzt Red Hat Gluster Storage als Reservespeicher.

Red Hat OpenShift Container Storage 4 kann mit OpenShift Container Platform 4 verwendet werden und nutzt Red Hat Ceph Storage als Reservespeicher.

Weitere Informationen finden Sie unter Persistenter Speicher mit Red Hat OpenShift Container Storage und im Artikel zur Interoperabilitätsmatrix.

Nicht unterstützte persistente Speicheroptionen

Die Unterstützung für die folgenden persistenten Speicheroptionen von OpenShift Container Platform 3.11 hat sich in OpenShift Container Platform 4.10 geändert:

  • GlusterFS wird nicht mehr unterstützt.
  • CephFS wird nicht mehr als eigenständiges Produkt unterstützt.
  • Ceph RBD wird nicht mehr als eigenständiges Produkt unterstützt.

Wenn Sie eine dieser Optionen in OpenShift Container Platform 3.11 verwendet haben, müssen Sie für eine vollständige Unterstützung in OpenShift Container Platform 4.10 eine andere Option für persistenten Speicher wählen.

Weitere Informationen finden Sie unter Informationen zu persistentem Speicher.

3.3.2. Überlegungen zur Vernetzung

Überprüfen Sie die folgenden Vernetzungsänderungen, die beim Umstieg von OpenShift Container Platform 3.11 auf OpenShift Container Platform 4.10 zu berücksichtigen sind.

Netzwerk-Isolationsmodus

Der standardmäßige Netzwerk-Isolationsmodus für OpenShift Container Platform 3.11 war ovs-subnet, auch wenn die Benutzer häufig zu ovn-multitenant wechselten. Der standardmäßige Netzwerk-Isolationsmodus für OpenShift Container Platform 4.10 wird durch eine Netzwerkrichtlinie gesteuert.

Wenn Ihr OpenShift Container Platform 3.11-Cluster den ovs-subnet- oder ovs-multitenant-Modus verwendet hat, empfiehlt es sich, für Ihren OpenShift Container Platform 4.10-Cluster zu einer Netzwerkrichtlinie zu wechseln. Netzwerkrichtlinien haben eine Upstream-Unterstützung, sind flexibler und bieten dieselbe Funktionalität wie ovs-multitenant. Wenn Sie das ovs-multitenant-Verhalten beibehalten möchten, während Sie eine Netzwerkrichtlinie in OpenShift Container Platform 4.10 verwenden, folgen Sie den Schritten zur Konfiguration der Multitenant-Isolation mit der Netzwerkrichtlinie.

Weitere Informationen finden Sie unter Informationen zu Netzwerkrichtlinien.

3.3.3. Überlegungen zur Protokollierung

Überprüfen Sie die folgenden Änderungen bei der Protokollierung, die beim Umstieg von OpenShift Container Platform 3.11 auf OpenShift Container Platform 4.10 zu beachten sind.

Bereitstellung von OpenShift Logging

OpenShift Container Platform 4 bietet einen einfachen Bereitstellungsmechanismus für OpenShift Logging, indem eine benutzerdefinierte Cluster Logging-Ressource verwendet wird.

Weitere Informationen finden Sie unter Installieren von OpenShift Logging.

Aggregierte Protokolldaten

Sie können Ihre aggregierten Protokolldaten von OpenShift Container Platform 3.11 nicht in Ihren neuen OpenShift Container Platform 4-Cluster übertragen.

Weitere Informationen finden Sie unter Informationen zu OpenShift Logging.

Nicht unterstützte Protokollierungskonfigurationen

Einige Protokollierungskonfigurationen, die in OpenShift Container Platform 3.11 verfügbar waren, werden in OpenShift Container Platform 4.10 nicht mehr unterstützt.

Weitere Informationen zu den explizit nicht unterstützten Anwendungsfällen der Protokollierung finden Sie unter Wartung und Unterstützung.

3.3.4. Überlegungen zur Sicherheit

Überprüfen Sie die folgenden Sicherheitsänderungen, die Sie beim Umstieg von OpenShift Container Platform 3.11 auf OpenShift Container Platform 4.10 berücksichtigen sollten.

Nicht authentifizierter Zugriff auf Discovery-Endpunkte

In OpenShift Container Platform 3.11 konnte ein nicht authentifizierter Benutzer auf die Discovery-Endpunkte zugreifen (z. B. /api/* und /apis/*). Aus Sicherheitsgründen ist der nicht authentifizierte Zugriff auf die Discovery-Endpunkte in OpenShift Container Platform 4.10 nicht mehr erlaubt. Wenn Sie den nicht authentifizierten Zugriff zulassen müssen, können Sie die RBAC-Einstellungen nach Bedarf konfigurieren; beachten Sie jedoch die Sicherheitsauswirkungen, da dadurch interne Clusterkomponenten für das externe Netzwerk zugänglich gemacht werden können.

Identitätsanbieter

Die Konfiguration für Identitätsanbieter hat sich in OpenShift Container Platform 4 geändert, einschließlich der folgenden nennenswerten Änderungen:

  • Der Request-Header-Identitätsanbieter in OpenShift Container Platform 4.10 erfordert wechselseitige TLS, während dies in OpenShift Container Platform 3.11 nicht der Fall war.
  • Die Konfiguration des OpenID-Connect-Identitätsanbieters wurde in OpenShift Container Platform 4.10 vereinfacht. Es werden nun Daten bezogen, die zuvor in OpenShift Container Platform 3.11 angegeben vom Endpunkt /.well-known/openid-configuration des Anbieters angegeben werden mussten.

Weitere Informationen finden Sie unter Informationen zur Identitätsanbieterkonfiguration.

OAuth-Token-Speicherformat

Neu erstellte OAuth-HTTP-Bearer-Tokens stimmen nicht mehr mit den Namen der entsprechenden OAuth-Zugriffstoken-Objekte überein. Die Objektnamen sind jetzt ein Hash des Bearer-Tokens und sind nicht mehr vertraulich. Dadurch verringert sich das Risiko, dass vertrauliche Informationen nach außen dringen.

3.3.5. Überlegungen zur Überwachung

Überprüfen Sie die folgenden Überwachungsänderungen, die beim Umstieg von OpenShift Container Platform 3.11 auf OpenShift Container Platform 4.10 zu beachten sind.

Warnmeldung zur Verfügbarkeit der Überwachungs-Infrastruktur

Die Standard-Warnmeldung, die ausgelöst wird, um die Verfügbarkeit der Überwachungsstruktur sicherzustellen, wurde in OpenShift Container Platform 3.11 DeadMansSwitch genannt. Dieser wurde in OpenShift Container Platform 4 in Watchdog umbenannt. Wenn Sie die PagerDuty-Integration für diesen Alarm in OpenShift Container Platform 3.11 eingerichtet haben, müssen Sie die PagerDuty-Integration für den Watchdog-Alarm in OpenShift Container Platform 4 einrichten.

Weitere Informationen finden Sie unter Anwenden einer benutzerdefinierten Alertmanager-Konfiguration.

Kapitel 4. Überlegungen zum Netzwerk

Überprüfen Sie die nach der Migration verfügbaren Methoden zur Umleitung des Netzwerkverkehrs Ihrer Anwendung.

4.1. DNS-Überlegungen

Die DNS-Domain des Ziel-Clusters unterscheidet sich von der Domain des Quell-Clusters. Standardmäßig erhalten die Anwendungen nach der Migration die Fully Qualified Domain Names (FQDNs) des Ziel-Clusters.

Um die Quell-DNS-Domain der migrierten Anwendungen beizubehalten, wählen Sie eine der beiden unten beschriebenen Optionen.

4.1.1. Isolation der DNS-Domain des Ziel-Clusters von den Clients

Sie können zulassen, dass die an die DNS-Domain des Quell-Clusters gesendeten Anfragen der Clients die DNS-Domain des Ziel-Clusters erreichen, ohne dass der Ziel-Cluster für die Clients zugänglich gemacht wird.

Vorgehensweise

  1. Platzieren Sie eine externe Netzwerkkomponente, wie z. B. einen Anwendungs-Lastenverteiler oder einen Reverse-Proxy, zwischen den Clients und dem Ziel-Cluster.
  2. Aktualisieren Sie den FQDN der Anwendung auf dem Quell-Cluster im DNS-Server, um die IP-Adresse der externen Netzwerkkomponente zurückzugeben.
  3. Konfigurieren Sie die Netzwerkkomponente so, dass sie für die Anwendung in der Quell-Domain empfangene Anfragen an den Lastenverteiler in der Ziel-Cluster-Domain sendet.
  4. Erstellen Sie einen Platzhalter-DNS-Eintrag für die Domain *.apps.source.example.com, der auf die IP-Adresse des Lastenverteilers des Quell-Clusters verweist.
  5. Erstellen Sie für jede Anwendung einen DNS-Eintrag, der auf die IP-Adresse der externen Netzwerkkomponente vor dem Ziel-Cluster verweist. Ein spezifischer DNS-Eintrag hat eine höhere Priorität als ein Platzhalter-Eintrag, sodass bei der Auflösung des FQDN der Anwendung kein Konflikt entsteht.
Anmerkung
  • Die externe Netzkomponente muss alle sicheren TLS-Verbindungen beenden. Wenn die Verbindungen zum Lastenverteiler des Ziel-Clusters weitergeleitet werden, ist der FQDN der Zielanwendung für den Client zugänglich und es treten Zertifikatsfehler auf.
  • Die Anwendungen dürfen den Clients keine Links zurückgeben, die auf die Ziel-Cluster-Domain verweisen. Andernfalls könnten Teile der Anwendung nicht geladen werden oder nicht richtig funktionieren.

4.1.2. Einrichten des Ziel-Clusters zur Annahme der Quell-DNS-Domain

Sie können den Ziel-Cluster so einrichten, dass er Anfragen für eine migrierte Anwendung in der DNS-Domain des Quell-Clusters annimmt.

Vorgehensweise

Führen Sie sowohl für den nicht sicheren HTTP-Zugang als auch für den sicheren HTTPS-Zugang die folgenden Schritte durch:

  1. Erstellen Sie im Projekt des Ziel-Clusters eine Route, die so konfiguriert ist, dass sie Anfragen annimmt, die an den FQDN der Anwendung im Quell-Cluster gerichtet sind:

    $ oc expose svc <app1-svc> --hostname <app1.apps.source.example.com> \
     -n <app1-namespace>

    Mit dieser neuen Route nimmt der Server jede Anfrage für diesen FQDN an und sendet sie an die entsprechenden Anwendungs-Pods. Darüber hinaus wird bei der Migration der Anwendung eine weitere Route in der Ziel-Cluster-Domain erstellt. Anfragen erreichen die migrierte Anwendung über einen dieser beiden Hostnamen.

  2. Erstellen Sie einen DNS-Eintrag bei Ihrem DNS-Anbieter, der den FQDN der Anwendung im Quell-Cluster auf die IP-Adresse des Standard-Lastenverteilers des Ziel-Clusters verweist. Dadurch wird der Datenverkehr von Ihrem Quell-Cluster zu Ihrem Ziel-Cluster umgeleitet.

    Der FQDN der Anwendung wird zum Lastenverteiler des Ziel-Clusters aufgelöst. Der standardmäßige Ingress-Controller-Router akzeptiert Anfragen für diesen FQDN, da eine Route für diesen Hostnamen zugänglich ist.

Für einen sicheren HTTPS-Zugang führen Sie den folgenden zusätzlichen Schritt durch:

  1. Ersetzen Sie das x509-Zertifikat des standardmäßigen Ingress-Controllers, das während des Installationsvorgangs erstellt wurde, durch ein benutzerdefiniertes Zertifikat.
  2. Konfigurieren Sie dieses Zertifikat so, dass es die Platzhalter-DNS-Domains für den Quell- und den Ziel-Cluster im Feld subjectAltName enthält.

    Das neue Zertifikat ist für die Sicherung von Verbindungen gültig, die über eine der beiden DNS-Domains hergestellt werden.

Zusätzliche Ressourcen

4.2. Methoden zur Umleitung des Netzwerkverkehrs

Nach einer erfolgreichen Migration müssen Sie den Netzwerkverkehr Ihrer zustandslosen Anwendungen vom Quell-Cluster zum Ziel-Cluster umleiten.

Die Methoden zur Umleitung des Netzwerkverkehrs beruhen auf folgenden Annahmen:

  • Die Anwendungspods werden sowohl auf dem Quell- als auch auf dem Ziel-Cluster ausgeführt.
  • Jede Anwendung hat eine Route, die den Hostnamen des Quell-Clusters enthält.
  • Die Route mit dem Hostnamen des Quell-Clusters enthält ein CA-Zertifikat.
  • Bei HTTPS enthält das CA-Zielzertifikat des Routers einen Subject Alternative Name für den Platzhalter-DNS-Eintrag des Quell-Clusters.

Ziehen Sie die folgenden Methoden in Betracht und wählen Sie diejenige aus, die Ihrer Zielsetzung entspricht.

  • Gleichzeitige Umleitung des gesamten Netzwerkverkehrs für alle Anwendungen

    Ändern Sie den Platzhalter-DNS-Eintrag des Quell-Clusters so, dass er auf die virtuelle IP-Adresse (VIP) des Ziel-Cluster-Routers zeigt.

    Diese Methode eignet sich für einfache Anwendungen oder kleine Migrationen.

  • Umleitung des Netzwerkverkehrs für einzelne Anwendungen

    Erstellen Sie für jede Anwendung einen DNS-Eintrag, wobei der Hostname des Quell-Clusters auf die VIP des Ziel-Cluster-Routers verweist. Dieser DNS-Eintrag hat Vorrang vor dem Platzhalter-DNS-Eintrag.

  • Schrittweise Umleitung des Netzwerkverkehrs für einzelne Anwendungen

    1. Erstellen Sie einen Proxy, der den Netzwerkverkehr für jede Anwendung sowohl an die VIP des Quell-Cluster-Routers als auch an die VIP des Ziel-Cluster-Routers weiterleiten kann.
    2. Erstellen Sie für jede Anwendung einen DNS-Eintrag mit dem Hostnamen des Quell-Clusters, der auf den Proxy verweist.
    3. Konfigurieren Sie den Proxy-Eintrag für die Anwendung so, dass ein bestimmter Prozentsatz des Netzwerkverkehrs an die VIP des Ziel-Cluster-Routers und der Rest des Datenverkehrs an das VIP des Quell-Cluster-Routers geleitet wird.
    4. Erhöhen Sie schrittweise den Prozentsatz des Netzwerkverkehrs, den Sie an die VIP des Ziel-Cluster-Routers weiterleiten, bis der gesamte Netzwerkverkehr umgeleitet ist.
  • Benutzerbasierte Umleitung des Netzwerkverkehrs für einzelne Anwendungen

    Mit dieser Methode können Sie TCP/IP-Header von Benutzeranfragen filtern, um den Netzwerkverkehr für vordefinierte Gruppen von Benutzern umzuleiten. Auf diese Weise können Sie den Umleitungsvorgang an bestimmten Benutzergruppen testen, bevor Sie den gesamten Netzwerkverkehr umleiten.

    1. Erstellen Sie einen Proxy, der den Netzwerkverkehr für jede Anwendung sowohl an die VIP des Quell-Cluster-Routers als auch an die VIP des Ziel-Cluster-Routers weiterleiten kann.
    2. Erstellen Sie für jede Anwendung einen DNS-Eintrag mit dem Hostnamen des Quell-Clusters, der auf den Proxy verweist.
    3. Konfigurieren Sie den Proxy-Eintrag für die Anwendung so, dass Netzwerkverkehr, der einem bestimmten Header-Muster entspricht, z. B. test customers, an die VIP des Ziel-Cluster-Routers und der restliche Datenverkehr an die VIP des Quell-Cluster-Routers geleitet wird.
    4. Leiten Sie den Netzwerkverkehr schrittweise auf die VIP des Ziel-Cluster-Routers um, bis der gesamte Netzwerkverkehr auf der VIP des Ziel-Cluster-Routers läuft.

Kapitel 5. Informationen zum Migration Toolkit for Containers

Mit dem Migration Toolkit for Containers (MTC) können Sie zustandsbehaftete Anwendungs-Workloads von OpenShift Container Platform 3 zu 4.10 auf der Granularität eines Namespaces migrieren.

Wichtig

Bevor Sie mit der Migration beginnen, sollten Sie sich über die Unterschiede zwischen OpenShift Container Platform 3 und 4 informieren.

MTC bietet eine Webkonsole und eine API, die auf benutzerdefinierten Kubernetes-Ressourcen basiert, um die Migration zu steuern und die Ausfallzeiten von Anwendungen zu minimieren.

Die MTC-Konsole wird standardmäßig auf dem Ziel-Cluster installiert. Sie können den Migration Toolkit for Containers Operator so konfigurieren, dass die Konsole auf einem Quell-Cluster der OpenShift Container Platform 3 oder auf einem Remote-Cluster installiert wird.

MTC unterstützt die Dateisystem- und Schnappschuss-Datenkopiermethoden für die Migration von Daten aus dem Quell-Cluster in den Ziel-Cluster. Sie können eine Methode wählen, die für Ihre Umgebung geeignet ist und von Ihrem Speicheranbieter unterstützt wird.

Der Servicekatalog wird in OpenShift Container Platform 4 eingestellt. Sie können Workload-Ressourcen, die mit dem Servicekatalog bereitgestellt wurden, von OpenShift Container Platform 3 zu 4 migrieren, aber Sie können nach der Migration keine Servicekatalog-Aktionen wie provision, deprovision oder update für diese Workloads durchführen. Die MTC-Konsole zeigt eine Meldung an, wenn die Servicekatalogressourcen nicht migriert werden können.

5.1. Terminologie

Tabelle 5.1. MTC-Terminologie

BegriffDefinition

Quellen-Cluster

Cluster, aus dem die Anwendungen migriert werden.

Ziel-Cluster[1]

Cluster, in den die Anwendungen migriert werden.

Replikations-Repository

Objektspeicher zum Kopieren von Images, Volumes und Kubernetes-Objekten bei indirekter Migration oder für Kubernetes-Objekte bei Direct Volume Migration oder Direct Image Migration.

Das Replikations-Repository muss für alle Cluster zugänglich sein.

Host-Cluster

Cluster, auf dem der Pod migration-controller und die Webkonsole ausgeführt werden. Der Host-Cluster ist in der Regel der Ziel-Cluster, dies ist jedoch nicht erforderlich.

Der Host-Cluster benötigt keine zur Verfügung gestellte Registrierungsroute für die Direct Image Migration.

Remote-Cluster

Ein Remote-Cluster ist normalerweise der Quell-Cluster, dies ist jedoch nicht erforderlich.

Für einen Remote-Cluster ist eine benutzerdefinierte Ressource Secret erforderlich, die das Service Account-Token migration-controller enthält.

Ein Remote-Cluster erfordert eine zur Verfügung gestellte sichere Registrierungsroute für die Direct Image Migration.

Indirekte Migration

Images, Volumes und Kubernetes-Objekte werden vom Quell-Cluster in das Replikations-Repository und anschließend vom Replikations-Repository in den Ziel-Cluster kopiert.

Direct Volume Migration

Persistent Volumes werden direkt vom Quell-Cluster auf den Ziel-Cluster kopiert.

Direct Image Migration

Die Bilder werden direkt vom Quell-Cluster auf den Ziel-Cluster kopiert.

Stage-Migration

Die Daten werden auf den Ziel-Cluster kopiert, ohne dass die Anwendung angehalten wird.

Die mehrfache Ausführung einer Stage-Migration verkürzt die Dauer der Cutover-Migration.

Cutover-Migration

Die Anwendung wird auf dem Quell-Cluster gestoppt und ihre Ressourcen werden auf den Ziel-Cluster migriert.

State-Migration

Der Anwendungszustand wird migriert, indem bestimmte Persistent Volume Claims und Kubernetes-Objekte auf den Ziel-Cluster kopiert werden.

Rollback-Migration

Die Rollback-Migration setzt eine abgeschlossene Migration zurück.

1 Rufen Sie den Zielcluster in der MTC-Webkonsole auf.

5.2. MTC-Workflow

Sie können Kubernetes-Ressourcen, Persistent Volume-Daten und interne Container-Images auf OpenShift Container Platform 4.10 migrieren, indem Sie die MTC-Webkonsole (Migration Toolkit for Containers) oder die Kubernetes-API verwenden.

MTC migriert die folgenden Ressourcen:

  • Ein in einem Migrationsplan angegebener Namespace.
  • Namespace-gebundene Ressourcen: Wenn der MTC einen Namespace migriert, migriert er alle mit diesem Namespace verbundenen Objekte und Ressourcen, wie z. B. Dienste oder Pods. Wenn außerdem eine Ressource, die im Namespace, aber nicht auf Cluster-Ebene existiert, von einer Ressource abhängt, die auf Cluster-Ebene existiert, migriert das MTC beide Ressourcen.

    Ein Security Context Constraint (SCC) ist beispielsweise eine Ressource, die auf Cluster-Ebene existiert, und ein Service Account (SA) ist eine Ressource, die auf Namespace-Ebene existiert. Wenn ein SA in einem Namespace existiert, den das MTC migriert, findet der MTC automatisch alle SCCs, die mit dem SA verknüpft sind, und migriert auch diese SCCs. In ähnlicher Weise migriert der MTC Persistent Volume Claims, die mit den Persistent Volumes des Namespace verknüpft sind.

    Anmerkung

    Cluster-gebundene Ressourcen müssen je nach Ressource möglicherweise manuell migriert werden.

  • Custom Resources (CRs) und Custom Resource Definitions (CRDs): MTC migriert automatisch CRs und CRDs auf Namespace-Ebene.

Die Migration einer Anwendung mit der MTC-Webkonsole umfasst die folgenden Schritte:

  1. Installieren Sie den Migration Toolkit for Containers Operator auf allen Clustern.

    Sie können den Migration Toolkit for Containers Operator in einer eingeschränkten Umgebung mit begrenztem oder keinem Internetzugang installieren. Die Quell- und Ziel-Cluster müssen über einen Netzwerkzugang zueinander und zu einer Spiegelregistrierung verfügen.

  2. Konfigurieren Sie das Replikations-Repository, einen temporären Objektspeicher, den MTC für die Datenmigration verwendet.

    Quell- und Ziel-Cluster müssen während der Migration Netzwerkzugriff auf das Replikations-Repository haben. Wenn Sie einen Proxyserver verwenden, müssen Sie ihn so konfigurieren, dass der Netzwerkverkehr zwischen dem Replikations-Repository und den Clustern zugelassen wird.

  3. Fügen Sie den Quell-Cluster zur MTC-Webkonsole hinzu.
  4. Fügen Sie das Replikations-Repository zur MTC-Webkonsole hinzu.
  5. Erstellen Sie einen Migrationsplan mit einer der folgenden Datenmigrationsoptionen:

    • Copy: MTC kopiert die Daten aus dem Quell-Cluster in das Replikations-Repository und aus dem Replikations-Repository in den Ziel-Cluster.

      Anmerkung

      Bei der Direct Image Migration oder der Direct Volume Migration werden die Images oder Volumes direkt vom Quell-Cluster auf den Ziel-Cluster kopiert.

      PV-Migration – Copy
    • Move: MTC gebt die Bereitstellung eines Remote-Volume auf, z. B. NFS auf dem Quell-Cluster, erstellt eine PV-Ressource auf dem Ziel-Cluster, die auf das Remote-Volume zeigt, und stellt dann das Remote-Volume auf dem Ziel-Cluster bereit. Anwendungen, die auf dem Ziel-Cluster ausgeführt werden, verwenden dasselbe Remote-Volume, das auch der Quell-Cluster verwendet hat. Das Remote-Volume muss für den Quell- und den Ziel-Cluster zugänglich sein.

      Anmerkung

      Obwohl das Replikations-Repository in diesem Diagramm nicht angezeigt wird, ist es für die Migration erforderlich.

      PV-Migration – Move
  6. Führen Sie den Migrationsplan mit einer der folgenden Optionen aus:

    • Stage kopiert Daten auf den Ziel-Cluster, ohne die Anwendung anzuhalten.

      Eine Stage-Migration kann mehrfach durchgeführt werden, sodass die meisten Daten vor der Migration auf das Ziel kopiert werden. Die Durchführung einer oder mehrerer Stage-Migrationen verkürzt die Dauer der Cutover-Migration.

    • Cutover stoppt die Anwendung auf dem Quell-Cluster und verschiebt die Ressourcen auf den Ziel-Cluster.

      Optional: Sie können das Kontrollkästchen Halt transactions on the source cluster during migration deaktivieren.

OCP 3 zu 4 – App-Migration

5.3. Informationen zu Datenkopiermethoden

Das Migration Toolkit for Containers (MTC) unterstützt die Dateisystem- und Schnappschuss-Datenkopiermethoden für die Migration von Daten aus dem Quell-Cluster in den Ziel-Cluster. Sie können eine Methode wählen, die für Ihre Umgebung geeignet ist und von Ihrem Speicheranbieter unterstützt wird.

5.3.1. Dateisystem-Kopiermethode

MTC kopiert Datendateien aus dem Quell-Cluster in das Replikations-Repository und von dort in den Ziel-Cluster.

Die Dateisystem-Kopiermethode verwendet Restic für die indirekte Migration oder Rsync für die Direct Volume Migration.

Tabelle 5.2. Zusammenfassung der Dateisystem-Kopiermethode

VorteileEinschränkungen
  • Cluster können verschiedene Speicherklassen haben.
  • Unterstützt für alle S3-Speicheranbieter.
  • Optionale Datenverifizierung mit Prüfsumme.
  • Unterstützt die direkte Migration von Volumes, was die Leistung erheblich steigert.
  • Langsamer als die Schnappschuss-Kopiermethode.
  • Die optionale Datenverifizierung verringert die Leistung erheblich.

5.3.2. Schnappschuss-Kopiermethode

MTC kopiert einen Schnappschuss der Daten des Quell-Clusters in das Replikations-Repository eines Cloud-Anbieters. Die Daten werden auf dem Ziel-Cluster wiederhergestellt.

Die Schnappschuss-Kopiermethode kann mit Amazon Web Services, Google Cloud Provider und Microsoft Azure verwendet werden.

Tabelle 5.3. Zusammenfassung der Schnappschuss-Kopiermethode

VorteileEinschränkungen
  • Schneller als die Dateisystem-Kopiermethode.
  • Der Cloud-Anbieter muss Schnappschüsse unterstützen.
  • Die Cluster müssen sich beim selben Cloud-Anbieter befinden.
  • Die Cluster müssen sich am selben Ort oder in derselben Region befinden.
  • Die Cluster müssen dieselbe Speicherklasse haben.
  • Die Speicherklasse muss mit Schnappschüssen kompatibel sein.
  • Unterstützt keine Direct Volume Migration.

5.4. Direct Volume Migration und Direct Image Migration

Sie können die Direct Image Migration (DIM) und die Direct Volume Migration (DVM) verwenden, um Images und Daten direkt vom Quell-Cluster zum Ziel-Cluster zu migrieren.

Wenn Sie die DVM mit Knoten durchführen, die sich in unterschiedlichen Verfügbarkeitszonen befinden, kann die Migration fehlschlagen, weil die migrierten Pods nicht auf den Persistent Volume Claim zugreifen können.

Die DIM und DVM bieten erhebliche Leistungsvorteile, da die Zwischenschritte des Backups von Dateien aus dem Quell-Cluster in das Replikations-Repository und der Wiederherstellung von Dateien aus dem Replikations-Repository in den Ziel-Cluster übersprungen werden. Die Daten werden mit Rsync übertragen.

Für die DIM und DVM gibt es zusätzliche Voraussetzungen.

Kapitel 6. Installation des Migration Toolkit for Containers

Sie können das Migration Toolkit for Containers (MTC) auf OpenShift Container Platform 3 und 4 installieren.

Nach der Installation von Migration Toolkit for Containers Operator auf OpenShift Container Platform 4.10 mit Hilfe des Operator Lifecycle Managers installieren Sie manuell den Legacy Migration Toolkit for Containers Operator auf OpenShift Container Platform 3.

Standardmäßig werden die MTC-Webkonsole und der Pod Migration Controller auf dem Ziel-Cluster ausgeführt. Sie können das Manifest der Custom Resource Migration Controller so konfigurieren, dass die MTC-Webkonsole und der Pod Migration Controller auf einem Quell-Cluster oder einem Remote-Cluster ausgeführt werden.

Nach der Installation von MTC müssen Sie einen Objektspeicher für die Verwendung als Replikations-Repository konfigurieren.

Informationen zur Deinstallation von MTC finden Sie unter Deinstallation von MTC und Löschen von Ressourcen.

6.1. Kompatibilitäts-Leitlinien

Sie müssen den Migration Toolkit for Containers (MTC) Operator installieren, der mit Ihrer OpenShift Container Platform-Version kompatibel ist.

Sie können MTC 1.6 nicht auf OpenShift Container Platform 4.5 oder früheren Versionen installieren, da die Versionen der Custom Resource Definition API nicht kompatibel sind.

Sie können Workloads von einem Quell-Cluster mit MTC 1.5.3 zu einem Ziel-Cluster mit MTC 1.6 migrieren, solange die benutzerdefinierte Ressource MigrationController und die MTC-Webkonsole auf dem Ziel-Cluster ausgeführt werden.

Tabelle 6.1. Kompatibilität von OpenShift Container Platform und MTC

Version der OpenShift Container PlatformMTC-VersionMigration Toolkit for Containers Operator

4.5 und früher

1.5.3

Legacy Migration Toolkit for Containers Operator, manuell mit der Datei operator.yml installiert.

4.6 und später

Neueste Version 1.6.x von z-stream

Migration Toolkit for Containers Operator, installiert mit Operator Lifecycle Manager.

6.2. Installation des Legacy Migration Toolkit for Containers Operator auf OpenShift Container Platform 3

Sie können den Legacy Migration Toolkit for Containers Operator manuell auf OpenShift Container Platform 3 installieren.

Voraussetzungen

  • Sie müssen auf allen Clustern als Benutzer mit cluster-admin-Privilegien angemeldet sein.
  • Sie müssen Zugriff auf registry.redhat.io haben.
  • Sie müssen podman installiert haben.
  • Sie müssen ein Image Stream-Geheimnis erstellen und es auf jeden Knoten im Cluster kopieren.

Vorgehensweise

  1. Melden Sie sich mit Ihren Anmeldedaten für das Red Hat Customer Portal bei registry.redhat.io an:

    $ sudo podman login registry.redhat.io
  2. Laden Sie die Datei operator.yml herunter:

    $ sudo podman cp $(sudo podman create \
      registry.redhat.io/rhmtc/openshift-migration-legacy-rhel8-operator:v1.5.3):/operator.yml ./
  3. Laden Sie die Datei controller.yml herunter:

    $ sudo podman cp $(sudo podman create \
      registry.redhat.io/rhmtc/openshift-migration-legacy-rhel8-operator:v1.5.3):/controller.yml ./
  4. Melden Sie sich bei Ihrem OpenShift Container Platform 3-Cluster an.
  5. Überprüfen Sie, ob sich der Cluster bei registry.redhat.io authentifizieren kann:

    $ oc run test --image registry.redhat.io/ubi8 --command sleep infinity
  6. Erstellen Sie das Objekt Migration Toolkit for Containers Operator:

    $ oc create -f operator.yml

    Beispielausgabe

    namespace/openshift-migration created
    rolebinding.rbac.authorization.k8s.io/system:deployers created
    serviceaccount/migration-operator created
    customresourcedefinition.apiextensions.k8s.io/migrationcontrollers.migration.openshift.io created
    role.rbac.authorization.k8s.io/migration-operator created
    rolebinding.rbac.authorization.k8s.io/migration-operator created
    clusterrolebinding.rbac.authorization.k8s.io/migration-operator created
    deployment.apps/migration-operator created
    Error from server (AlreadyExists): error when creating "./operator.yml":
    rolebindings.rbac.authorization.k8s.io "system:image-builders" already exists 1
    Error from server (AlreadyExists): error when creating "./operator.yml":
    rolebindings.rbac.authorization.k8s.io "system:image-pullers" already exists

    1
    Sie können die Meldung Error from server (AlreadyExists) ignorieren. Sie werden durch den Migration Toolkit for Containers Operator verursacht, der Ressourcen für frühere Versionen von OpenShift Container Platform 3 erstellt, die in späteren Versionen bereitgestellt werden.
  7. Erstellen Sie das Objekt MigrationController:

    $ oc create -f controller.yml
  8. Überprüfen Sie, ob die MTC-Pods ausgeführt werden:

    $ oc get pods -n openshift-migration

6.3. Installation von Migration Toolkit for Containers Operator auf OpenShift Container Platform 4.10

Sie installieren den Migration Toolkit for Containers Operator auf OpenShift Container Platform 4.10 mit Hilfe des Operator Lifecycle Managers.

Voraussetzungen

  • Sie müssen auf allen Clustern als Benutzer mit cluster-admin-Privilegien angemeldet sein.

Vorgehensweise

  1. Klicken Sie in der Webkonsole der OpenShift Container Platform auf OperatorsOperatorHub.
  2. Verwenden Sie das Feld Filter by keyword, um den Migration Toolkit for Containers Operator zu finden.
  3. Wählen Sie den Migration Toolkit for Containers Operator aus und klicken Sie auf Install.
  4. Klicken Sie auf Install.

    Auf der Seite Installed Operators wird der Migration Toolkit for Containers Operator im Projekt openshift-migration mit dem Status Succeeded angezeigt.

  5. Klicken Sie auf Migration Toolkit for Containers Operator.
  6. Suchen Sie unter Provided APIs die Kachel Migration Controller und klicken Sie auf Create Instance.
  7. Klicken Sie auf Create.
  8. Klicken Sie auf WorkloadsPods, um zu überprüfen, ob die MTC-Pods ausgeführt werden.

6.4. Konfigurieren von Proxys

Für OpenShift Container Platform 4.1 und frühere Versionen müssen Sie, nachdem Sie den Migration Toolkit for Containers Operator installiert haben, Proxys im Manifest der Custom Resource (CR) MigrationController konfigurieren, da diese Versionen kein clusterweites Proxy-Objekt unterstützen.

Für OpenShift Container Platform 4.2 bis 4.10 erbt das Migration Toolkit for Containers (MTC) die clusterweiten Proxy-Einstellungen. Sie können die Proxy-Parameter ändern, wenn Sie die clusterweiten Proxy-Einstellungen außer Kraft setzen wollen.

Sie müssen die Proxys so konfigurieren, dass sie das SPDY-Protokoll zulassen und den Header Upgrade HTTP an den API-Server weiterleiten. Andernfalls wird die Fehlermeldung Upgrade request required angezeigt. Die CR MigrationController verwendet SPDY, um Befehle in Remote-Pods auszuführen. Der Header Upgrade HTTP ist erforderlich, um eine Websocket-Verbindung mit dem API-Server zu öffnen.

Direct Volume Migration

Wenn Sie eine Direct Volume Migration (DVM) von einem Quell-Cluster hinter einem Proxy durchführen, müssen Sie einen Stunnel-Proxy konfigurieren. Stunnel erstellt einen transparenten Tunnel zwischen dem Quell- und dem Ziel-Cluster für die TCP-Verbindung, ohne die Zertifikate zu ändern.

Die DVM unterstützt nur einen Proxy. Der Quell-Cluster kann nicht auf die Route des Ziel-Clusters zugreifen, wenn sich der Ziel-Cluster ebenfalls hinter einem Proxy befindet.

Voraussetzungen

  • Sie müssen auf allen Clustern als Benutzer mit cluster-admin-Privilegien angemeldet sein.

Vorgehensweise

  1. Rufen Sie das CR-Manifest MigrationController ab:

    $ oc get migrationcontroller <migration_controller> -n openshift-migration
  2. Aktualisieren Sie die Proxy-Parameter:

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigrationController
    metadata:
      name: <migration_controller>
      namespace: openshift-migration
    ...
    spec:
      stunnel_tcp_proxy: http://<username>:<password>@<ip>:<port> 1
      httpProxy: http://<username>:<password>@<ip>:<port> 2
      httpsProxy: http://<username>:<password>@<ip>:<port> 3
      noProxy: example.com 4
    1
    Stunnel-Proxy-URL für die Direct Volume Migration.
    2
    Proxy-URL für die Erstellung von HTTP-Verbindungen außerhalb des Clusters. Das URL-Schema muss http sein.
    3
    Proxy-URL für die Erstellung von HTTPS-Verbindungen außerhalb des Clusters. Wenn dies nicht angegeben wird, wird httpProxy sowohl für HTTP- als auch für HTTPS-Verbindungen verwendet.
    4
    Durch Kommata getrennte Liste von Zieldomain-Namen, Domains, IP-Adressen oder anderen Netzwerk-CIDRs zum Ausschluss von Proxying.

    Stellen Sie einer Domain ein . voran, um nur Subdomains zu finden. Zum Beispiel gibt es bei .y.com eine Übereinstimmung mit x.y.com, aber nicht mit y.com. Verwenden Sie *, um den Proxy für alle Ziele zu umgehen. Wenn Sie Worker hochskalieren, die nicht in dem durch das Installationskonfigurationsfeld networking.machineNetwork[].cidr definierten Netzwerk enthalten sind, müssen Sie sie zu dieser Liste hinzufügen, um Verbindungsprobleme zu vermeiden.

    Dieses Feld wird ignoriert, wenn weder das Feld httpProxy noch das Feld httpsProxy konfiguriert ist.

  3. Speichern Sie das Manifest als migration-controller.yaml.
  4. Wenden Sie das aktualisierte Manifest an:

    $ oc replace -f migration-controller.yaml -n openshift-migration

Weitere Informationen finden Sie unter Konfigurieren des clusterweiten Proxys.

6.5. Konfigurieren eines Replikations-Repositorys

Sie müssen einen Objektspeicher für die Verwendung als Replikations-Repository konfigurieren. Das Migration Toolkit for Containers (MTC) kopiert Daten aus dem Quell-Cluster in das Replikations-Repository und anschließend aus dem Replikations-Repository in den Ziel-Cluster.

MTC unterstützt die Dateisystem- und Schnappschuss-Datenkopiermethoden für die Migration von Daten aus dem Quell-Cluster in den Ziel-Cluster. Sie können eine Methode wählen, die für Ihre Umgebung geeignet ist und von Ihrem Speicheranbieter unterstützt wird.

Die folgenden Speicheranbieter werden unterstützt:

6.5.1. Voraussetzungen

  • Alle Cluster müssen ununterbrochenen Netzwerkzugriff zum Replikations-Repository haben.
  • Wenn Sie einen Proxy-Server mit einem intern gehosteten Replikations-Repository verwenden, müssen Sie sicherstellen, dass der Proxy den Zugriff auf das Replikations-Repository erlaubt.

6.5.2. Abrufen von Anmeldedaten für Multicloud Object Gateway

Sie müssen die Anmeldedaten für Multicloud Object Gateway (MCG) und den S3-Endpunkt abrufen, um MCG als Replikations-Repository für das Migration Toolkit for Containers (MTC) zu konfigurieren. Sie müssen die Anmeldedaten für Multicloud Object Gateway (MCG) abrufen, um eine Secret Custom Resource (CR) für die OpenShift API for Data Protection (OADP) zu erstellen.

MCG ist eine Komponente von OpenShift Container Storage.

Voraussetzungen

Vorgehensweise

  1. Ermitteln Sie den S3-Endpunkt, die AWS_ACCESS_KEY_ID und den AWS_SECRET_ACCESS_KEY, indem Sie den Befehl describe für die benutzerdefinierte NooBaa-Ressource ausführen.

    Sie verwenden diese Anmeldedaten, um MCG als Replikations-Repository hinzuzufügen.

6.5.3. Konfigurieren von Amazon Web Services

Sie konfigurieren den S3-Objektspeicher von Amazon Web Services (AWS) als Replikations-Repository für das Migration Toolkit for Containers (MTC).

Voraussetzungen

  • Sie müssen die AWS CLI installiert haben.
  • Der Speicher-Bucket für AWS S3 muss für den Quell- und den Ziel-Cluster zugänglich sein.
  • Wenn Sie die Schnappschuss-Kopiermethode verwenden:

    • Sie müssen Zugang zu EC2 Elastic Block Storage (EBS) haben.
    • Der Quell- und der Ziel-Cluster müssen sich in derselben Region befinden.
    • Die Quell- und Ziel-Cluster müssen dieselbe Speicherklasse haben.
    • Die Speicherklasse muss mit Schnappschüssen kompatibel sein.

Vorgehensweise

  1. Legen Sie die Variable BUCKET fest:

    $ BUCKET=<your_bucket>
  2. Legen Sie die Variable REGION fest:

    $ REGION=<your_region>
  3. Erstellen Sie einen AWS S3-Bucket:

    $ aws s3api create-bucket \
        --bucket $BUCKET \
        --region $REGION \
        --create-bucket-configuration LocationConstraint=$REGION 1
    1
    us-east-1 unterstützt keinen LocationConstraint. Wenn Ihre Region us-east-1 ist, lassen Sie --create-bucket-configuration LocationConstraint=$REGION weg.
  4. Erstellen Sie einen IAM-Benutzer:

    $ aws iam create-user --user-name velero 1
    1
    Wenn Sie Velero für die Sicherung mehrerer Cluster mit mehreren S3-Buckets verwenden möchten, erstellen Sie für jeden Cluster einen eindeutigen Benutzernamen.
  5. Erstellen Sie die Datei velero-policy.json:

    $ cat > velero-policy.json <<EOF
    {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Effect": "Allow",
                "Action": [
                    "ec2:DescribeVolumes",
                    "ec2:DescribeSnapshots",
                    "ec2:CreateTags",
                    "ec2:CreateVolume",
                    "ec2:CreateSnapshot",
                    "ec2:DeleteSnapshot"
                ],
                "Resource": "*"
            },
            {
                "Effect": "Allow",
                "Action": [
                    "s3:GetObject",
                    "s3:DeleteObject",
                    "s3:PutObject",
                    "s3:AbortMultipartUpload",
                    "s3:ListMultipartUploadParts"
                ],
                "Resource": [
                    "arn:aws:s3:::${BUCKET}/*"
                ]
            },
            {
                "Effect": "Allow",
                "Action": [
                    "s3:ListBucket"
                ],
                "Resource": [
                    "arn:aws:s3:::${BUCKET}"
                ]
            }
        ]
    }
    EOF
  6. Fügen Sie die Richtlinien hinzu, um dem Benutzer velero die erforderlichen Berechtigungen zu erteilen:

    $ aws iam put-user-policy \
      --user-name velero \
      --policy-name velero \
      --policy-document file://velero-policy.json
  7. Erstellen Sie einen Zugriffsschlüssel für den Benutzer velero:

    $ aws iam create-access-key --user-name velero

    Beispielausgabe

    {
      "AccessKey": {
            "UserName": "velero",
            "Status": "Active",
            "CreateDate": "2017-07-31T22:24:41.576Z",
            "SecretAccessKey": <AWS_SECRET_ACCESS_KEY>,
            "AccessKeyId": <AWS_ACCESS_KEY_ID>
      }
    }

    Halten Sie den AWS_SECRET_ACCESS_KEY und die AWS_ACCESS_KEY_ID fest. Sie benötigen die Anmeldedaten, um AWS als Replikations-Repository hinzuzufügen.

6.5.4. Konfigurieren von Google Cloud Platform

Sie konfigurieren einen Speicher-Bucket von Google Cloud Platform (GCP) als Replikations-Repository für das Migration Toolkit for Containers (MTC).

Voraussetzungen

  • Sie müssen die CLI-Tools gcloud und gsutil installiert haben. Einzelheiten finden Sie in der Dokumentation für Google Cloud.
  • Der GCP-Speicher-Bucket muss für den Quell- und den Ziel-Cluster zugänglich sein.
  • Wenn Sie die Schnappschuss-Kopiermethode verwenden:

    • Der Quell- und der Ziel-Cluster müssen sich in derselben Region befinden.
    • Die Quell- und Ziel-Cluster müssen dieselbe Speicherklasse haben.
    • Die Speicherklasse muss mit Schnappschüssen kompatibel sein.

Vorgehensweise

  1. Melden Sie sich bei GCP an:

    $ gcloud auth login
  2. Legen Sie die Variable BUCKET fest:

    $ BUCKET=<bucket> 1
    1
    Geben Sie den Namen Ihres Buckets an.
  3. Erstellen Sie den Speicher-Bucket:

    $ gsutil mb gs://$BUCKET/
  4. Legen Sie für die Variable PROJECT_ID Ihr aktives Projekt fest:

    $ PROJECT_ID=$(gcloud config get-value project)
  5. Erstellen Sie einen Service Account:

    $ gcloud iam service-accounts create velero \
        --display-name "Velero service account"
  6. Listen Sie Ihre Service Accounts auf:

    $ gcloud iam service-accounts list
  7. Legen Sie für die Variable SERVICE_ACCOUNT_EMAIL den entsprechenden email-Wert fest:

    $ SERVICE_ACCOUNT_EMAIL=$(gcloud iam service-accounts list \
        --filter="displayName:Velero service account" \
        --format 'value(email)')
  8. Fügen Sie die Richtlinien hinzu, um dem Benutzer velero die erforderlichen Berechtigungen zu erteilen:

    $ ROLE_PERMISSIONS=(
        compute.disks.get
        compute.disks.create
        compute.disks.createSnapshot
        compute.snapshots.get
        compute.snapshots.create
        compute.snapshots.useReadOnly
        compute.snapshots.delete
        compute.zones.get
    )
  9. Erstellen Sie die benutzerdefinierte Rolle velero.server:

    $ gcloud iam roles create velero.server \
        --project $PROJECT_ID \
        --title "Velero Server" \
        --permissions "$(IFS=","; echo "${ROLE_PERMISSIONS[*]}")"
  10. Fügen Sie dem Projekt eine IAM-Richtlinienbindung hinzu:

    $ gcloud projects add-iam-policy-binding $PROJECT_ID \
        --member serviceAccount:$SERVICE_ACCOUNT_EMAIL \
        --role projects/$PROJECT_ID/roles/velero.server
  11. Aktualisieren Sie den IAM-Service Account:

    $ gsutil iam ch serviceAccount:$SERVICE_ACCOUNT_EMAIL:objectAdmin gs://${BUCKET}
  12. Speichern Sie die Schlüssel des IAM-Service Accounts in der Datei credentials-velero im aktuellen Verzeichnis:

    $ gcloud iam service-accounts keys create credentials-velero \
        --iam-account $SERVICE_ACCOUNT_EMAIL

    Sie verwenden die Datei credentials-velero, um GCP als Replikations-Repository hinzuzufügen.

6.5.5. Konfigurieren von Microsoft Azure

Sie konfigurieren einen Microsoft Azure Blob-Speichercontainer als Replikations-Repository für das Migration Toolkit for Containers (MTC).

Voraussetzungen

  • Sie müssen die Azure CLI installiert haben.
  • Der Azure Blob-Speichercontainer muss für den Quell- und den Ziel-Cluster zugänglich sein.
  • Wenn Sie die Schnappschuss-Kopiermethode verwenden:

    • Der Quell- und der Ziel-Cluster müssen sich in derselben Region befinden.
    • Die Quell- und Ziel-Cluster müssen dieselbe Speicherklasse haben.
    • Die Speicherklasse muss mit Schnappschüssen kompatibel sein.

Vorgehensweise

  1. Melden Sie sich bei Azure an:

    $ az login
  2. Legen Sie die Variable AZURE_RESOURCE_GROUP fest:

    $ AZURE_RESOURCE_GROUP=Velero_Backups
  3. Erstellen Sie eine Azure-Ressourcengruppe:

    $ az group create -n $AZURE_RESOURCE_GROUP --location CentralUS 1
    1
    Geben Sie Ihren Standort an.
  4. Legen Sie die Variable AZURE_STORAGE_ACCOUNT_ID fest:

    $ AZURE_STORAGE_ACCOUNT_ID="velero$(uuidgen | cut -d '-' -f5 | tr '[A-Z]' '[a-z]')"
  5. Erstellen Sie ein Azure-Speicherkonto:

    $ az storage account create \
        --name $AZURE_STORAGE_ACCOUNT_ID \
        --resource-group $AZURE_BACKUP_RESOURCE_GROUP \
        --sku Standard_GRS \
        --encryption-services blob \
        --https-only true \
        --kind BlobStorage \
        --access-tier Hot
  6. Legen Sie die Variable BLOB_CONTAINER fest:

    $ BLOB_CONTAINER=velero
  7. Erstellen Sie einen Azure Blob-Speichercontainer:

    $ az storage container create \
      -n $BLOB_CONTAINER \
      --public-access off \
      --account-name $AZURE_STORAGE_ACCOUNT_ID
  8. Erstellen Sie einen Service Principal und Anmeldedaten für velero:

    $ AZURE_SUBSCRIPTION_ID=`az account list --query '[?isDefault].id' -o tsv` \
      AZURE_TENANT_ID=`az account list --query '[?isDefault].tenantId' -o tsv` \
      AZURE_CLIENT_SECRET=`az ad sp create-for-rbac --name "velero" \
      --role "Contributor" --query 'password' -o tsv` \
      AZURE_CLIENT_ID=`az ad sp list --display-name "velero" \
      --query '[0].appId' -o tsv`
  9. Speichern Sie die Anmeldedaten des Service Principal in der Datei credentials-velero:

    $ cat << EOF > ./credentials-velero
    AZURE_SUBSCRIPTION_ID=${AZURE_SUBSCRIPTION_ID}
    AZURE_TENANT_ID=${AZURE_TENANT_ID}
    AZURE_CLIENT_ID=${AZURE_CLIENT_ID}
    AZURE_CLIENT_SECRET=${AZURE_CLIENT_SECRET}
    AZURE_RESOURCE_GROUP=${AZURE_RESOURCE_GROUP}
    AZURE_CLOUD_NAME=AzurePublicCloud
    EOF

    Sie verwenden die Datei credentials-velero, um Azure als Replikations-Repository hinzuzufügen.

6.5.6. Zusätzliche Ressourcen

6.6. Deinstallation des MTC und Löschen von Ressourcen

Sie können das Migration Toolkit for Containers (MTC) deinstallieren und seine Ressourcen löschen, um den Cluster zu bereinigen.

Anmerkung

Durch das Löschen der velero-CRDs wird Velero aus dem Cluster entfernt.

Voraussetzungen

  • Sie müssen als Benutzer mit cluster-admin-Privilegien angemeldet sein.

Vorgehensweise

  1. Löschen Sie die benutzerdefinierte Ressource (CR) MigrationController auf allen Clustern:

    $ oc delete migrationcontroller <migration_controller>
  2. Deinstallieren Sie den Migration Toolkit for Containers Operator auf OpenShift Container Platform 4 mit Hilfe des Operator Lifecycle Managers.
  3. Löschen Sie mit den folgenden Befehlen die Cluster-abhängigen Ressourcen auf allen Clustern:

    • Benutzerdefinierte migration-Ressourcendefinitionen (CRDs):

      $ oc delete $(oc get crds -o name | grep 'migration.openshift.io')
    • velero-CRDs:

      $ oc delete $(oc get crds -o name | grep 'velero')
    • migrationscluster-Rollen:

      $ oc delete $(oc get clusterroles -o name | grep 'migration.openshift.io')
    • migration-operator-Cluster-Rolle:

      $ oc delete clusterrole migration-operator
    • velero-Cluster-Rollen:

      $ oc delete $(oc get clusterroles -o name | grep 'velero')
    • migration-Cluster-Rollenbindungen:

      $ oc delete $(oc get clusterrolebindings -o name | grep 'migration.openshift.io')
    • migration-operator-Cluster-Rollenbindungen:

      $ oc delete clusterrolebindings migration-operator
    • velero-Cluster-Rollenbindungen:

      $ oc delete $(oc get clusterrolebindings -o name | grep 'velero')

Kapitel 7. Installation des Migration Toolkit for Containers in einer eingeschränkten Netzwerkumgebung

Sie können das Migration Toolkit for Containers (MTC) auf OpenShift Container Platform 3 und 4 in einer eingeschränkten Netzwerkumgebung installieren, indem Sie die folgenden Schritte durchführen:

  1. Erstellen Sie einen Operator-Katalog-Mirror.

    Bei diesem Vorgang wird die Datei mapping.txt erstellt, die die Zuordnung zwischen dem registry.redhat.io-Image und Ihrem Image für die Spiegelregistrierung enthält. Die Datei mapping.txt ist für die Installation des Operators auf dem Quell-Cluster erforderlich.

  2. Installieren Sie den Migration Toolkit for Containers Operator auf dem Ziel-Cluster von OpenShift Container Platform 4.10 mit Hilfe des Operator Lifecycle Manager.

    Standardmäßig werden die MTC-Webkonsole und der Pod Migration Controller auf dem Ziel-Cluster ausgeführt. Sie können das Manifest der Custom Resource Migration Controller so konfigurieren, dass die MTC-Webkonsole und der Pod Migration Controller auf einem Quell-Cluster oder einem Remote-Cluster ausgeführt werden.

  3. Installieren Sie über die Befehlszeilenschnittstelle den Legacy Migration Toolkit for Containers Operator auf dem Quell-Cluster von OpenShift Container Platform 3.
  4. Konfigurieren Sie den Objektspeicher für die Verwendung als Replikations-Repository.

Informationen zur Deinstallation von MTC finden Sie unter Deinstallation von MTC und Löschen von Ressourcen.

7.1. Kompatibilitäts-Leitlinien

Sie müssen den Migration Toolkit for Containers (MTC) Operator installieren, der mit Ihrer OpenShift Container Platform-Version kompatibel ist.

Sie können MTC 1.6 nicht auf OpenShift Container Platform 4.5 oder früheren Versionen installieren, da die Versionen der Custom Resource Definition API nicht kompatibel sind.

Sie können Workloads von einem Quell-Cluster mit MTC 1.5.3 zu einem Ziel-Cluster mit MTC 1.6 migrieren, solange die benutzerdefinierte Ressource MigrationController und die MTC-Webkonsole auf dem Ziel-Cluster ausgeführt werden.

Tabelle 7.1. Kompatibilität von OpenShift Container Platform und MTC

Version der OpenShift Container PlatformMTC-VersionMigration Toolkit for Containers Operator

4.5 und früher

1.5.3

Legacy Migration Toolkit for Containers Operator, manuell mit der Datei operator.yml installiert.

4.6 und später

Neueste Version 1.6.x von z-stream

Migration Toolkit for Containers Operator, installiert mit Operator Lifecycle Manager.

7.2. Installation von Migration Toolkit for Containers Operator auf OpenShift Container Platform 4.10

Sie installieren den Migration Toolkit for Containers Operator auf OpenShift Container Platform 4.10 mit Hilfe des Operator Lifecycle Managers.

Voraussetzungen

  • Sie müssen auf allen Clustern als Benutzer mit cluster-admin-Privilegien angemeldet sein.
  • Sie müssen einen Operator-Katalog aus einem Spiegel-Image in einer lokalen Registrierung erstellen.

Vorgehensweise

  1. Klicken Sie in der Webkonsole der OpenShift Container Platform auf OperatorsOperatorHub.
  2. Verwenden Sie das Feld Filter by keyword, um den Migration Toolkit for Containers Operator zu finden.
  3. Wählen Sie den Migration Toolkit for Containers Operator aus und klicken Sie auf Install.
  4. Klicken Sie auf Install.

    Auf der Seite Installed Operators wird der Migration Toolkit for Containers Operator im Projekt openshift-migration mit dem Status Succeeded angezeigt.

  5. Klicken Sie auf Migration Toolkit for Containers Operator.
  6. Suchen Sie unter Provided APIs die Kachel Migration Controller und klicken Sie auf Create Instance.
  7. Klicken Sie auf Create.
  8. Klicken Sie auf WorkloadsPods, um zu überprüfen, ob die MTC-Pods ausgeführt werden.

7.3. Installation des Legacy Migration Toolkit for Containers Operator auf OpenShift Container Platform 3

Sie können den Legacy Migration Toolkit for Containers Operator manuell auf OpenShift Container Platform 3 installieren.

Voraussetzungen

  • Sie müssen auf allen Clustern als Benutzer mit cluster-admin-Privilegien angemeldet sein.
  • Sie müssen Zugriff auf registry.redhat.io haben.
  • Sie müssen podman installiert haben.
  • Sie müssen ein Image Stream-Geheimnis erstellen und es auf jeden Knoten im Cluster kopieren.
  • Sie benötigen eine Linux-Workstation mit Netzwerkzugriff, um Dateien von registry.redhat.io herunterladen zu können.
  • Sie müssen ein Mirror-Image des Operator-Katalogs erstellen.
  • Sie müssen den Migration Toolkit for Containers Operator aus dem Operator-Katalog-Mirror auf OpenShift Container Platform 4.10 installieren.

Vorgehensweise

  1. Melden Sie sich mit Ihren Anmeldedaten für das Red Hat Customer Portal bei registry.redhat.io an:

    $ sudo podman login registry.redhat.io
  2. Laden Sie die Datei operator.yml herunter:

    $ sudo podman cp $(sudo podman create \
      registry.redhat.io/rhmtc/openshift-migration-legacy-rhel8-operator:v1.5.3):/operator.yml ./
  3. Laden Sie die Datei controller.yml herunter:

    $ sudo podman cp $(sudo podman create \
      registry.redhat.io/rhmtc/openshift-migration-legacy-rhel8-operator:v1.5.3):/controller.yml ./
  4. Rufen Sie die Operator-Image-Zuordnung ab, indem Sie den folgenden Befehl ausführen:

    $ grep openshift-migration-legacy-rhel8-operator ./mapping.txt | grep rhmtc

    Die Datei mapping.txt wurde erstellt, als Sie den Operator-Katalog-Mirror erstellt haben. Die Ausgabe zeigt die Zuordnung zwischen dem registry.redhat.io-Image und Ihrem Image für die Spiegelregistrierung.

    Beispielausgabe

    registry.redhat.io/rhmtc/openshift-migration-legacy-rhel8-operator@sha256:468a6126f73b1ee12085ca53a312d1f96ef5a2ca03442bcb63724af5e2614e8a=<registry.apps.example.com>/rhmtc/openshift-migration-legacy-rhel8-operator

  5. Aktualisieren Sie die image-Werte für die Container ansible und operator sowie den REGISTRY-Wert in der Datei operator.yml:

    containers:
      - name: ansible
        image: <registry.apps.example.com>/rhmtc/openshift-migration-legacy-rhel8-operator@sha256:<468a6126f73b1ee12085ca53a312d1f96ef5a2ca03442bcb63724af5e2614e8a> 1
    ...
      - name: operator
        image: <registry.apps.example.com>/rhmtc/openshift-migration-legacy-rhel8-operator@sha256:<468a6126f73b1ee12085ca53a312d1f96ef5a2ca03442bcb63724af5e2614e8a> 2
    ...
        env:
        - name: REGISTRY
          value: <registry.apps.example.com> 3
    1 2
    Geben Sie Ihre Spiegelregistrierung und den sha256-Wert des Operator-Images an.
    3
    Geben Sie Ihre Spiegelregistrierung an.
  6. Melden Sie sich bei Ihrem OpenShift Container Platform 3-Cluster an.
  7. Erstellen Sie das Objekt Migration Toolkit for Containers Operator:

    $ oc create -f operator.yml

    Beispielausgabe

    namespace/openshift-migration created
    rolebinding.rbac.authorization.k8s.io/system:deployers created
    serviceaccount/migration-operator created
    customresourcedefinition.apiextensions.k8s.io/migrationcontrollers.migration.openshift.io created
    role.rbac.authorization.k8s.io/migration-operator created
    rolebinding.rbac.authorization.k8s.io/migration-operator created
    clusterrolebinding.rbac.authorization.k8s.io/migration-operator created
    deployment.apps/migration-operator created
    Error from server (AlreadyExists): error when creating "./operator.yml":
    rolebindings.rbac.authorization.k8s.io "system:image-builders" already exists 1
    Error from server (AlreadyExists): error when creating "./operator.yml":
    rolebindings.rbac.authorization.k8s.io "system:image-pullers" already exists

    1
    Sie können die Meldung Error from server (AlreadyExists) ignorieren. Sie werden durch den Migration Toolkit for Containers Operator verursacht, der Ressourcen für frühere Versionen von OpenShift Container Platform 3 erstellt, die in späteren Versionen bereitgestellt werden.
  8. Erstellen Sie das Objekt MigrationController:

    $ oc create -f controller.yml
  9. Überprüfen Sie, ob die MTC-Pods ausgeführt werden:

    $ oc get pods -n openshift-migration

7.4. Konfigurieren von Proxys

Für OpenShift Container Platform 4.1 und frühere Versionen müssen Sie, nachdem Sie den Migration Toolkit for Containers Operator installiert haben, Proxys im Manifest der Custom Resource (CR) MigrationController konfigurieren, da diese Versionen kein clusterweites Proxy-Objekt unterstützen.

Für OpenShift Container Platform 4.2 bis 4.10 erbt das Migration Toolkit for Containers (MTC) die clusterweiten Proxy-Einstellungen. Sie können die Proxy-Parameter ändern, wenn Sie die clusterweiten Proxy-Einstellungen außer Kraft setzen wollen.

Sie müssen die Proxys so konfigurieren, dass sie das SPDY-Protokoll zulassen und den Header Upgrade HTTP an den API-Server weiterleiten. Andernfalls wird die Fehlermeldung Upgrade request required angezeigt. Die CR MigrationController verwendet SPDY, um Befehle in Remote-Pods auszuführen. Der Header Upgrade HTTP ist erforderlich, um eine Websocket-Verbindung mit dem API-Server zu öffnen.

Direct Volume Migration

Wenn Sie eine Direct Volume Migration (DVM) von einem Quell-Cluster hinter einem Proxy durchführen, müssen Sie einen Stunnel-Proxy konfigurieren. Stunnel erstellt einen transparenten Tunnel zwischen dem Quell- und dem Ziel-Cluster für die TCP-Verbindung, ohne die Zertifikate zu ändern.

Die DVM unterstützt nur einen Proxy. Der Quell-Cluster kann nicht auf die Route des Ziel-Clusters zugreifen, wenn sich der Ziel-Cluster ebenfalls hinter einem Proxy befindet.

Voraussetzungen

  • Sie müssen auf allen Clustern als Benutzer mit cluster-admin-Privilegien angemeldet sein.

Vorgehensweise

  1. Rufen Sie das CR-Manifest MigrationController ab:

    $ oc get migrationcontroller <migration_controller> -n openshift-migration
  2. Aktualisieren Sie die Proxy-Parameter:

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigrationController
    metadata:
      name: <migration_controller>
      namespace: openshift-migration
    ...
    spec:
      stunnel_tcp_proxy: http://<username>:<password>@<ip>:<port> 1
      httpProxy: http://<username>:<password>@<ip>:<port> 2
      httpsProxy: http://<username>:<password>@<ip>:<port> 3
      noProxy: example.com 4
    1
    Stunnel-Proxy-URL für die Direct Volume Migration.
    2
    Proxy-URL für die Erstellung von HTTP-Verbindungen außerhalb des Clusters. Das URL-Schema muss http sein.
    3
    Proxy-URL für die Erstellung von HTTPS-Verbindungen außerhalb des Clusters. Wenn dies nicht angegeben wird, wird httpProxy sowohl für HTTP- als auch für HTTPS-Verbindungen verwendet.
    4
    Durch Kommata getrennte Liste von Zieldomain-Namen, Domains, IP-Adressen oder anderen Netzwerk-CIDRs zum Ausschluss von Proxying.

    Stellen Sie einer Domain ein . voran, um nur Subdomains zu finden. Zum Beispiel gibt es bei .y.com eine Übereinstimmung mit x.y.com, aber nicht mit y.com. Verwenden Sie *, um den Proxy für alle Ziele zu umgehen. Wenn Sie Worker hochskalieren, die nicht in dem durch das Installationskonfigurationsfeld networking.machineNetwork[].cidr definierten Netzwerk enthalten sind, müssen Sie sie zu dieser Liste hinzufügen, um Verbindungsprobleme zu vermeiden.

    Dieses Feld wird ignoriert, wenn weder das Feld httpProxy noch das Feld httpsProxy konfiguriert ist.

  3. Speichern Sie das Manifest als migration-controller.yaml.
  4. Wenden Sie das aktualisierte Manifest an:

    $ oc replace -f migration-controller.yaml -n openshift-migration

Weitere Informationen finden Sie unter Konfigurieren des clusterweiten Proxys.

7.5. Konfigurieren eines Replikations-Repositorys

Das Multicloud Object Gateway ist die einzige unterstützte Option für eine eingeschränkte Netzwerkumgebung.

MTC unterstützt die Dateisystem- und Schnappschuss-Datenkopiermethoden für die Migration von Daten aus dem Quell-Cluster in den Ziel-Cluster. Sie können eine Methode wählen, die für Ihre Umgebung geeignet ist und von Ihrem Speicheranbieter unterstützt wird.

7.5.1. Voraussetzungen

  • Alle Cluster müssen ununterbrochenen Netzwerkzugriff zum Replikations-Repository haben.
  • Wenn Sie einen Proxy-Server mit einem intern gehosteten Replikations-Repository verwenden, müssen Sie sicherstellen, dass der Proxy den Zugriff auf das Replikations-Repository erlaubt.

7.5.2. Abrufen von Anmeldedaten für Multicloud Object Gateway

Sie müssen die Anmeldedaten für Multicloud Object Gateway (MCG) abrufen, um eine Secret Custom Resource (CR) für die OpenShift API for Data Protection (OADP) zu erstellen.

MCG ist eine Komponente von OpenShift Container Storage.

Voraussetzungen

Vorgehensweise

  1. Ermitteln Sie den S3-Endpunkt, die AWS_ACCESS_KEY_ID und den AWS_SECRET_ACCESS_KEY, indem Sie den Befehl describe für die benutzerdefinierte NooBaa-Ressource ausführen.

7.5.3. Zusätzliche Ressourcen

7.6. Deinstallation des MTC und Löschen von Ressourcen

Sie können das Migration Toolkit for Containers (MTC) deinstallieren und seine Ressourcen löschen, um den Cluster zu bereinigen.

Anmerkung

Durch das Löschen der velero-CRDs wird Velero aus dem Cluster entfernt.

Voraussetzungen

  • Sie müssen als Benutzer mit cluster-admin-Privilegien angemeldet sein.

Vorgehensweise

  1. Löschen Sie die benutzerdefinierte Ressource (CR) MigrationController auf allen Clustern:

    $ oc delete migrationcontroller <migration_controller>
  2. Deinstallieren Sie den Migration Toolkit for Containers Operator auf OpenShift Container Platform 4 mit Hilfe des Operator Lifecycle Managers.
  3. Löschen Sie mit den folgenden Befehlen die Cluster-abhängigen Ressourcen auf allen Clustern:

    • Benutzerdefinierte migration-Ressourcendefinitionen (CRDs):

      $ oc delete $(oc get crds -o name | grep 'migration.openshift.io')
    • velero-CRDs:

      $ oc delete $(oc get crds -o name | grep 'velero')
    • migrationscluster-Rollen:

      $ oc delete $(oc get clusterroles -o name | grep 'migration.openshift.io')
    • migration-operator-Cluster-Rolle:

      $ oc delete clusterrole migration-operator
    • velero-Cluster-Rollen:

      $ oc delete $(oc get clusterroles -o name | grep 'velero')
    • migration-Cluster-Rollenbindungen:

      $ oc delete $(oc get clusterrolebindings -o name | grep 'migration.openshift.io')
    • migration-operator-Cluster-Rollenbindungen:

      $ oc delete clusterrolebindings migration-operator
    • velero-Cluster-Rollenbindungen:

      $ oc delete $(oc get clusterrolebindings -o name | grep 'velero')

Kapitel 8. Upgrade des Migration Toolkit for Containers

Sie können das Migration Toolkit for Containers (MTC) auf der OpenShift Container Platform 4.10 mithilfe des Operator Lifecycle Manager aktualisieren.

Sie können MTC auf OpenShift Container Platform 3 aktualisieren, indem Sie den Legacy Migration Toolkit for Containers Operator neu installieren.

Wichtig

Wenn Sie von MTC Version 1.3 aktualisieren, müssen Sie zusätzliche Schritte durchführen, um die benutzerdefinierte MigPlan-Ressource (CR) zu aktualisieren.

8.1. Upgrade des Migration Toolkit for Containers auf OpenShift Container Platform 4.10

Sie können das Migration Toolkit for Containers (MTC) auf OpenShift Container Platform 4.10 mithilfe des Operator Lifecycle Manager aktualisieren.

Voraussetzungen

  • Sie müssen als Benutzer mit cluster-admin-Privilegien angemeldet sein.

Vorgehensweise

  1. Navigieren Sie in der Konsole der OpenShift Container Platform zu OperatorsInstalled Operators.

    Operatoren, bei denen ein Upgrade ansteht, zeigen den Status Upgrade available an.

  2. Klicken Sie auf Migration Toolkit for Containers Operator.
  3. Klicken Sie auf die Registerkarte Subscription. Alle genehmigungspflichtigen Upgrades werden neben Upgrade Status angezeigt. Es könnte zum Beispiel 1 requires approval angezeigt werden.
  4. Klicken Sie auf 1 requires approval und dann auf Preview Install Plan.
  5. Überprüfen Sie die Ressourcen, für die ein Upgrade verfügbar ist, und klicken Sie auf Approve.
  6. Navigieren Sie zurück zur Seite Operators → Installed Operators, um den Fortschritt des Upgrades zu überwachen. Nach Abschluss des Vorgangs ändert sich der Status in Succeeded und Up to date.
  7. Klicken Sie auf Migration Toolkit for Containers Operator.
  8. Suchen Sie unter Provided APIs die Kachel Migration Controller und klicken Sie auf Create Instance.
  9. Klicken Sie auf WorkloadsPods, um zu überprüfen, ob die MTC-Pods ausgeführt werden.

8.2. Upgrade des Migration Toolkit for Containers auf OpenShift Container Platform 3

Sie können Migration Toolkit for Containers (MTC) auf OpenShift Container Platform 3 aktualisieren, indem Sie den Legacy Migration Toolkit for Containers Operator manuell installieren.

Voraussetzungen

  • Sie müssen als Benutzer mit cluster-admin-Privilegien angemeldet sein.
  • Sie müssen Zugriff auf registry.redhat.io haben.
  • Sie müssen podman installiert haben.

Vorgehensweise

  1. Melden Sie sich mit Ihren Anmeldedaten für das Red Hat Customer Portal bei registry.redhat.io an:

    $ sudo podman login registry.redhat.io
  2. Laden Sie die Datei operator.yml herunter:

    $ sudo podman cp $(sudo podman create \
      registry.redhat.io/rhmtc/openshift-migration-legacy-rhel8-operator:v1.5.3):/operator.yml ./
  3. Ersetzen Sie den Migration Toolkit for Container Operator:

    $ oc replace --force -f operator.yml
  4. Skalieren Sie die Bereitstellung von migration-operator auf 0, um die Bereitstellung zu beenden:

    $ oc scale -n openshift-migration --replicas=0 deployment/migration-operator
  5. Skalieren Sie die Bereitstellung migration-operator auf 1, um die Bereitstellung zu starten und die Änderungen anzuwenden:

    $ oc scale -n openshift-migration --replicas=1 deployment/migration-operator
  6. Überprüfen Sie, ob der migration-operator aktualisiert wurde:

    $ oc -o yaml -n openshift-migration get deployment/migration-operator | grep image: | awk -F ":" '{ print $NF }'
  7. Laden Sie die Datei controller.yml herunter:

    $ sudo podman cp $(sudo podman create \
      registry.redhat.io/rhmtc/openshift-migration-legacy-rhel8-operator:v1.5.3):/controller.yml ./
  8. Erstellen Sie das Objekt migration-controller:

    $ oc create -f controller.yml
  9. Wenn Sie den OpenShift Container Platform 3-Cluster zuvor zur MTC-Webkonsole hinzugefügt haben, müssen Sie das Service Account-Token in der Webkonsole aktualisieren, da der Upgrade-Vorgang den Namespace openshift-migration löscht und wiederherstellt:

    1. Rufen Sie das Service Account-Token ab:

      $ oc sa get-token migration-controller -n openshift-migration
    2. Klicken Sie in der MTC-Webkonsole auf Clusters.
    3. Klicken Sie auf das Optionsmenü kebab neben dem Cluster und wählen Sie Edit aus.
    4. Geben Sie das neue Service Account-Token in das Feld Service account token ein.
    5. Klicken Sie auf Update Cluster und dann auf Close.
  10. Überprüfen Sie, ob die MTC-Pods ausgeführt werden:

    $ oc get pods -n openshift-migration

8.3. Upgrade von MTC 1.3 auf 1.6

Wenn Sie Migration Toolkit for Containers (MTC) Version 1.3.x auf 1.6 aktualisieren, müssen Sie das benutzerdefinierte MigPlan-Ressourcenmanifest (CR) auf dem Cluster aktualisieren, auf dem der Pod MigrationController ausgeführt wird.

Da die Parameter indirectImageMigration und indirectVolumeMigration in MTC 1.3 nicht existieren, ist ihr Standardwert in Version 1.4 false, was bedeutet, dass die Direct Image Migration und Direct Volume Migration aktiviert sind. Da die direkten Migrationsvoraussetzungen nicht erfüllt sind, kann der Migrationsplan den Zustand Ready nur erreichen, wenn diese Parameterwerte zu true geändert werden.

Voraussetzungen

  • Sie müssen als Benutzer mit cluster-admin-Privilegien angemeldet sein.

Vorgehensweise

  1. Melden Sie sich bei dem Cluster an, in dem der Pod MigrationController ausgeführt wird.
  2. Rufen Sie das CR-Manifest MigPlan ab:

    $ oc get migplan <migplan> -o yaml -n openshift-migration
  3. Aktualisieren Sie die folgenden Parameterwerte und speichern Sie die Datei als migplan.yaml:

    ...
    spec:
      indirectImageMigration: true
      indirectVolumeMigration: true
  4. Ersetzen Sie das CR-Manifest MigPlan, um die Änderungen zu anzuwenden:

    $ oc replace -f migplan.yaml -n openshift-migration
  5. Rufen Sie das aktualisierte CR-Manifest MigPlan ab, um die Änderungen zu überprüfen:

    $ oc get migplan <migplan> -o yaml -n openshift-migration

Kapitel 9. Checklisten zur Migrationsvorbereitung

Bevor Sie Ihre Anwendungs-Workloads mit dem Migration Toolkit for Containers (MTC) migrieren, sollten Sie die folgenden Checklisten überprüfen.

9.1. Ressourcen

  • ❏ Wenn Ihre Anwendung ein internes Dienstnetzwerk oder eine externe Route für die Kommunikation mit Diensten verwendet, ist die entsprechende Route vorhanden.
  • ❏ Wenn Ihre Anwendung Ressourcen auf Cluster-Ebene verwendet, haben Sie diese auf dem Ziel-Cluster neu erstellt.
  • ❏ Sie haben Persistent Volumes (PVs), Image Streams und andere Ressourcen, die nicht migriert werden sollen, ausgeschlossen.
  • ❏ Die PV-Daten wurden für den Fall gesichert, dass eine Anwendung nach der Migration ein unerwartetes Verhalten zeigt und die Daten beschädigt.

9.2. Quellen-Cluster

  • ❏ Der Cluster erfüllt die Mindestanforderungen an die Hardware.
  • ❏ Sie haben die richtige Version des Legacy Migration Toolkit for Containers Operator installiert:

    • operator-3.7.yml auf OpenShift Container Platform Version 3.7.
    • operator.yml auf OpenShift Container Platform Versionen 3.9 bis 4.5.
  • ❏ Die MTC-Version ist auf allen Clustern dieselbe.
  • ❏ Alle Knoten haben eine aktive Subskription für OpenShift Container Platform.
  • ❏ Sie haben alle einmalig auszuführenden Aufgaben durchgeführt.
  • ❏ Sie haben alle Zustandsprüfungen für die Umgebungen durchgeführt.
  • ❏ Sie haben mit folgendem Befehl geprüft, ob PVs mit abnormalen Konfigurationen vorhanden sind, die im Zustand Terminating feststecken:

    $ oc get pv
  • ❏ Sie haben mit folgendem Befehl nach Pods gesucht, deren Status nicht Running oder Completed ist:

    $ oc get pods --all-namespaces | egrep -v 'Running | Completed'
  • ❏ Sie haben mit folgendem Befehl nach Pods mit einer hohen Anzahl von Neustarts gesucht:

    $ oc get pods --all-namespaces --field-selector=status.phase=Running \
      -o json | jq '.items[]|select(any( .status.containerStatuses[]; \
      .restartCount > 3))|.metadata.name'

    Auch wenn die Pods den Zustand Running haben, kann eine hohe Anzahl von Neustarts auf zugrunde liegende Probleme hinweisen.

  • ❏ Sie haben alte Builds, Bereitstellungen und Images aus jedem zu migrierenden Namespace durch Pruning entfernt.
  • ❏ Die interne Registrierung verwendet einen unterstützten Storage-Typ.
  • ❏ Nur für die Direct Image Migration: Die interne Registrierung wurde dem externen Netzwerkverkehr zur Verfügung gestellt.
  • ❏ Sie können Images in der Registrierung lesen und schreiben.
  • ❏ Der etcd-Cluster befindet sich in einem ordnungsgemäßen Zustand.
  • ❏ Die durchschnittliche Antwortzeit des API-Servers auf dem Quell-Cluster beträgt weniger als 50 ms.
  • ❏ Die Cluster-Zertifikate sind für die Dauer des Migrationsprozesses gültig.
  • ❏ Sie haben mit folgendem Befehl überprüft, ob es ausstehende Signierungsanfragen für Zertifikate gibt:

    $ oc get csr -A | grep pending -i
  • ❏ Der Identitätsanbieter funktioniert.

9.3. Ziel-Cluster

  • ❏ Sie haben Migration Toolkit for Containers Operator Version 1.5.1 installiert.
  • ❏ Alle MTC-Voraussetzungen sind erfüllt.
  • ❏ Der Cluster erfüllt die Mindestanforderungen an die Hardware für die jeweilige Plattform und Installationsmethode, z. B. auf Bare Metal.
  • ❏ Der Cluster verfügt über Speicherklassen, die für die vom Quell-Cluster verwendeten Speichertypen definiert sind, z. B. Block-Volume, Dateisystem oder Objektspeicher.

    Anmerkung

    Für NFS ist keine definierte Speicherklasse erforderlich.

  • ❏ Der Cluster verfügt über die richtige Netzwerkkonfiguration und die richtigen Berechtigungen für den Zugriff auf externe Dienste, z. B. Datenbanken, Quellcode-Repositorys, Container-Image-Registrierungen und CI/CD-Tools.
  • ❏ Externe Anwendungen und Dienste, die vom Cluster bereitgestellte Dienste nutzen, verfügen über die richtige Netzwerkkonfiguration und die richtigen Zugriffsberechtigungen für den Cluster.
  • ❏ Interne Container-Image-Abhängigkeiten werden erfüllt.

    Wenn eine Anwendung ein internes Image im openshift-Namespace verwendet, das von OpenShift Container Platform 4.10 nicht unterstützt wird, können Sie das OpenShift Container Platform 3 Image-Stream-Tag manuell mit podman aktualisieren.

  • ❏ Der Ziel-Cluster und das Replikations-Repository verfügen über ausreichend Speicherplatz.
  • ❏ Der Identitätsanbieter funktioniert.
  • ❏ DNS-Einträge für Ihre Anwendung sind auf dem Ziel-Cluster vorhanden.
  • ❏ Legen Sie den Wert des Parameters annotation.openshift.io/host.generated für jede OpenShift Container Platform-Route auf true fest, um ihren Hostnamen für den Ziel-Cluster zu aktualisieren. Andernfalls behalten die migrierten Routen den Hostnamen des Quell-Clusters bei.
  • ❏ Die Zertifikate, die Ihre Anwendung verwendet, sind auf dem Ziel-Cluster vorhanden.
  • ❏ Sie haben passende Firewall-Regeln auf dem Ziel-Cluster konfiguriert.
  • ❏ Sie haben den Lastenverteiler auf dem Ziel-Cluster korrekt konfiguriert.
  • ❏ Wenn Sie Objekte in einen bestehenden Namespace auf dem Ziel-Cluster migrieren, der denselben Namen wie der Namespace hat, der von der Quelle migriert wird, enthält der Ziel-Namespace keine Objekte mit demselben Namen und Typ wie die zu migrierenden Objekte.

    Anmerkung

    Erstellen Sie vor der Migration keine Namespaces für Ihre Anwendung auf dem Ziel-Cluster, da dies zu einer Änderung der Quoten führen kann.

9.4. Leistung

  • ❏ Das Migrationsnetzwerk hat einen Mindestdurchsatz von 10 Gbit/s.
  • ❏ Die Cluster verfügen über ausreichende Ressourcen für die Migration.

    Anmerkung

    Cluster benötigen zusätzlichen Arbeitsspeicher, CPUs und Speicher, um eine Migration zusätzlich zu den normalen Workloads durchzuführen. Der tatsächliche Ressourcenbedarf hängt von der Anzahl der Kubernetes-Ressourcen ab, die in einem einzelnen Migrationsplan migriert werden. Sie müssen Migrationen in einer nicht produktiven Umgebung testen, um den Ressourcenbedarf abschätzen zu können.

  • ❏ Die Arbeitsspeicher- und CPU-Auslastung der Knoten ist auf einem angemessenen Niveau.
  • ❏ Die etcd-Festplattenleistung der Cluster wurde mit fio überprüft.

Kapitel 10. Migrieren Ihrer Anwendungen

Sie können Ihre Anwendungen über die Webkonsole des Migration Toolkit for Containers (MTC) oder über die Befehlszeile migrieren.

Sie können die Stage-Migration und Cutover-Migration verwenden, um eine Anwendung zwischen Clustern zu migrieren:

  • Bei der Stage-Migration werden Daten vom Quell-Cluster auf den Ziel-Cluster kopiert, ohne dass die Anwendung angehalten wird. Sie können eine Stage-Migration mehrmals durchführen, um die Dauer der Cutover-Migration zu verkürzen.
  • Bei der Cutover-Migration werden die Transaktionen auf dem Quell-Cluster gestoppt und die Ressourcen auf den Ziel-Cluster verschoben.

Sie können die State-Migration verwenden, um den Zustand einer Anwendung zu migrieren:

  • Bei der State-Migration werden ausgewählte Persistent Volume Claims (PVCs) und Kubernetes-Ressourcen kopiert.
  • Sie können die State-Migration verwenden, um einen Namespace innerhalb desselben Clusters zu migrieren.

Die meisten Cluster-Ressourcen werden noch nicht von MTC gehandhabt. Wenn Ihre Anwendungen Cluster-Ressourcen benötigen, müssen Sie diese möglicherweise manuell auf dem Ziel-Cluster erstellen.

Während der Migration behält MTC die folgenden Namespace-Annotationen bei:

  • openshift.io/sa.scc.mcs
  • openshift.io/sa.scc.supplemental-groups
  • openshift.io/sa.scc.uid-range

Diese Annotationen bewahren den UID-Bereich und stellen sicher, dass die Container ihre Dateisystemberechtigungen auf dem Ziel-Cluster beibehalten. Es besteht das Risiko, dass die migrierten UIDs sich in einem bestehenden oder zukünftigen Namespace auf dem Ziel-Cluster duplizieren.

10.1. Voraussetzungen für die Migration

  • Sie müssen auf allen Clustern als Benutzer mit cluster-admin-Privilegien angemeldet sein.

Direct Image Migration

  • Sie müssen sicherstellen, dass die sichere interne Registrierung des Quell-Clusters verfügbar gemacht wird.
  • Sie müssen eine Route zur verfügbaren Registrierung erstellen.

Direct Volume Migration

  • Wenn Ihre Cluster Proxys verwenden, müssen Sie einen Stunnel-TCP-Proxy konfigurieren.

Interne Images

  • Wenn Ihre Anwendung interne Images aus dem openshift-Namespace verwendet, müssen Sie sicherstellen, dass die erforderlichen Versionen der Images auf dem Ziel-Cluster vorhanden sind.

    Sie können ein Image-Stream-Tag manuell aktualisieren, um ein veraltetes OpenShift Container Platform 3-Image auf einem OpenShift Container Platform 4.10-Cluster zu verwenden.

Cluster

  • Der Quell-Cluster muss auf die neueste MTC-Version von z-stream aktualisiert werden.
  • Die MTC-Version muss auf allen Clustern dieselbe sein.

Netzwerk

  • Die Cluster haben uneingeschränkten Netzwerkzugriff zueinander und zum Replikations-Repository.
  • Wenn Sie die Persistent Volumes mit move kopieren, müssen die Cluster uneingeschränkten Netzwerkzugriff auf die Remote-Volumes haben.
  • Sie müssen die folgenden Ports auf einem OpenShift Container Platform 3-Cluster aktivieren:

    • 8443 (API-Server)
    • 443 (Routen)
    • 53 (DNS)
  • Sie müssen die folgenden Ports auf einem OpenShift Container Platform 4-Cluster aktivieren:

    • 6443 (API-Server)
    • 443 (Routen)
    • 53 (DNS)
  • Sie müssen Port 443 auf dem Replikations-Repository aktivieren, wenn Sie TLS verwenden.

Persistent Volumes (PVs)

  • Die PVs müssen gültig sein.
  • Die PVs müssen an Persistent Volume Claims gebunden sein.
  • Wenn Sie Schnappschüsse zum Kopieren der PVs verwenden, gelten die folgenden zusätzlichen Voraussetzungen:

    • Der Cloud-Anbieter muss Schnappschüsse unterstützen.
    • Die PVs müssen denselben Cloud-Anbieter haben.
    • Die PVs müssen sich in derselben geografischen Region befinden.
    • Die PVs müssen dieselbe Speicherklasse haben.

Zusätzliche Ressourcen zu Migrationsvoraussetzungen

10.2. Migration Ihrer Anwendungen mit Hilfe der MTC-Webkonsole

Sie können Cluster und ein Replikations-Repository über die MTC-Webkonsole konfigurieren. Dann können Sie einen Migrationsplan erstellen und ausführen.

10.2.1. Starten der MTC-Webkonsole

Sie können die MTC-Webkonsole (Migration Toolkit for Containers) in einem Browser starten.

Voraussetzungen

  • Die MTC-Webkonsole muss über Netzwerkzugriff auf die Webkonsole der OpenShift Container Platform verfügen.
  • Die MTC-Webkonsole muss über Netzwerkzugriff auf den OAuth-Autorisierungsserver verfügen.

Vorgehensweise

  1. Melden Sie sich bei dem OpenShift Container Platform-Cluster an, auf dem Sie MTC installiert haben.
  2. Rufen Sie die URL der MTC-Webkonsole durch Eingabe des folgenden Befehls auf:

    $ oc get -n openshift-migration route/migration -o go-template='https://{{ .spec.host }}'

    Die Ausgabe sieht folgendermaßen aus: https://migration-openshift-migration.apps.cluster.openshift.com.

  3. Starten Sie einen Browser und navigieren Sie zur MTC-Webkonsole.

    Anmerkung

    Wenn Sie versuchen, unmittelbar nach der Installation des Migration Toolkit for Containers Operator auf die MTC-Webkonsole zuzugreifen, kann es sein, dass die Konsole nicht geladen wird, weil der Operator noch mit der Konfiguration des Clusters beschäftigt ist. Warten Sie ein paar Minuten und versuchen Sie es erneut.

  4. Wenn Sie selbstsignierte CA-Zertifikate verwenden, werden Sie aufgefordert, das CA-Zertifikat vom API-Server des Quell-Clusters zu akzeptieren. Die Webseite führt Sie durch den Annahmevorgang der restlichen Zertifikate.
  5. Melden Sie sich mit Ihrem OpenShift Container Platform-Benutzernamen und -Passwort an.

10.2.2. Hinzufügen eines Clusters zur MTC-Webkonsole

Sie können einen Cluster zur Webkonsole des Migration Toolkit for Containers (MTC) hinzufügen.

Voraussetzungen

  • Wenn Sie Azure Schnappschüsse zum Kopieren von Daten verwenden:

    • Müssen Sie den Namen der Azure-Ressourcengruppe für den Cluster angeben.
    • Müssen die Cluster sich in derselben Azure-Ressourcengruppe befinden.
    • Müssen die Cluster sich am selben geografischen Ort befinden.
  • Wenn Sie die Direct Image Migration verwenden, müssen Sie eine Route zur

Vorgehensweise

  1. Melden Sie sich beim Cluster an.
  2. Rufen Sie das Service Account-Token migration-controller ab:

    $ oc sa get-token migration-controller -n openshift-migration

    Beispielausgabe

    eyJhbGciOiJSUzI1NiIsImtpZCI6IiJ9.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJtaWciLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlY3JldC5uYW1lIjoibWlnLXRva2VuLWs4dDJyIiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZXJ2aWNlLWFjY291bnQubmFtZSI6Im1pZyIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6ImE1YjFiYWMwLWMxYmYtMTFlOS05Y2NiLTAyOWRmODYwYjMwOCIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDptaWc6bWlnIn0.xqeeAINK7UXpdRqAtOj70qhBJPeMwmgLomV9iFxr5RoqUgKchZRG2J2rkqmPm6vr7K-cm7ibD1IBpdQJCcVDuoHYsFgV4mp9vgOfn9osSDp2TGikwNz4Az95e81xnjVUmzh-NjDsEpw71DH92iHV_xt2sTwtzftS49LpPW2LjrV0evtNBP_t_RfskdArt5VSv25eORl7zScqfe1CiMkcVbf2UqACQjo3LbkpfN26HAioO2oH0ECPiRzT0Xyh-KwFutJLS9Xgghyw-LD9kPKcE_xbbJ9Y4Rqajh7WdPYuB0Jd9DPVrslmzK-F6cgHHYoZEv0SvLQi-PO0rpDrcjOEQQ

  3. Klicken Sie in der MTC-Webkonsole auf Clusters.
  4. Klicken Sie auf Add Cluster.
  5. Füllen Sie die folgenden Felder aus:

    • Cluster name: Der Clustername kann Kleinbuchstaben (a-z) und Zahlen (0-9) enthalten. Er darf keine Leerzeichen oder internationalen Zeichen enthalten.
    • URL: Geben Sie die URL des API-Servers an, z. B. https://<www.example.com>:8443.
    • Service account token: Fügen Sie das Service Account-Token migration-controller ein.
    • Exposed route host to image registry: Wenn Sie die Direct Image Migration verwenden, geben Sie die verfügbare Route zur Image-Registrierung des Quell-Clusters an.

      Um die Route zu erstellen, führen Sie den folgenden Befehl aus:

      • Für OpenShift Container Platform 3:

        $ oc create route passthrough --service=docker-registry --port=5000 -n default
      • Für OpenShift Container Platform 4:

        $ oc create route passthrough --service=image-registry --port=5000 -n openshift-image-registry
    • Azure cluster: Sie müssen diese Option auswählen, wenn Sie Azure-Schnappschüsse zum Kopieren Ihrer Daten verwenden.
    • Azure resource group: Dieses Feld wird angezeigt, wenn Azure cluster ausgewählt ist. Geben Sie die Azure-Ressourcengruppe an.
    • Require SSL verification: Optional: Wählen Sie diese Option, um SSL-Verbindungen zum Cluster zu verifizieren.
    • CA bundle file: Dieses Feld wird angezeigt, wenn die Option Require SSL verification erforderlich ausgewählt ist. Wenn Sie eine benutzerdefinierte Datei mit CA-Zertifikatpaket für selbstsignierte Zertifikate erstellt haben, klicken Sie auf Browse, wählen Sie die CA-Paketdatei aus und laden Sie sie hoch.
  6. Klicken Sie auf Add Cluster.

    Der Cluster wird in der Liste Clusters angezeigt.

10.2.3. Hinzufügen eines Replikations-Repositorys zur MTC-Webkonsole

Sie können einen Objektspeicher als Replikations-Repository zur MTC-Webkonsole (Migration Toolkit for Containers) hinzufügen.

MTC unterstützt die folgenden Speicheranbieter:

  • Amazon Web Services (AWS) S3
  • Multi-Cloud Object Gateway (MCG)
  • Generischer S3-Objektspeicher, z. B. Minio oder Ceph S3
  • Google Cloud Provider (GCP)
  • Microsoft Azure Blob

Voraussetzungen

  • Sie müssen den Objektspeicher als Replikations-Repository konfigurieren.

Vorgehensweise

  1. Klicken Sie in der MTC-Webkonsole auf Replication repositories.
  2. Klicken Sie auf Add repository.
  3. Wählen Sie einen Storage provider type und füllen Sie die folgenden Felder aus:

    • AWS für S3-Anbieter, einschließlich AWS und MCG:

      • Replication repository name: Geben Sie den Namen des Replikations-Repositorys in der MTC-Webkonsole an.
      • S3 bucket name: Geben Sie den Namen des S3-Buckets an.
      • S3 bucket region: Geben Sie die Region des S3-Buckets an. Erforderlich für AWS S3. Optional für einige S3-Anbieter. Informieren Sie sich in der Produktdokumentation Ihres S3-Anbieters über die erwarteten Werte.
      • S3 endpoint: Geben Sie die URL des S3-Dienstes an, nicht den Bucket, zum Beispiel https://<s3-storage.apps.cluster.com>. Erforderlich für einen generischen S3-Anbieter. Sie müssen das Präfix https:// verwenden.
      • S3 provider access key: Geben Sie den <AWS_SECRET_ACCESS_KEY> für AWS oder den S3-Anbieter-Zugangsschlüssel für MCG und andere S3-Anbieter an.
      • S3 provider secret access key: Geben Sie die <AWS_ACCESS_KEY_ID> für AWS oder den geheimen S3-Anbieter-Zugangsschlüssel für MCG und andere S3-Anbieter an.
      • Require SSL verification: Deaktivieren Sie dieses Kontrollkästchen, wenn Sie einen generischen S3-Anbieter verwenden.
      • Wenn Sie ein benutzerdefiniertes CA-Zertifikatpaket für selbstsignierte Zertifikate erstellt haben, klicken Sie auf Browse und suchen Sie nach der base64-kodierten Datei.
    • GCP:

      • Replication repository name: Geben Sie den Namen des Replikations-Repositorys in der MTC-Webkonsole an.
      • GCP bucket name: Geben Sie den Namen des GCP-Buckets an.
      • GCP credential JSON blob: Geben Sie die Zeichenfolge in der Datei credentials-velero an.
    • Azure:

      • Replication repository name: Geben Sie den Namen des Replikations-Repositorys in der MTC-Webkonsole an.
      • Azure resource group: Geben Sie die Ressourcengruppe des Azure Blob-Speichers an.
      • Azure storage account name: Geben Sie den Namen des Azure Blob-Speicherkontos an.
      • Azure credentials - INI file contents: Geben Sie die Zeichenfolge in der Datei credentials-velero an.
  4. Klicken Sie auf Add repository und warten Sie auf die Validierung der Verbindung.
  5. Klicken Sie auf Close.

    Das neue Repository wird in der Liste Replication repositories angezeigt.

10.2.4. Erstellen eines Migrationsplans in der MTC-Webkonsole

Sie können einen Migrationsplan in der MTC-Webkonsole (Migration Toolkit for Containers) erstellen.

Voraussetzungen

  • Sie müssen auf allen Clustern als Benutzer mit cluster-admin-Privilegien angemeldet sein.
  • Sie müssen sicherstellen, dass auf allen Clustern dieselbe MTC-Version installiert ist.
  • Sie müssen die Cluster und das Replikations-Repository zur MTC-Webkonsole hinzufügen.
  • Wenn Sie ein Persistent Volume (PV) mit der Datenkopie-Methode move migrieren möchten, müssen Quell- und Ziel-Cluster ununterbrochenen Netzwerkzugriff auf das Remote-Volume haben.
  • Wenn Sie die Direct Image Migration verwenden möchten, müssen Sie die verfügbare Route zur Image-Registrierung des Quell-Clusters angeben. Dies kann über die MTC-Webkonsole oder durch Aktualisierung des benutzerdefinierten Ressourcenmanifests MigCluster erfolgen.

Vorgehensweise

  1. Klicken Sie in der MTC-Webkonsole auf Migration plans.
  2. Klicken Sie auf Add migration plan.
  3. Geben Sie bei Plan name einen Namen ein.

    Der Name des Migrationsplans darf nicht mehr als 253 klein geschriebene alphanumerische Zeichen(a-z, 0-9) und keine Leerzeichen oder Unterstriche(_) enthalten.

  4. Wählen Sie einen Source cluster, einen Target cluster und ein Repository aus.
  5. Klicken Sie auf Next.
  6. Wählen Sie die zu migrierenden Projekte aus.
  7. Optional: Klicken Sie auf das Bearbeitungssymbol neben einem Projekt, um den Ziel-Namespace zu ändern.
  8. Klicken Sie auf Next.
  9. Wählen Sie einen Migration type für jedes PV:

    • Mit der Option Copy werden die Daten aus der PV eines Quell-Clusters in das Replikations-Repository kopiert und anschließend in einem neu erstellten PV mit ähnlichen Merkmalen im Ziel-Cluster wiederhergestellt.
    • Mit der Option Move wird die Bereitstellung eines Remote-Volume, z. B. NFS, auf dem Quell-Cluster aufgehoben, eine PV-Ressource auf dem Ziel-Cluster erstellt, die auf das Remote-Volume verweist, und dann das Remote-Volume auf dem Ziel-Cluster bereitgestellt. Anwendungen, die auf dem Ziel-Cluster ausgeführt werden, verwenden dasselbe Remote-Volume, das auch der Quell-Cluster verwendet hat.
  10. Klicken Sie auf Next.
  11. Wählen Sie eine Copy method für jedes PV:

    • Snapshot copy sichert und stellt Daten mithilfe der Schnappschuss-Funktionalität des Cloud-Anbieters wieder her. Dies ist wesentlich schneller als Filesystem copy.
    • Filesystem copy sichert die Dateien auf dem Quell-Cluster und stellt sie auf dem Ziel-Cluster wieder her.

      Die Methode der Dateisystemkopie ist für die Direct Volume Migration erforderlich.

  12. Sie können die Option Verify copy wählen, um die mit Filesystem copy migrierten Daten zu verifizieren. Die Daten werden verifiziert, indem für jede Quelldatei eine Prüfsumme generiert und diese nach der Wiederherstellung überprüft wird. Die Datenverifizierung verringert die Leistung erheblich.
  13. Wählen Sie eine Target storage class aus.

    Wenn Sie Filesystem copy gewählt haben, können Sie die Ziel-Speicherklasse ändern.

  14. Klicken Sie auf Next.
  15. Auf der Seite Migration options ist die Option Direct image migration ausgewählt, wenn Sie eine verfügbar Image-Registrierungsroute für den Quell-Cluster angegeben haben. Die Option Direct PV migration wird ausgewählt, wenn Sie die Daten mit Filesystem copy migrieren.

    Die direkten Migrationsoptionen kopieren Images und Dateien direkt vom Quell-Cluster auf den Ziel-Cluster. Diese Option ist wesentlich schneller als das Kopieren von Images und Dateien vom Quell-Cluster in das Replikations-Repository und anschließend vom Replikations-Repository in den Ziel-Cluster.

  16. Klicken Sie auf Next.
  17. Optional: Klicken Sie auf Add Hook, um dem Migrationsplan einen Hook hinzuzufügen.

    Ein Hook führt benutzerdefinierten Code aus. Sie können bis zu vier Hooks zu einem einzigen Migrationsplan hinzufügen. Jeder Hook wird während eines anderen Migrationsschritts ausgeführt.

    1. Geben Sie den Namen des Hooks ein, der in der Webkonsole angezeigt werden soll.
    2. Wenn es sich bei dem Hook um ein Ansible-Playbook handelt, wählen Sie Ansible playbook und klicken Sie auf Browse, um das Playbook hochzuladen, oder fügen Sie den Inhalt des Playbooks in das Feld ein.
    3. Optional: Geben Sie ein Ansible-Laufzeit-Image an, wenn Sie nicht das Standard-Hook-Image verwenden.
    4. Wenn es sich bei dem Hook nicht um ein Ansible-Playbook handelt, wählen Sie Custom container image und geben Sie den Namen und den Pfad des Images an.

      Ein benutzerdefiniertes Container-Image kann Ansible-Playbooks enthalten.

    5. Wählen Sie Source cluster oder Target cluster.
    6. Geben Sie bei Service account name und Service account namespace Werte ein.
    7. Wählen Sie den Migrationsschritt für den Hook:

      • preBackup: Bevor die Anwendungs-Workload auf dem Quell-Cluster gesichert wird
      • postBackup: Nachdem die Anwendungs-Workload auf dem Quell-Cluster gesichert wurde
      • preRestore: Bevor die Anwendungs-Workload auf dem Ziel-Cluster wiederhergestellt wird
      • postRestore: Nachdem die Anwendungs-Workload auf dem Ziel-Cluster wiederhergestellt wurde
    8. Klicken Sie auf Add.
  18. Klicken Sie auf Finish.

    Der Migrationsplan wird in der Liste Migration plans angezeigt.

Zusätzliche Ressourcen

10.2.5. Ausführen eines Migrationsplans in der MTC-Webkonsole

Sie können Anwendungen und Daten mit dem Migrationsplan migrieren, den Sie in der MTC-Webkonsole (Migration Toolkit for Containers) erstellt haben.

Anmerkung

Während der Migration legt MTC die Rückforderungsrichtlinie für migrierte Persistent Volumes (PVs) auf dem Ziel-Cluster auf Retain fest.

Die benutzerdefinierte Ressource Backup enthält eine PVOriginalReclaimPolicy-Annotation, die die ursprüngliche Rückforderungsrichtlinie angibt. Sie können die Rückforderungsrichtlinie für die migrierten PVs manuell wiederherstellen.

Voraussetzungen

Die MTC-Webkonsole muss Folgendes enthalten:

  • Quell-Cluster im Zustand Ready
  • Ziel-Cluster im Zustand Ready
  • Replikations-Repository
  • Gültiger Migrationsplan

Vorgehensweise

  1. Melden Sie sich bei der MTC-Webkonsole an und klicken Sie auf Migration plans.
  2. Klicken Sie auf das Optionen-Menü kebab neben einem Migrationsplan und wählen Sie eine der folgenden Optionen unter Migration:

    • Stage kopiert Daten aus dem Quell-Cluster in den Ziel-Cluster, ohne die Anwendung anzuhalten.
    • Cutover stoppt die Transaktionen auf dem Quell-Cluster und verschiebt die Ressourcen in den Ziel-Cluster.

      Optional: Im Dialogfeld Cutover migration können Sie das Kontrollkästchen Stop transactions on the source cluster during migration deaktivieren.

    • State kopiert ausgewählter Persistent Volume Claims (PVCs) und Kubernetes-Ressourcen, die den Status einer Anwendung bilden. Sie können die State-Migration verwenden, um einen Namespace innerhalb desselben Clusters zu migrieren.

      Wichtig

      Verwenden Sie die State-Migration nicht, um einen Namespace zwischen Clustern zu migrieren. Verwenden Sie stattdessen die Stage- oder Cutover-Migration.

      • Wählen Sie im Dialogfeld State migration ein oder mehrere PVCs aus und klicken Sie auf Migrate.
  3. Wenn die Migration abgeschlossen ist, überprüfen Sie in der OpenShift Container Platform-Webkonsole, ob die Anwendung erfolgreich migriert wurde:

    1. Klicken Sie auf HomeProjects.
    2. Klicken Sie auf das migrierte Projekt, um seinen Status anzuzeigen.
    3. Klicken Sie im Bereich Routes auf Location, um zu verifizieren, ob die Anwendung funktioniert (falls zutreffend).
    4. Klicken Sie auf WorkloadsPods, um zu verifizieren, ob die Pods im migrierten Namespace ausgeführt werden.
    5. Klicken Sie auf StoragePersistent Volumes, um zu überprüfen, ob die migrierten persistenten Volumes korrekt bereitgestellt wurden.

Kapitel 11. Erweiterte Migrationsoptionen

Sie können Ihre Migrationen automatisieren und die benutzerdefinierten Ressourcen MigPlan und MigrationController ändern, um umfangreiche Migrationen durchzuführen und die Leistung zu verbessern.

11.1. Terminologie

Tabelle 11.1. MTC-Terminologie

BegriffDefinition

Quellen-Cluster

Cluster, aus dem die Anwendungen migriert werden.

Ziel-Cluster[1]

Cluster, in den die Anwendungen migriert werden.

Replikations-Repository

Objektspeicher zum Kopieren von Images, Volumes und Kubernetes-Objekten bei indirekter Migration oder für Kubernetes-Objekte bei Direct Volume Migration oder Direct Image Migration.

Das Replikations-Repository muss für alle Cluster zugänglich sein.

Host-Cluster

Cluster, auf dem der Pod migration-controller und die Webkonsole ausgeführt werden. Der Host-Cluster ist in der Regel der Ziel-Cluster, dies ist jedoch nicht erforderlich.

Der Host-Cluster benötigt keine zur Verfügung gestellte Registrierungsroute für die Direct Image Migration.

Remote-Cluster

Ein Remote-Cluster ist normalerweise der Quell-Cluster, dies ist jedoch nicht erforderlich.

Für einen Remote-Cluster ist eine benutzerdefinierte Ressource Secret erforderlich, die das Service Account-Token migration-controller enthält.

Ein Remote-Cluster erfordert eine zur Verfügung gestellte sichere Registrierungsroute für die Direct Image Migration.

Indirekte Migration

Images, Volumes und Kubernetes-Objekte werden vom Quell-Cluster in das Replikations-Repository und anschließend vom Replikations-Repository in den Ziel-Cluster kopiert.

Direct Volume Migration

Persistent Volumes werden direkt vom Quell-Cluster auf den Ziel-Cluster kopiert.

Direct Image Migration

Die Bilder werden direkt vom Quell-Cluster auf den Ziel-Cluster kopiert.

Stage-Migration

Die Daten werden auf den Ziel-Cluster kopiert, ohne dass die Anwendung angehalten wird.

Die mehrfache Ausführung einer Stage-Migration verkürzt die Dauer der Cutover-Migration.

Cutover-Migration

Die Anwendung wird auf dem Quell-Cluster gestoppt und ihre Ressourcen werden auf den Ziel-Cluster migriert.

State-Migration

Der Anwendungszustand wird migriert, indem bestimmte Persistent Volume Claims und Kubernetes-Objekte auf den Ziel-Cluster kopiert werden.

Rollback-Migration

Die Rollback-Migration setzt eine abgeschlossene Migration zurück.

1 Rufen Sie den Zielcluster in der MTC-Webkonsole auf.

11.2. Migration von Anwendungen über die Befehlszeile

Sie können Anwendungen mit der MTC-API über die Command Line Interface (CLI) migrieren, um die Migration zu automatisieren.

11.2.1. Voraussetzungen für die Migration

  • Sie müssen auf allen Clustern als Benutzer mit cluster-admin-Privilegien angemeldet sein.

Direct Image Migration

  • Sie müssen sicherstellen, dass die sichere interne Registrierung des Quell-Clusters verfügbar gemacht wird.
  • Sie müssen eine Route zur verfügbaren Registrierung erstellen.

Direct Volume Migration

  • Wenn Ihre Cluster Proxys verwenden, müssen Sie einen Stunnel-TCP-Proxy konfigurieren.

Interne Images

  • Wenn Ihre Anwendung interne Images aus dem openshift-Namespace verwendet, müssen Sie sicherstellen, dass die erforderlichen Versionen der Images auf dem Ziel-Cluster vorhanden sind.

    Sie können ein Image-Stream-Tag manuell aktualisieren, um ein veraltetes OpenShift Container Platform 3-Image auf einem OpenShift Container Platform 4.10-Cluster zu verwenden.

Cluster

  • Der Quell-Cluster muss auf die neueste MTC-Version von z-stream aktualisiert werden.
  • Die MTC-Version muss auf allen Clustern dieselbe sein.

Netzwerk

  • Die Cluster haben uneingeschränkten Netzwerkzugriff zueinander und zum Replikations-Repository.
  • Wenn Sie die Persistent Volumes mit move kopieren, müssen die Cluster uneingeschränkten Netzwerkzugriff auf die Remote-Volumes haben.
  • Sie müssen die folgenden Ports auf einem OpenShift Container Platform 3-Cluster aktivieren:

    • 8443 (API-Server)
    • 443 (Routen)
    • 53 (DNS)
  • Sie müssen die folgenden Ports auf einem OpenShift Container Platform 4-Cluster aktivieren:

    • 6443 (API-Server)
    • 443 (Routen)
    • 53 (DNS)
  • Sie müssen Port 443 auf dem Replikations-Repository aktivieren, wenn Sie TLS verwenden.

Persistent Volumes (PVs)

  • Die PVs müssen gültig sein.
  • Die PVs müssen an Persistent Volume Claims gebunden sein.
  • Wenn Sie Schnappschüsse zum Kopieren der PVs verwenden, gelten die folgenden zusätzlichen Voraussetzungen:

    • Der Cloud-Anbieter muss Schnappschüsse unterstützen.
    • Die PVs müssen denselben Cloud-Anbieter haben.
    • Die PVs müssen sich in derselben geografischen Region befinden.
    • Die PVs müssen dieselbe Speicherklasse haben.

11.2.2. Erstellen einer Registrierungsroute für die Direct Image Migration

Für die Direct Image Migration müssen Sie auf allen Remote-Clustern eine Route zur verfügbaren internen Registrierungen erstellen.

Voraussetzungen

  • Die interne Registrierung muss auf allen Remote-Clustern für den externen Datenverkehr zugänglich sein.

    Die OpenShift Container Platform 4-Registrierung ist standardmäßig verfügbar.

    Die OpenShift Container Platform 3-Registrierung muss manuell verfügbar gemacht werden.

Vorgehensweise

  • Um eine Route zu einer OpenShift Container Platform 3-Registrierung zu erstellen, führen Sie den folgenden Befehl aus:

    $ oc create route passthrough --service=docker-registry -n default
  • Um eine Route zu einer OpenShift Container Platform 4-Registrierung zu erstellen, führen Sie den folgenden Befehl aus:

    $ oc create route passthrough --service=image-registry -n openshift-image-registry

11.2.3. Konfigurieren von Proxys

Für OpenShift Container Platform 4.1 und frühere Versionen müssen Sie, nachdem Sie den Migration Toolkit for Containers Operator installiert haben, Proxys im Manifest der Custom Resource (CR) MigrationController konfigurieren, da diese Versionen kein clusterweites Proxy-Objekt unterstützen.

Für OpenShift Container Platform 4.2 bis 4.10 erbt das Migration Toolkit for Containers (MTC) die clusterweiten Proxy-Einstellungen. Sie können die Proxy-Parameter ändern, wenn Sie die clusterweiten Proxy-Einstellungen außer Kraft setzen wollen.

Sie müssen die Proxys so konfigurieren, dass sie das SPDY-Protokoll zulassen und den Header Upgrade HTTP an den API-Server weiterleiten. Andernfalls wird die Fehlermeldung Upgrade request required angezeigt. Die CR MigrationController verwendet SPDY, um Befehle in Remote-Pods auszuführen. Der Header Upgrade HTTP ist erforderlich, um eine Websocket-Verbindung mit dem API-Server zu öffnen.

Direct Volume Migration

Wenn Sie eine Direct Volume Migration (DVM) von einem Quell-Cluster hinter einem Proxy durchführen, müssen Sie einen Stunnel-Proxy konfigurieren. Stunnel erstellt einen transparenten Tunnel zwischen dem Quell- und dem Ziel-Cluster für die TCP-Verbindung, ohne die Zertifikate zu ändern.

Die DVM unterstützt nur einen Proxy. Der Quell-Cluster kann nicht auf die Route des Ziel-Clusters zugreifen, wenn sich der Ziel-Cluster ebenfalls hinter einem Proxy befindet.

Voraussetzungen

  • Sie müssen auf allen Clustern als Benutzer mit cluster-admin-Privilegien angemeldet sein.

Vorgehensweise

  1. Rufen Sie das CR-Manifest MigrationController ab:

    $ oc get migrationcontroller <migration_controller> -n openshift-migration
  2. Aktualisieren Sie die Proxy-Parameter:

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigrationController
    metadata:
      name: <migration_controller>
      namespace: openshift-migration
    ...
    spec:
      stunnel_tcp_proxy: http://<username>:<password>@<ip>:<port> 1
      httpProxy: http://<username>:<password>@<ip>:<port> 2
      httpsProxy: http://<username>:<password>@<ip>:<port> 3
      noProxy: example.com 4
    1
    Stunnel-Proxy-URL für die Direct Volume Migration.
    2
    Proxy-URL für die Erstellung von HTTP-Verbindungen außerhalb des Clusters. Das URL-Schema muss http sein.
    3
    Proxy-URL für die Erstellung von HTTPS-Verbindungen außerhalb des Clusters. Wenn dies nicht angegeben wird, wird httpProxy sowohl für HTTP- als auch für HTTPS-Verbindungen verwendet.
    4
    Durch Kommata getrennte Liste von Zieldomain-Namen, Domains, IP-Adressen oder anderen Netzwerk-CIDRs zum Ausschluss von Proxying.

    Stellen Sie einer Domain ein . voran, um nur Subdomains zu finden. Zum Beispiel gibt es bei .y.com eine Übereinstimmung mit x.y.com, aber nicht mit y.com. Verwenden Sie *, um den Proxy für alle Ziele zu umgehen. Wenn Sie Worker hochskalieren, die nicht in dem durch das Installationskonfigurationsfeld networking.machineNetwork[].cidr definierten Netzwerk enthalten sind, müssen Sie sie zu dieser Liste hinzufügen, um Verbindungsprobleme zu vermeiden.

    Dieses Feld wird ignoriert, wenn weder das Feld httpProxy noch das Feld httpsProxy konfiguriert ist.

  3. Speichern Sie das Manifest als migration-controller.yaml.
  4. Wenden Sie das aktualisierte Manifest an:

    $ oc replace -f migration-controller.yaml -n openshift-migration

11.2.4. Migration einer Anwendung mit Hilfe der MTC-API

Sie können eine Anwendung über die Befehlszeile migrieren, indem Sie die MTC-API (Migration Toolkit for Containers) verwenden.

Vorgehensweise

  1. Erstellen Sie ein MigCluster-CR-Manifest für den Host-Cluster:

    $ cat << EOF | oc apply -f -
    apiVersion: migration.openshift.io/v1alpha1
    kind: MigCluster
    metadata:
      name: <host_cluster>
      namespace: openshift-migration
    spec:
      isHostCluster: true
    EOF
  2. Erstellen Sie ein Secret-Objektmanifest für jeden Remote-Cluster:

    $ cat << EOF | oc apply -f -
    apiVersion: v1
    kind: Secret
    metadata:
      name: <cluster_secret>
      namespace: openshift-config
    type: Opaque
    data:
      saToken: <sa_token> 1
    EOF
    1
    Geben Sie das base64-kodierte SA-Token (Service Account) migration-controller des Remote-Clusters an. Sie erhalten das Token, indem Sie den folgenden Befehl ausführen:
    $ oc sa get-token migration-controller -n openshift-migration | base64 -w 0
  3. Erstellen Sie für jeden Remote-Cluster ein MigCluster-CR-Manifest:

    $ cat << EOF | oc apply -f -
    apiVersion: migration.openshift.io/v1alpha1
    kind: MigCluster
    metadata:
      name: <remote_cluster> 1
      namespace: openshift-migration
    spec:
      exposedRegistryPath: <exposed_registry_route> 2
      insecure: false 3
      isHostCluster: false
      serviceAccountSecretRef:
        name: <remote_cluster_secret> 4
        namespace: openshift-config
      url: <remote_cluster_url> 5
    EOF
    1
    Geben Sie die CR Cluster des Remote-Clusters an.
    2
    Optional: Geben Sie für die Direct Image Migration die verfügbare Registrierungsroute an.
    3
    Bei false ist die SSL-Verifizierung aktiviert. CA-Zertifikate sind nicht erforderlich und werden nicht überprüft, wenn true.
    4
    Geben Sie das Objekt Secret des Remote-Clusters an.
    5
    Geben Sie die URL des Remote-Clusters an.
  4. Verifizieren Sie, dass sich alle Cluster im Status Ready befinden:

    $ oc describe cluster <cluster>
  5. Erstellen Sie ein Secret-Objektmanifest für das Replikations-Repository:

    $ cat << EOF | oc apply -f -
    apiVersion: v1
    kind: Secret
    metadata:
      namespace: openshift-config
      name: <migstorage_creds>
    type: Opaque
    data:
      aws-access-key-id: <key_id_base64> 1
      aws-secret-access-key: <secret_key_base64> 2
    EOF
    1
    Geben Sie die Schlüssel-ID im base64-Format an.
    2
    Geben Sie den geheimen Schlüssel im base64-Format an.

    AWS-Anmeldedaten sind standardmäßig base64-kodiert. Bei anderen Speicheranbietern müssen Sie Ihre Anmeldedaten verschlüsseln, indem Sie den folgenden Befehl mit jedem Schlüssel ausführen:

    $ echo -n "<key>" | base64 -w 0 1
    1
    Geben Sie die Schlüssel-ID oder den geheimen Schlüssel an. Beide Schlüssel müssen base64-kodiert sein.
  6. Erstellen Sie ein MigStorage-CR-Manifest für das Replikations-Repository:

    $ cat << EOF | oc apply -f -
    apiVersion: migration.openshift.io/v1alpha1
    kind: MigStorage
    metadata:
      name: <migstorage>
      namespace: openshift-migration
    spec:
      backupStorageConfig:
        awsBucketName: <bucket> 1
        credsSecretRef:
          name: <storage_secret> 2
          namespace: openshift-config
      backupStorageProvider: <storage_provider> 3
      volumeSnapshotConfig:
        credsSecretRef:
          name: <storage_secret> 4
          namespace: openshift-config
      volumeSnapshotProvider: <storage_provider> 5
    EOF
    1
    Geben Sie den Bucket-Namen an.
    2
    Geben Sie die CR Secrets des Objektspeichers an. Sie müssen sicherstellen, dass die in der CR Secrets des Objektspeichers gespeicherten Anmeldedaten korrekt sind.
    3
    Geben Sie den Speicheranbieter an.
    4
    Optional: Wenn Sie Daten mit Hilfe von Schnappschüssen kopieren, geben Sie die CR Secrets des Objektspeichers an. Sie müssen sicherstellen, dass die in der CR Secrets des Objektspeichers gespeicherten Anmeldedaten korrekt sind.
    5
    Optional: Wenn Sie Daten mit Hilfe von Schnappschüssen kopieren, geben Sie den Speicheranbieter an.
  7. Verifizieren Sie, dass die CR MigStorage den Status Ready hat:

    $ oc describe migstorage <migstorage>
  8. Erstellen Sie ein MigPlan-CR-Manifest:

    $ cat << EOF | oc apply -f -
    apiVersion: migration.openshift.io/v1alpha1
    kind: MigPlan
    metadata:
      name: <migplan>
      namespace: openshift-migration
    spec:
      destMigClusterRef:
        name: <host_cluster>
        namespace: openshift-migration
      indirectImageMigration: true 1
      indirectVolumeMigration: true 2
      migStorageRef:
        name: <migstorage> 3
        namespace: openshift-migration
      namespaces:
        - <source_namespace_1> 4
        - <source_namespace_2>
        - <source_namespace_3>:<destination_namespace> 5
      srcMigClusterRef:
        name: <remote_cluster> 6
        namespace: openshift-migration
    EOF
    1
    Direct Image Migration ist aktiviert, wenn false.
    2
    Direct Volume Migration ist aktiviert, wenn false.
    3
    Geben Sie den Namen der CR-Instanz MigStorage an.
    4
    Geben Sie einen oder mehrere Quell-Namespaces an. Standardmäßig hat der Ziel-Namespace denselben Namen.
    5
    Geben Sie einen Ziel-Namespace an, wenn er sich vom Quell-Namespace unterscheidet.
    6
    Geben Sie den Namen der Instanz MigCluster des Quell-Clusters an.
  9. Vergewissern Sie sich, dass die Instanz MigPlan sich im Status Ready befindet:

    $ oc describe migplan <migplan> -n openshift-migration
  10. Erstellen Sie ein MigMigration-CR-Manifest, um die in der Instanz MigPlan definierte Migration zu starten:

    $ cat << EOF | oc apply -f -
    apiVersion: migration.openshift.io/v1alpha1
    kind: MigMigration
    metadata:
      name: <migmigration>
      namespace: openshift-migration
    spec:
      migPlanRef:
        name: <migplan> 1
        namespace: openshift-migration
      quiescePods: true 2
      stage: false 3
      rollback: false 4
    EOF
    1
    Geben Sie den Namen der CR MigPlan an.
    2
    Die Pods auf dem Quell-Cluster werden vor der Migration gestoppt, wenn true.
    3
    Wenn true, wird eine Stage-Migration durchgeführt, bei der die meisten Daten kopiert werden, ohne die Anwendung anzuhalten.
    4
    Eine abgeschlossene Migration wird rückgängig gemacht, wenn true.
  11. Überprüfen Sie die Migration, indem Sie den Fortschritt der CR MigMigration beobachten:

    $ oc watch migmigration <migmigration> -n openshift-migration

    Die Ausgabe sieht wie folgt aus:

    Beispielausgabe

    Name:         c8b034c0-6567-11eb-9a4f-0bc004db0fbc
    Namespace:    openshift-migration
    Labels:       migration.openshift.io/migplan-name=django
    Annotations:  openshift.io/touch: e99f9083-6567-11eb-8420-0a580a81020c
    API Version:  migration.openshift.io/v1alpha1
    Kind:         MigMigration
    ...
    Spec:
      Mig Plan Ref:
        Name:       migplan
        Namespace:  openshift-migration
      Stage:        false
    Status:
      Conditions:
        Category:              Advisory
        Last Transition Time:  2021-02-02T15:04:09Z
        Message:               Step: 19/47
        Reason:                InitialBackupCreated
        Status:                True
        Type:                  Running
        Category:              Required
        Last Transition Time:  2021-02-02T15:03:19Z
        Message:               The migration is ready.
        Status:                True
        Type:                  Ready
        Category:              Required
        Durable:               true
        Last Transition Time:  2021-02-02T15:04:05Z
        Message:               The migration registries are healthy.
        Status:                True
        Type:                  RegistriesHealthy
      Itinerary:               Final
      Observed Digest:         7fae9d21f15979c71ddc7dd075cb97061895caac5b936d92fae967019ab616d5
      Phase:                   InitialBackupCreated
      Pipeline:
        Completed:  2021-02-02T15:04:07Z
        Message:    Completed
        Name:       Prepare
        Started:    2021-02-02T15:03:18Z
        Message:    Waiting for initial Velero backup to complete.
        Name:       Backup
        Phase:      InitialBackupCreated
        Progress:
          Backup openshift-migration/c8b034c0-6567-11eb-9a4f-0bc004db0fbc-wpc44: 0 out of estimated total of 0 objects backed up (5s)
        Started:        2021-02-02T15:04:07Z
        Message:        Not started
        Name:           StageBackup
        Message:        Not started
        Name:           StageRestore
        Message:        Not started
        Name:           DirectImage
        Message:        Not started
        Name:           DirectVolume
        Message:        Not started
        Name:           Restore
        Message:        Not started
        Name:           Cleanup
      Start Timestamp:  2021-02-02T15:03:18Z
    Events:
      Type    Reason   Age                 From                     Message
      ----    ------   ----                ----                     -------
      Normal  Running  57s                 migmigration_controller  Step: 2/47
      Normal  Running  57s                 migmigration_controller  Step: 3/47
      Normal  Running  57s (x3 over 57s)   migmigration_controller  Step: 4/47
      Normal  Running  54s                 migmigration_controller  Step: 5/47
      Normal  Running  54s                 migmigration_controller  Step: 6/47
      Normal  Running  52s (x2 over 53s)   migmigration_controller  Step: 7/47
      Normal  Running  51s (x2 over 51s)   migmigration_controller  Step: 8/47
      Normal  Ready    50s (x12 over 57s)  migmigration_controller  The migration is ready.
      Normal  Running  50s                 migmigration_controller  Step: 9/47
      Normal  Running  50s                 migmigration_controller  Step: 10/47

11.2.5. State-Migration

Sie können wiederholbare, reine State-Migrationen durchführen, indem Sie Migration Toolkit for Container (MTC) verwenden, um Persistent Volume Claims (PVCs) zu migrieren, die den Zustand einer Anwendung bilden. Sie migrieren bestimmte PVCs, indem Sie andere PVCs aus dem Migrationsplan ausschließen. PV-Daten (Persistent Volume) werden auf den Ziel-Cluster kopiert. Die PV-Referenzen werden nicht verschoben. Die Anwendungspods werden weiterhin auf dem Quell-Cluster ausgeführt. Sie können die PVCs zuordnen, um sicherzustellen, dass die Quell- und Ziel-PVCs synchronisiert sind.

Sie können eine einmalige Migration von Kubernetes-Objekten durchführen, die den Status einer Anwendung bilden.

Wenn Sie über eine CI/CD-Pipeline verfügen, können Sie zustandslose Komponenten migrieren, indem Sie sie auf dem Ziel-Cluster bereitstellen. Dann können Sie zustandsbehaftete Komponenten mit Hilfe von MTC migrieren.

Sie können eine State-Migration zwischen Clustern oder innerhalb desselben Clusters durchführen.

Wichtig

Bei der State-Migration werden nur die Komponenten migriert, die den Status einer Anwendung bilden. Wenn Sie einen ganzen Namespace migrieren möchten, verwenden Sie die Stage- oder Cutover-Migration.

Zusätzliche Ressourcen

11.3. Hooks für die Migration

Sie können einem einzelnen Migrationsplan bis zu vier Hooks für die Migration hinzufügen, wobei jeder Hook in einer anderen Phase der Migration ausgeführt wird. Hooks für die Migration übernehmen Aufgaben wie die Anpassung der Anwendungsruhezeit, die manuelle Migration nicht unterstützter Datentypen und die Aktualisierung von Anwendungen nach der Migration.

Ein Hook für die Migration wird auf einem Quell- oder Ziel-Cluster bei einem der folgenden Migrationsschritte ausgeführt:

  • PreBackup: Bevor die Ressourcen auf dem Quell-Cluster gesichert werden.
  • PostBackup: Nachdem die Ressourcen auf dem Quell-Cluster gesichert wurden.
  • PreRestore: Bevor die Ressourcen auf dem Ziel-Cluster wiederhergestellt werden.
  • PostRestore: Nachdem die Ressourcen auf dem Ziel-Cluster wiederhergestellt wurden.

Sie können einen Hook erstellen, indem Sie ein Ansible-Playbook erstellen, das mit dem standardmäßigen Ansible-Image oder mit einem benutzerdefinierten Hook-Container ausgeführt wird.

Ansible-Playbook

Das Ansible-Playbook wird in einen Hook-Container als Config-Map eingebunden. Der Hook-Container wird als Auftrag ausgeführt und verwendet den Cluster, den Service Account und den Namespace, die in der Custom Resource MigPlan angegeben sind. Der Auftrag wird so lange ausgeführt, bis er die Standardgrenze von 6 Wiederholungen erreicht oder erfolgreich abgeschlossen wird. Dies gilt auch dann, wenn der ursprüngliche Pod gestoppt oder beendet wird.

Das standardmäßige Ansible-Laufzeit-Image ist registry.redhat.io/rhmtc/openshift-migration-hook-runner-rhel7:1.6. Dieses Image basiert auf dem Ansible-Runner-Image und enthält python-openshift für Ansible-Kubernetes-Ressourcen und eine aktualisierte oc-Binärdatei.

Kundenspezifischer Hook-Container

Sie können einen eigenen Hook-Container anstelle des standardmäßigen Ansible-Image verwenden.

11.3.1. Schreiben eines Ansible-Playbooks für einen Hook für die Migration

Sie können ein Ansible-Playbook schreiben, das als Hook für die Migration dient. Der Hook wird einem Migrationsplan über die MTC-Webkonsole oder durch Angabe von Werten für die spec.hooks-Parameter im Manifest der Custom Resource (CR) MigPlan hinzugefügt.

Das Ansible-Playbook wird als Config-Map in einen Hook-Container eingebunden. Der Hook-Container wird als Auftrag ausgeführt und verwendet den Cluster, den Service Account und den Namespace, die in der CR MigPlan angegeben sind. Der Hook-Container verwendet ein bestimmtes Service Account-Token, sodass die Aufgaben keine Authentifizierung erfordern, bevor sie im Cluster ausgeführt werden.

11.3.1.1. Ansible-Module

Sie können das Ansible-Modul shell verwenden, um oc-Befehle auszuführen.

Beispiel für ein shell-Modul

- hosts: localhost
  gather_facts: false
  tasks:
  - name: get pod name
    shell: oc get po --all-namespaces

Sie können kubernetes.core-Module wie z. B. k8s_info verwenden, um mit Kubernetes-Ressourcen zu interagieren.

Beispiel für ein k8s_facts-Modul

- hosts: localhost
  gather_facts: false
  tasks:
  - name: Get pod
    k8s_info:
      kind: pods
      api: v1
      namespace: openshift-migration
      name: "{{ lookup( 'env', 'HOSTNAME') }}"
    register: pods

  - name: Print pod name
    debug:
      msg: "{{ pods.resources[0].metadata.name }}"

Sie können das Modul fail verwenden, um einen Exit-Status ungleich 0 in Fällen zu erzeugen, in denen dieser Status normalerweise erzeugt werden würde. Dies würde die Erkennung eines erfolgreichen oder fehlerhaften Hook sicherstellen. Hooks werden als Aufträge ausgeführt und der Erfolg oder Misserfolg eines Hook basiert auf dem Exit-Status des Auftragscontainers.

Beispiel für ein fail-Modul

- hosts: localhost
  gather_facts: false
  tasks:
  - name: Set a boolean
    set_fact:
      do_fail: true

  - name: "fail"
    fail:
      msg: "Cause a failure"
    when: do_fail

11.3.1.2. Umgebungsvariablen

Der CR-Name MigPlan und die Namespaces für die Migration werden als Umgebungsvariablen an den Hook-Container übergeben. Der Zugriff auf diese Variablen erfolgt über das Plugin lookup.

Beispiel für Umgebungsvariablen

- hosts: localhost
  gather_facts: false
  tasks:
  - set_fact:
      namespaces: "{{ (lookup( 'env', 'migration_namespaces')).split(',') }}"

  - debug:
      msg: "{{ item }}"
    with_items: "{{ namespaces }}"

  - debug:
      msg: "{{ lookup( 'env', 'migplan_name') }}"

11.4. Optionen für den Migrationsplan

Sie können Komponenten in der Custom Resource (CR) MigPlan ausschließen, bearbeiten und zuordnen.

11.4.1. Ausschließen von Ressourcen

Sie können Ressourcen, z. B. Image-Streams, Persistent Volumes (PVs) oder Abonnements, aus einem Migrationsplan des Migration Toolkit for Containers (MTC) ausschließen, um die Ressourcenlast für die Migration zu reduzieren oder um Images oder PVs mit einem anderen Tool zu migrieren.

Standardmäßig schließt das MTC Servicekatalog- und OLM-Ressourcen (Operator Lifecycle Manager) von der Migration aus. Diese Ressourcen sind Teil der Servicekatalog-API- und der OLM-API-Gruppe, die beide derzeit nicht für die Migration unterstützt werden.

Vorgehensweise

  1. Bearbeiten Sie das Manifest der Custom Resource MigrationController:

    $ oc edit migrationcontroller <migration_controller> -n openshift-migration
  2. Aktualisieren Sie den Abschnitt spec, indem Sie einen Parameter hinzufügen, um bestimmte Ressourcen auszuschließen, oder indem Sie eine Ressource zum Parameter excluded_resources hinzufügen, wenn sie keinen eigenen Ausschlussparameter hat:

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigrationController
    metadata:
      name: migration-controller
      namespace: openshift-migration
    spec:
      disable_image_migration: true 1
      disable_pv_migration: true 2
      ...
      excluded_resources: 3
      - imagetags
      - templateinstances
      - clusterserviceversions
      - packagemanifests
      - subscriptions
      - servicebrokers
      - servicebindings
      - serviceclasses
      - serviceinstances
      - serviceplans
      - operatorgroups
      - events
      - events.events.k8s.io
    1
    Fügen Sie disable_image_migration: true hinzu, um Image Streams von der Migration auszuschließen. Bearbeiten Sie den Parameter excluded_resources nicht. imagestreams wird zu excluded_resources hinzugefügt, wenn der Pod MigrationController neu startet.
    2
    Fügen Sie disable_pv_migration: true hinzu, um PVs aus dem Migrationsplan auszuschließen. Bearbeiten Sie den Parameter excluded_resources nicht. persistentvolumes und persistentvolumeclaims werden zu excluded_resources hinzugefügt, wenn der Pod MigrationController neu startet. Die Deaktivierung der PV-Migration deaktiviert auch die PV-Erkennung bei der Erstellung des Migrationsplans.
    3
    Sie können OpenShift Container Platform-Ressourcen zur Liste excluded_resources hinzufügen. Löschen Sie die standardmäßig ausgeschlossenen Ressourcen nicht. Diese Ressourcen sind schwer zu migrieren und müssen ausgeschlossen werden.
  3. Warten Sie zwei Minuten, bis der Pod MigrationController neu gestartet ist, damit die Änderungen übernommen werden.
  4. Überprüfen Sie, ob die Ressource ausgeschlossen wurde:

    $ oc get deployment -n openshift-migration migration-controller -o yaml | grep EXCLUDED_RESOURCES -A1

    Die Ausgabe enthält die ausgeschlossenen Ressourcen:

    Beispielausgabe

        - name: EXCLUDED_RESOURCES
          value:
          imagetags,templateinstances,clusterserviceversions,packagemanifests,subscriptions,servicebrokers,servicebindings,serviceclasses,serviceinstances,serviceplans,imagestreams,persistentvolumes,persistentvolumeclaims

11.4.2. Zuordnen von Namespaces

Wenn Sie Namespaces in der Custom Resource (CR) MigPlan zuordnen, müssen Sie sicherstellen, dass die Namespaces weder auf dem Quell- noch auf dem Ziel-Cluster dupliziert werden, da die UID- und GID-Bereiche der Namespaces während der Migration kopiert werden.

Zwei Quell-Namespaces, die demselben Ziel-Namespace zugeordnet sind

spec:
  namespaces:
    - namespace_2
    - namespace_1:namespace_2

Wenn Sie möchten, dass der Quell-Namespace einem gleichnamigen Namespace zugeordnet wird, müssen Sie kein Mapping erstellen. Standardmäßig haben ein Quell- und ein Ziel-Namespace denselben Namen.

Falsche Namespace-Zuordnung

spec:
  namespaces:
    - namespace_1:namespace_1

Korrekte Namespace-Referenz

spec:
  namespaces:
    - namespace_1

11.4.3. Ausschließen von Persistent Volume Claims

Sie wählen Persistent Volume Claims (PVCs) für die Statusmigration aus, indem Sie die PVCs ausschließen, die Sie nicht migrieren möchten. Sie schließen PVCs aus, indem Sie den Parameter spec.persistentVolumes.pvc.selection.action der Custom Resource (CR) MigPlan festlegen, nachdem die Persistent Volumes (PVs) erkannt worden sind.

Voraussetzungen

  • CR MigPlan befindet sich im Status Ready.

Vorgehensweise

  • Fügen Sie den Parameter spec.persistentVolumes.pvc.selection.action zur CR MigPlan hinzu und legen Sie ihn auf skip fest:

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigPlan
    metadata:
      name: <migplan>
      namespace: openshift-migration
    spec:
    ...
      persistentVolumes:
      - capacity: 10Gi
        name: <pv_name>
        pvc:
    ...
        selection:
          action: skip

11.4.4. Zuordnen von Persistent Volume Claims

Sie können PV-Daten (Persistent Volume) aus dem Quell-Cluster in Persistent Volume Claims (PVCs) migrieren, die bereits im Ziel-Cluster in der CR MigPlan bereitgestellt wurden, indem Sie die PVCs zuordnen. Dieses Mapping stellt sicher, dass die Ziel-PVCs der migrierten Anwendungen mit den Quell-PVCs synchronisiert werden.

Sie ordnen PVCs zu, indem Sie den Parameter spec.persistentVolumes.pvc.name in der Custom Resource (CR) MigPlan aktualisieren, nachdem die PVs erkannt wurden.

Voraussetzungen

  • CR MigPlan befindet sich im Status Ready.

Vorgehensweise

  • Aktualisieren Sie den Parameter spec.persistentVolumes.pvc.name in der CR MigPlan:

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigPlan
    metadata:
      name: <migplan>
      namespace: openshift-migration
    spec:
    ...
      persistentVolumes:
      - capacity: 10Gi
        name: <pv_name>
        pvc:
          name: <source_pvc>:<destination_pvc> 1
    1
    Geben Sie den PVC auf dem Quell-Cluster und den PVC auf dem Ziel-Cluster an. Wenn der Ziel-PVC nicht existiert, wird er erstellt. Sie können dieses Mapping verwenden, um den PVC-Namen während der Migration zu ändern.

11.4.5. Bearbeiten von Attributen von Persistent Volumes

Nachdem Sie die Custom Resource (CR) MigPlan erstellt haben, erkennt die CR MigrationController die Persistent Volumes (PVs). Der Block spec.persistentVolumes und der Block status.destStorageClasses werden der CR MigPlan hinzugefügt.

Sie können die Werte im Block spec.persistentVolumes.selection bearbeiten. Wenn Sie Werte außerhalb des Blocks spec.persistentVolumes.selection ändern, werden die Werte überschrieben, wenn die CR MigPlan mit der CR MigrationController abgestimmt wird.

Anmerkung

Der Standardwert für den Parameter spec.persistentVolumes.selection.storageClass wird durch die folgende Logik bestimmt:

  1. Wenn das PV des Quell-Clusters Gluster oder NFS ist, ist der Standard entweder cephfs für accessMode: ReadWriteMany oder cephrbd für accessMode: ReadWriteOnce.
  2. Wenn es sich bei dem PV weder um Gluster noch um NFS handelt oder wenn cephfs oder cephrbd nicht verfügbar ist, wird standardmäßig eine Speicherklasse für denselben Anbieter verwendet.
  3. Wenn keine Speicherklasse für denselben Anbieter verfügbar ist, wird als Standard die Standard-Speicherklasse des Ziel-Clusters verwendet.

Sie können den Wert von storageClass in den Wert eines beliebigen name-Parameters im Block status.destStorageClasses der CR MigPlan ändern.

Wenn der Wert für storageClass leer ist, hat das PV nach der Migration keine Speicherklasse. Diese Option eignet sich beispielsweise, wenn Sie das PV auf ein NFS-Volume auf dem Ziel-Cluster verschieben möchten.

Voraussetzungen

  • CR MigPlan befindet sich im Status Ready.

Vorgehensweise

  • Bearbeiten Sie die Werte von spec.persistentVolumes.selection in der CR MigPlan:

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigPlan
    metadata:
      name: <migplan>
      namespace: openshift-migration
    spec:
      persistentVolumes:
      - capacity: 10Gi
        name: pvc-095a6559-b27f-11eb-b27f-021bddcaf6e4
        proposedCapacity: 10Gi
        pvc:
          accessModes:
          - ReadWriteMany
          hasReference: true
          name: mysql
          namespace: mysql-persistent
        selection:
          action: <copy> 1
          copyMethod: <filesystem> 2
          verify: true 3
          storageClass: <gp2> 4
          accessMode: <ReadWriteMany> 5
        storageClass: cephfs
    1
    Erlaubte Werte sind move, copy und skip. Wenn nur eine Aktion unterstützt wird, ist der Standardwert die unterstützte Aktion. Wenn mehrere Aktionen unterstützt werden, ist der Standardwert copy.
    2
    Erlaubte Werte sind snapshot und filesystem. Der Standardwert ist filesystem.
    3
    Der Parameter verify wird angezeigt, wenn Sie in der MTC-Webkonsole die Verifizierungsoption für Dateisystemkopien auswählen. Sie können ihn auf false festlegen.
    4
    Sie können den Standardwert in den Wert eines beliebigen name-Parameters im Block status.destStorageClasses der CR MigPlan ändern. Wenn kein Wert angegeben wird, hat der PV nach der Migration keine Speicherklasse.
    5
    Erlaubte Werte sind ReadWriteOnce und ReadWriteMany. Wird dieser Wert nicht angegeben, gilt als Standard der Zugriffsmodus des PVC des Quell-Clusters. Sie können den Zugriffsmodus nur in der CR MigPlan bearbeiten. Sie können ihn nicht über die MTC-Webkonsole bearbeiten.
Zusätzliche Ressourcen

11.4.6. Migrieren von Kubernetes-Objekten

Sie können eine einmalige Migration von Kubernetes-Objekten durchführen, die den Status einer Anwendung bilden.

Anmerkung

Nach der Migration wird der Parameter closed der CR MigPlan auf true festgelegt. Sie können keine weitere MigMigration-CR für diese MigPlan-CR erstellen.

Sie fügen Kubernetes-Objekte zur CR MigPlan hinzu, indem Sie eine der folgenden Optionen verwenden:

  • Hinzufügen der Kubernetes-Objekte zum Abschnitt includedResources
  • Verwenden des Parameters labelSelector zum Verweisen auf Kubernetes-Objekte mit Bezeichnung
  • Hinzufügen von Kubernetes-Objekten zum Abschnitt includedResources und anschließendes Filtern mit dem Parameter labelSelector, z. B. Ressourcen Secret und ConfigMap mit der Bezeichnung app: frontend

Vorgehensweise

  • Aktualisieren Sie die CR MigPlan:

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigPlan
    metadata:
      name: <migplan>
      namespace: openshift-migration
    spec:
      includedResources:
      - kind: <kind> 1
        group: ""
      - kind: <kind>
        group: ""
    ...
      labelSelector:
        matchLabels:
          <label> 2
    1
    Geben Sie das Kubernetes-Objekt an, z. B. Secret oder ConfigMap.
    2
    Geben Sie die Bezeichnung der zu migrierenden Ressourcen an, z. B. app: frontend.

11.5. Optionen für Migration Controller

Sie können in der Custom Resource (CR) MigrationController Grenzen für Migrationspläne bearbeiten, die Größenänderung von Persistent Volumes aktivieren oder zwischengespeicherte Kubernetes-Clients für große Migrationen und verbesserte Leistung aktivieren.

11.5.1. Anheben der Grenzen für große Migrationen

Mit dem Migration Toolkit for Containers (MTC) können Sie die Grenzen für Migrationsobjekte und Container-Ressourcen für große Migrationen anheben.

Wichtig

Sie müssen diese Änderungen testen, bevor Sie eine Migration in einer Produktionsumgebung durchführen.

Vorgehensweise

  1. Bearbeiten Sie das Manifest der Custom Resource (CR) MigrationController:

    $ oc edit migrationcontroller -n openshift-migration
  2. Aktualisieren Sie die folgenden Parameter:

    ...
    mig_controller_limits_cpu: "1" 1
    mig_controller_limits_memory: "10Gi" 2
    ...
    mig_controller_requests_cpu: "100m" 3
    mig_controller_requests_memory: "350Mi" 4
    ...
    mig_pv_limit: 100 5
    mig_pod_limit: 100 6
    mig_namespace_limit: 10 7
    ...
    1
    Gibt die Anzahl der CPUs an, die der CR MigrationController zur Verfügung stehen.
    2
    Gibt an, wie viel Speicherplatz der CR MigrationController zur Verfügung steht.
    3
    Gibt die Anzahl der für Anforderungen der CR MigrationController verfügbaren CPU-Einheiten an. 100m entsprechen 0,1 CPU-Einheiten (100 * 1e-3).
    4
    Gibt an, wie viel Speicherplatz für Anforderungen der CR MigrationController zur Verfügung steht.
    5
    Gibt die Anzahl der Persistent Volumes an, die migriert werden können.
    6
    Gibt die Anzahl der Pods an, die migriert werden können.
    7
    Gibt die Anzahl der Namespaces an, die migriert werden können.
  3. Erstellen Sie einen Migrationsplan, der die aktualisierten Parameter verwendet, um die Änderungen zu verifizieren.

    Wenn Ihr Migrationsplan die Grenzen der CR MigrationController überschreitet, zeigt die MTC-Konsole eine Warnmeldung an, wenn Sie den Migrationsplan speichern.

11.5.2. Aktivieren der Größenänderung eines Persistent Volume für Direct Volume Migration

Sie können die Größenänderung von Persistent Volumes (PV) für Direct Volume Migration aktivieren, um zu vermeiden, dass der Festplatten-Speicherplatz auf dem Ziel-Cluster knapp wird.

Wenn die Festplattennutzung eines PV ein konfiguriertes Niveau erreicht, vergleicht die Custom Resource (CR) MigrationController die angeforderte Speicherkapazität eines Persistent Volume Claim (PVC) mit dessen tatsächlich bereitgestellter Kapazität. Anschließend wird der benötigte Speicherplatz auf dem Ziel-Cluster berechnet.

Der Parameter pv_resizing_threshold legt fest, wann die PV-Größenänderung verwendet wird. Der Standardwert ist 3%. Das bedeutet, dass eine Größenänderung des PV erfolgt, wenn die Festplattennutzung eines PV mehr als 97% beträgt. Sie können diesen Schwellenwert erhöhen, damit die PV-Größenänderung bei einer geringeren Festplattennutzung erfolgt.

Die PVC-Kapazität wird nach den folgenden Kriterien berechnet:

  • Wenn die angeforderte Speicherkapazität (spec.resources.requests.storage) des PVC nicht mit seiner tatsächlich bereitgestellten Kapazität (status.capacity.storage) übereinstimmt, wird der größere Wert verwendet.
  • Wenn ein PV über einen PVC bereitgestellt und dann später geändert wird, sodass seine PV- und PVC-Kapazitäten nicht mehr übereinstimmen, wird der größere Wert verwendet.

Voraussetzungen

  • Die PVCs müssen mit einem oder mehreren ausgeführten Pods verbunden sein, damit die CR MigrationController Befehle ausführen kann.

Vorgehensweise

  1. Melden Sie sich beim Host-Cluster an.
  2. Aktivieren Sie die Größenänderung des PV, indem Sie die CR MigrationController patchen:

    $ oc patch migrationcontroller migration-controller -p '{"spec":{"enable_dvm_pv_resizing":true}}' \ 1
      --type='merge' -n openshift-migration
    1
    Legen Sie den Wert auf false fest, um die Größenänderung des PV zu deaktivieren.
  3. Optional: Aktualisieren Sie den Parameter pv_resizing_threshold, um den Schwellenwert zu erhöhen:

    $ oc patch migrationcontroller migration-controller -p '{"spec":{"pv_resizing_threshold":41}}' \ 1
      --type='merge' -n openshift-migration
    1
    Der Standardwert ist 3.

    Wenn der Schwellenwert überschritten wird, wird die folgende Statusmeldung im Status der CR MigPlan angezeigt:

    status:
      conditions:
    ...
      - category: Warn
        durable: true
        lastTransitionTime: "2021-06-17T08:57:01Z"
        message: 'Capacity of the following volumes will be automatically adjusted to avoid disk capacity issues in the target cluster:  [pvc-b800eb7b-cf3b-11eb-a3f7-0eae3e0555f3]'
        reason: Done
        status: "False"
        type: PvCapacityAdjustmentRequired
    Anmerkung

    Bei AWS gp2-Speicher wird diese Meldung nur angezeigt, wenn pv_resizing_threshold 42 % oder mehr beträgt, da gp2 die Volume-Nutzung und -Größe auf diese Weise berechnet. (BZ#1973148)

11.5.3. Aktivieren von zwischengespeicherten Kubernetes-Clients

Sie können zwischengespeicherte Kubernetes-Clients in der Custom Ressource (CR) MigrationController aktivieren, um die Leistung während der Migration zu verbessern. Der größte Leistungsvorteil zeigt sich bei der Migration zwischen Clustern in verschiedenen Regionen oder bei erheblicher Netzwerklatenz.

Anmerkung

Delegierte Aufgaben, z. B. Rsync-Backup für Direct Volume Migration oder Velero-Backup und -Restore, zeigen jedoch keine verbesserte Leistung bei zwischengespeicherten Clients.

Zwischenspeicherte Clients benötigen zusätzlichen Arbeitsspeicher, da die CR MigrationController alle API-Ressourcen zwischenspeichert, die für die Interaktion mit MigCluster-CRs erforderlich sind. Anfragen, die normalerweise an den API-Server gesendet werden, werden stattdessen an den Cache geleitet. Der Cache überwacht den API-Server auf Updates.

Sie können die Arbeitsspeicher-Grenzen und Anforderungen der CR MigrationController anheben, wenn OOMKilled-Fehler auftreten, nachdem Sie zwischengespeicherte Clients aktiviert haben.

Vorgehensweise

  1. Aktivieren Sie zwischengespeicherte Clients, indem Sie den folgenden Befehl ausführen:

    $ oc -n openshift-migration patch migrationcontroller migration-controller --type=json --patch \
      '[{ "op": "replace", "path": "/spec/mig_controller_enable_cache", "value": true}]'
  2. Optional: Erhöhen Sie die Arbeitsspeicher-Grenzen der CR MigrationController, indem Sie den folgenden Befehl ausführen:

    $ oc -n openshift-migration patch migrationcontroller migration-controller --type=json --patch \
      '[{ "op": "replace", "path": "/spec/mig_controller_limits_memory", "value": <10Gi>}]'
  3. Optional: Erhöhen Sie die Arbeitsspeicher-Anforderungen der CR MigrationController, indem Sie den folgenden Befehl ausführen:

    $ oc -n openshift-migration patch migrationcontroller migration-controller --type=json --patch \
      '[{ "op": "replace", "path": "/spec/mig_controller_requests_memory", "value": <350Mi>}]'

Kapitel 12. Problembehandlung

In diesem Abschnitt werden Ressourcen zur Problembehandlung für das Migration Toolkit for Containers (MTC) beschrieben.

Bekannte Probleme finden Sie in den MTC-Versionshinweisen.

12.1. MTC-Workflow

Sie können Kubernetes-Ressourcen, Persistent Volume-Daten und interne Container-Images auf OpenShift Container Platform 4.10 migrieren, indem Sie die MTC-Webkonsole (Migration Toolkit for Containers) oder die Kubernetes-API verwenden.

MTC migriert die folgenden Ressourcen:

  • Ein in einem Migrationsplan angegebener Namespace.
  • Namespace-gebundene Ressourcen: Wenn der MTC einen Namespace migriert, migriert er alle mit diesem Namespace verbundenen Objekte und Ressourcen, wie z. B. Dienste oder Pods. Wenn außerdem eine Ressource, die im Namespace, aber nicht auf Cluster-Ebene existiert, von einer Ressource abhängt, die auf Cluster-Ebene existiert, migriert das MTC beide Ressourcen.

    Ein Security Context Constraint (SCC) ist beispielsweise eine Ressource, die auf Cluster-Ebene existiert, und ein Service Account (SA) ist eine Ressource, die auf Namespace-Ebene existiert. Wenn ein SA in einem Namespace existiert, den das MTC migriert, findet der MTC automatisch alle SCCs, die mit dem SA verknüpft sind, und migriert auch diese SCCs. In ähnlicher Weise migriert der MTC Persistent Volume Claims, die mit den Persistent Volumes des Namespace verknüpft sind.

    Anmerkung

    Cluster-gebundene Ressourcen müssen je nach Ressource möglicherweise manuell migriert werden.

  • Custom Resources (CRs) und Custom Resource Definitions (CRDs): MTC migriert automatisch CRs und CRDs auf Namespace-Ebene.

Die Migration einer Anwendung mit der MTC-Webkonsole umfasst die folgenden Schritte:

  1. Installieren Sie den Migration Toolkit for Containers Operator auf allen Clustern.

    Sie können den Migration Toolkit for Containers Operator in einer eingeschränkten Umgebung mit begrenztem oder keinem Internetzugang installieren. Die Quell- und Ziel-Cluster müssen über einen Netzwerkzugang zueinander und zu einer Spiegelregistrierung verfügen.

  2. Konfigurieren Sie das Replikations-Repository, einen temporären Objektspeicher, den MTC für die Datenmigration verwendet.

    Quell- und Ziel-Cluster müssen während der Migration Netzwerkzugriff auf das Replikations-Repository haben. Wenn Sie einen Proxyserver verwenden, müssen Sie ihn so konfigurieren, dass der Netzwerkverkehr zwischen dem Replikations-Repository und den Clustern zugelassen wird.

  3. Fügen Sie den Quell-Cluster zur MTC-Webkonsole hinzu.
  4. Fügen Sie das Replikations-Repository zur MTC-Webkonsole hinzu.
  5. Erstellen Sie einen Migrationsplan mit einer der folgenden Datenmigrationsoptionen:

    • Copy: MTC kopiert die Daten aus dem Quell-Cluster in das Replikations-Repository und aus dem Replikations-Repository in den Ziel-Cluster.

      Anmerkung

      Bei der Direct Image Migration oder der Direct Volume Migration werden die Images oder Volumes direkt vom Quell-Cluster auf den Ziel-Cluster kopiert.

      PV-Migration – Copy
    • Move: MTC gebt die Bereitstellung eines Remote-Volume auf, z. B. NFS auf dem Quell-Cluster, erstellt eine PV-Ressource auf dem Ziel-Cluster, die auf das Remote-Volume zeigt, und stellt dann das Remote-Volume auf dem Ziel-Cluster bereit. Anwendungen, die auf dem Ziel-Cluster ausgeführt werden, verwenden dasselbe Remote-Volume, das auch der Quell-Cluster verwendet hat. Das Remote-Volume muss für den Quell- und den Ziel-Cluster zugänglich sein.

      Anmerkung

      Obwohl das Replikations-Repository in diesem Diagramm nicht angezeigt wird, ist es für die Migration erforderlich.

      PV-Migration – Move
  6. Führen Sie den Migrationsplan mit einer der folgenden Optionen aus:

    • Stage kopiert Daten auf den Ziel-Cluster, ohne die Anwendung anzuhalten.

      Eine Stage-Migration kann mehrfach durchgeführt werden, sodass die meisten Daten vor der Migration auf das Ziel kopiert werden. Die Durchführung einer oder mehrerer Stage-Migrationen verkürzt die Dauer der Cutover-Migration.

    • Cutover stoppt die Anwendung auf dem Quell-Cluster und verschiebt die Ressourcen auf den Ziel-Cluster.

      Optional: Sie können das Kontrollkästchen Halt transactions on the source cluster during migration deaktivieren.

OCP 3 zu 4 – App-Migration

Informationen zu den Custom Resources von MTC

Das Migration Toolkit for Containers (MTC) erstellt die folgenden Custom Resources (CRs):

Diagramm der Migrationsarchitektur

20 MigCluster (Konfiguration, MTC-Cluster): Cluster-Definition

20 MigStorage (Konfiguration, MTC-Cluster): Speicherdefinition

20 MigPlan (Konfiguration, MTC-Cluster): Migrationsplan

Die CR MigPlan beschreibt die Quell- und Ziel-Cluster, das Replikations-Repository und die zu migrierenden Namespaces. Sie ist mit 0, 1 oder vielen MigMigration-CRs verbunden.

Anmerkung

Beim Löschen einer MigPlan-CR werden die damit zusammenhängenden MigMigration-CRs gelöscht.

20 BackupStorageLocation (Konfiguration, MTC-Cluster): Speicherort der Velero-Backup-Objekte

20 VolumeSnapshotLocation (Konfiguration, MTC-Cluster): Speicherort der Velero-Volume-Schnappschüsse

20 MigMigration (Aktion, MTC-Cluster): Migration, die jedes Mal erstellt wird, wenn Sie Daten bereitstellen oder migrieren. Jede MigMigration-CR hängt mit einer MigPlan-CR zusammen.

20 Backup (Aktion, Quell-Cluster): Wenn Sie einen Migrationsplan ausführen, erstellt die CR MigMigration zwei Velero-Backup-CRs auf jedem Quell-Cluster:

  • Backup-CR 1 für Kubernetes-Objekte
  • Backup-CR 2 für PV-Daten

20 Restore (Aktion, Ziel-Cluster): Wenn Sie einen Migrationsplan ausführen, erstellt die CR MigMigration zwei Velero-Restore-CRs auf dem Ziel-Cluster:

  • CR 1 (mit Backup-CR 2) für PV-Daten wiederherstellen
  • CR 2 (mit Backup-CR 1) für Kubernetes-Objekte wiederherstellen

12.2. MTC – Manifeste für Custom Resource

Migration Toolkit for Containers (MTC) verwendet die folgenden Manifeste der Custom Resource (CR) für die Migration von Anwendungen.

12.2.1. DirectImageMigration

Die CR DirectImageMigration kopiert Images direkt vom Quell-Cluster auf den Ziel-Cluster.

apiVersion: migration.openshift.io/v1alpha1
kind: DirectImageMigration
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: <direct_image_migration>
spec:
  srcMigClusterRef:
    name: <source_cluster>
    namespace: openshift-migration
  destMigClusterRef:
    name: <destination_cluster>
    namespace: openshift-migration
  namespaces: 1
    - <source_namespace_1>
    - <source_namespace_2>:<destination_namespace_3> 2
1
Ein oder mehrere Namespaces, die zu migrierende Images enthalten. Standardmäßig hat der Ziel-Namespace denselben Namen wie der Quell-Namespace.
2
Quell-Namespace, der einem Ziel-Namespace mit einem anderen Namen zugeordnet ist.

12.2.2. DirectImageStreamMigration

Die CR DirectImageStreamMigration kopiert Image Stream-Referenzen direkt vom Quell-Cluster zum Ziel-Cluster.

apiVersion: migration.openshift.io/v1alpha1
kind: DirectImageStreamMigration
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: <direct_image_stream_migration>
spec:
  srcMigClusterRef:
    name: <source_cluster>
    namespace: openshift-migration
  destMigClusterRef:
    name: <destination_cluster>
    namespace: openshift-migration
  imageStreamRef:
    name: <image_stream>
    namespace: <source_image_stream_namespace>
  destNamespace: <destination_image_stream_namespace>

12.2.3. DirectVolumeMigration

Die CR DirectVolumeMigration kopiert Persistent Volumes (PVs) direkt vom Quell-Cluster auf den Ziel-Cluster.

apiVersion: migration.openshift.io/v1alpha1
kind: DirectVolumeMigration
metadata:
  name: <direct_volume_migration>
  namespace: openshift-migration
spec:
  createDestinationNamespaces: false 1
  deleteProgressReportingCRs: false 2
  destMigClusterRef:
    name: <host_cluster> 3
    namespace: openshift-migration
  persistentVolumeClaims:
  - name: <pvc> 4
    namespace: <pvc_namespace>
  srcMigClusterRef:
    name: <source_cluster>
    namespace: openshift-migration
1
Legen Sie diesen Wert auf true fest, um Namespaces für die PVs auf dem Ziel-Cluster zu erstellen.
2
Legen Sie diesen Wert auf true fest, um DirectVolumeMigrationProgress-CRs nach der Migration zu löschen. Der Standardwert ist false, damit DirectVolumeMigrationProgress-CRs zur Fehlerbehebung beibehalten werden.
3
Aktualisieren Sie den Clusternamen, wenn der Ziel-Cluster nicht der Host-Cluster ist.
4
Geben Sie einen oder mehrere PVCs an, die migriert werden sollen.

12.2.4. DirectVolumeMigrationProgress

Die CR DirectVolumeMigrationProgress zeigt den Fortschritt der CR DirectVolumeMigration an.

apiVersion: migration.openshift.io/v1alpha1
kind: DirectVolumeMigrationProgress
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: <direct_volume_migration_progress>
spec:
  clusterRef:
    name: <source_cluster>
    namespace: openshift-migration
  podRef:
    name: <rsync_pod>
    namespace: openshift-migration

12.2.5. MigAnalytic

Die CR MigAnalytic erfasst die Anzahl der Images, Kubernetes-Ressourcen und die Kapazität des Persistent Volume (PV) von einer zugehörigen MigPlan-CR.

Sie können die gesammelten Daten konfigurieren.

apiVersion: migration.openshift.io/v1alpha1
kind: MigAnalytic
metadata:
  annotations:
    migplan: <migplan>
  name: <miganalytic>
  namespace: openshift-migration
  labels:
    migplan: <migplan>
spec:
  analyzeImageCount: true 1
  analyzeK8SResources: true 2
  analyzePVCapacity: true 3
  listImages: false 4
  listImagesLimit: 50 5
  migPlanRef:
    name: <migplan>
    namespace: openshift-migration
1
Optional: Gibt die Anzahl der Images zurück.
2
Optional: Gibt die Nummer, Art und API-Version der Kubernetes-Ressourcen zurück.
3
Optional: Gibt die PV-Kapazität zurück.
4
Gibt eine Liste von Image-Namen zurück. Der Standardwert ist false, damit die Ausgabe nicht zu lang ist.
5
Optional: Geben Sie die maximale Anzahl der Image-Namen an, die zurückgegeben werden sollen, wenn listImages = true ist.

12.2.6. MigCluster

Die CR MigCluster definiert einen Host-, einen lokalen oder einen Remote-Cluster.

apiVersion: migration.openshift.io/v1alpha1
kind: MigCluster
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: <host_cluster> 1
  namespace: openshift-migration
spec:
  isHostCluster: true 2
# The 'azureResourceGroup' parameter is relevant only for Microsoft Azure.
  azureResourceGroup: <azure_resource_group> 3
  caBundle: <ca_bundle_base64> 4
  insecure: false 5
  refresh: false 6
# The 'restartRestic' parameter is relevant for a source cluster.
  restartRestic: true 7
# The following parameters are relevant for a remote cluster.
  exposedRegistryPath: <registry_route> 8
  url: <destination_cluster_url> 9
  serviceAccountSecretRef:
    name: <source_secret> 10
    namespace: openshift-config
1
Aktualisieren Sie den Clusternamen, falls der Pod migration-controller nicht auf diesem Cluster ausgeführt wird.
2
Der Pod migration-controller wird auf diesem Cluster ausgeführt, wenn der Wert true ist.
3
Nur bei Microsoft Azure: Geben Sie die Ressourcengruppe an.
4
Optional: Wenn Sie ein Zertifikatpaket für selbstsignierte CA-Zertifikate erstellt haben und der Parameter insecure den Wert false hat, geben Sie das base64-kodierte Zertifikatpaket an.
5
Legen Sie diesen Wert auf true fest, um die SSL-Verifizierung zu deaktivieren.
6
Legen Sie diesen Wert auf true fest, um den Cluster zu validieren.
7
Legen Sie diesen Wert auf true fest, um die Restic-Pods auf dem Quell-Cluster neu zu starten, nachdem die Stage-Pods erstellt wurden.
8
Nur für Remote-Cluster und Direct Image Migration: Geben Sie den zugänglichen sicheren Registrierungspfad an.
9
Nur für Remote-Cluster: Geben Sie die URL an.
10
Nur für Remote-Cluster: Geben Sie den Namen des Objekts Secret an.

12.2.7. MigHook

Die CR MigHook definiert einen Hook für die Migration, der benutzerdefinierten Code in einer angegebenen Phase der Migration ausführt. Sie können bis zu vier Hooks für die Migration erstellen. Jeder Hook wird während einer anderen Phase der Migration ausgeführt.

Sie können den Hook-Namen, die Laufzeit, ein benutzerdefiniertes Image und den Cluster, in dem der Hook ausgeführt wird, konfigurieren.

Die Migrationsphasen und Namespaces der Hook werden in der CR MigPlan konfiguriert.

apiVersion: migration.openshift.io/v1alpha1
kind: MigHook
metadata:
  generateName: <hook_name_prefix> 1
  name: <mighook> 2
  namespace: openshift-migration
spec:
  activeDeadlineSeconds: 1800 3
  custom: false 4
  image: <hook_image> 5
  playbook: <ansible_playbook_base64> 6
  targetCluster: source 7
1
Optional: An den Wert dieses Parameters wird ein eindeutiger Hash angehängt, damit jeder Hook für die Migration einen eindeutigen Namen hat. Sie müssen den Wert des Parameters name nicht angeben.
2
Geben Sie den Namen des Hook für die Migration an, falls Sie den Wert des Parameters generateName nicht angeben.
3
Optional: Geben Sie die maximale Anzahl von Sekunden an, die ein Hook ausgeführt werden soll. Der Standardwert ist 1800.
4
Der Hook ist ein benutzerdefiniertes Image, wenn der Wert auf true festgelegt wird. Das benutzerdefinierte Image kann Ansible enthalten oder in einer anderen Programmiersprache geschrieben sein.
5
Geben Sie das benutzerdefinierte Image an. Zum Beispiel: quay.io/konveyor/hook-runner:latest. Erforderlich, wenn custom =true ist.
6
Base64-kodiertes Ansible-Playbook. Erforderlich, wenn custom = false ist.
7
Geben Sie den Cluster an, in dem der Hook ausgeführt werden soll. Gültige Werte sind source oder destination.

12.2.8. MigMigration

Die CR MigMigration führt eine CR MigPlan aus.

Sie können eine Migmigration-CR konfigurieren, um eine Stage- oder schrittweise Migration durchzuführen, eine laufende Migration abzubrechen oder eine abgeschlossene Migration zurückzusetzen.

apiVersion: migration.openshift.io/v1alpha1
kind: MigMigration
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: <migmigration>
  namespace: openshift-migration
spec:
  canceled: false 1
  rollback: false 2
  stage: false 3
  quiescePods: true 4
  keepAnnotations: true 5
  verify: false 6
  migPlanRef:
    name: <migplan>
    namespace: openshift-migration
1
Legen Sie Sie diesen Wert auf true fest, um eine laufende Migration abzubrechen.
2
Legen Sie diesen Wert auf true fest, um eine abgeschlossene Migration zurückzusetzen.
3
Legen Sie diesen Wert auf true fest, um eine Stage-Migration durchzuführen. Die Daten werden schrittweise kopiert und die Pods auf dem Quell-Cluster nicht angehalten.
4
Legen Sie diesen Wert auf true fest, um die Anwendung während der Migration anzuhalten. Die Pods auf dem Quell-Cluster werden nach der Phase Backup auf 0 skaliert.
5
Legen Sie diesen Wert auf true fest, um die während der Migration angewendeten Bezeichnungen und Annotationen beizubehalten.
6
Legen Sie diesen Wert auf true fest, um den Status der migrierten Pods auf dem Ziel-Cluster zu überprüfen und die Namen der Pods zurückzugeben, die sich nicht im Status Running befinden.

12.2.9. MigPlan

Die CR MigPlan definiert die Parameter eines Migrationsplans.

Sie können Ziel-Namespaces, Hook-Phasen und direkte oder indirekte Migrationen konfigurieren.

Anmerkung

Standardmäßig hat ein Ziel-Namespace denselben Namen wie der Quell-Namespace. Wenn Sie einen abweichenden Ziel-Namespace konfigurieren, müssen Sie sicherstellen, dass die Namespaces weder auf dem Quell- noch auf dem Ziel-Cluster dupliziert werden, da die UID- und GID-Bereiche während der Migration kopiert werden.

apiVersion: migration.openshift.io/v1alpha1
kind: MigPlan
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: <migplan>
  namespace: openshift-migration
spec:
  closed: false 1
  srcMigClusterRef:
    name: <source_cluster>
    namespace: openshift-migration
  destMigClusterRef:
    name: <destination_cluster>
    namespace: openshift-migration
  hooks: 2
    - executionNamespace: <namespace> 3
      phase: <migration_phase> 4
      reference:
        name: <hook> 5
        namespace: <hook_namespace> 6
      serviceAccount: <service_account> 7
  indirectImageMigration: true 8
  indirectVolumeMigration: false 9
  migStorageRef:
    name: <migstorage>
    namespace: openshift-migration
  namespaces:
    - <source_namespace_1> 10
    - <source_namespace_2>
    - <source_namespace_3>:<destination_namespace_4> 11
  refresh: false  12
1
Die Migration ist abgeschlossen, wenn der Wert true ist. Sie können keine weitere MigMigration-CR für diese MigPlan-CR erstellen.
2
Optional: Sie können bis zu vier Hooks für die Migration angeben. Jeder Hook muss während einer anderen Migrationsphase ausgeführt werden.
3
Optional: Geben Sie den Namespace an, in dem der Hook ausgeführt werden soll.
4
Optional: Geben Sie die Migrationsphase an, während der ein Hook ausgeführt wird. Ein Hook kann einer Phase zugewiesen werden. Gültige Werte sind PreBackup, PostBackup, PreRestore und PostRestore.
5
Optional: Geben Sie den Namen der CR MigHook an.
6
Optional: Geben Sie den Namespace der CR MigHook an.
7
Optional: Geben Sie einen Service Account mit cluster-admin-Privilegien an.
8
Wenn true, ist die Direct Image Migration deaktiviert. Images werden vom Quell-Cluster in das Replikations-Repository und vom Replikations-Repository in den Ziel-Cluster kopiert.
9
Direct Volume Migration ist deaktiviert, wenn true. PVs werden vom Quell-Cluster in das Replikations-Repository und vom Replikations-Repository in den Ziel-Cluster kopiert.
10
Geben Sie einen oder mehrere Quell-Namespaces an. Wenn Sie nur den Quell-Namespace angeben, ist der Ziel-Namespace derselbe.
11
Geben Sie den Ziel-Namespace an, wenn er sich vom Quell-Namespace unterscheidet.
12
Die CR MigPlan wird validiert, wenn sie true ist.

12.2.10. MigStorage

Die CR MigStorage beschreibt den Objektspeicher für das Replikations-Repository.

Amazon Web Services (AWS), Microsoft Azure, Google Cloud Storage, Multi-Cloud Object Gateway und allgemeiner S3-kompatibler Cloud-Speicher werden unterstützt.

AWS und die Schnappschuss-Kopiermethode haben zusätzliche Parameter.

apiVersion: migration.openshift.io/v1alpha1
kind: MigStorage
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: <migstorage>
  namespace: openshift-migration
spec:
  backupStorageProvider: <backup_storage_provider> 1
  volumeSnapshotProvider: <snapshot_storage_provider> 2
  backupStorageConfig:
    awsBucketName: <bucket> 3
    awsRegion: <region> 4
    credsSecretRef:
      namespace: openshift-config
      name: <storage_secret> 5
    awsKmsKeyId: <key_id> 6
    awsPublicUrl: <public_url> 7
    awsSignatureVersion: <signature_version> 8
  volumeSnapshotConfig:
    awsRegion: <region> 9
    credsSecretRef:
      namespace: openshift-config
      name: <storage_secret> 10
  refresh: false 11
1
Geben Sie den Speicheranbieter an.
2
Nur bei der Schnappschuss-Kopiermethode: Geben Sie den Speicheranbieter an.
3
Nur bei AWS: Geben Sie den Bucket-Namen an.
4
Nur bei AWS: Geben Sie die Bucket-Region an, z. B. us-east-1.
5
Geben Sie den Namen des Objekts Secret an, das Sie für den Speicher erstellt haben.
6
Nur für AWS: Wenn Sie den AWS Key Management Service verwenden, geben Sie die eindeutige Kennung des Schlüssels an.
7
Nur für AWS: Wenn Sie öffentlichen Zugriff auf den AWS-Bucket gewährt haben, geben Sie die Bucket-URL an.
8
Nur AWS: Geben Sie die AWS-Signaturversion für die Authentifizierung von Anfragen an den Bucket an, z. B. 4.
9
Nur für die Schnappschuss-Kopiermethode: Geben Sie die geografische Region des Clusters an.
10
Nur für die Schnappschuss-Kopiermethode: Geben Sie den Namen des Objekts Secret an, das Sie für den Speicher erstellt haben.
11
Legen Sie diesen Wert auf true fest, um den Cluster zu validieren.

12.3. Protokolle und Debugging-Tools

In diesem Abschnitt werden Protokolle und Debugging-Tools beschrieben, die Sie zur Problembehandlung verwenden können.

12.3.1. Anzeigen der Ressourcen des Migrationsplans

Über die MTC-Webkonsole und die Command Line Interface (CLI) können Sie die Ressourcen des Migrationsplans anzeigen, um eine laufende Migration zu überwachen oder Probleme bei einer fehlgeschlagenen Migration zu beheben.

Vorgehensweise

  1. Klicken Sie in der MTC-Webkonsole auf Migration Plans.
  2. Klicken Sie auf Migrations (Zahl) neben einem Migrationsplan, um die Seite Migrations anzuzeigen.
  3. Klicken Sie auf eine Migration, um Migration details anzuzeigen.
  4. Erweitern Sie Migration resources, um die Migrationsressourcen und ihren Status in einer Strukturansicht anzuzeigen.

    Anmerkung

    Um die Probleme einer fehlgeschlagenen Migration zu beheben, beginnen Sie mit einer allgemeinen Ressource, bei der ein Fehler aufgetreten ist, und arbeiten sich dann in der Ressourcenstruktur zu den untergeordneten Ressourcen vor.

  5. Klicken Sie auf das Optionsmenü kebab neben einer Ressource und wählen Sie eine der folgenden Optionen:

    • Der Befehl Copy oc describe kopiert den Befehl in Ihre Zwischenablage.

      • Melden Sie sich bei dem betreffenden Cluster an und führen Sie den Befehl aus.

        Die Bedingungen und Ereignisse der Ressource werden im YAML-Format angezeigt.

    • Der Befehl Copy oc logs kopiert den Befehl in Ihre Zwischenablage.

      • Melden Sie sich bei dem betreffenden Cluster an und führen Sie den Befehl aus.

        Wenn die Ressource das Filtern von Protokollen unterstützt, wird ein gefiltertes Protokoll angezeigt.

    • View JSON zeigt die Ressourcendaten im JSON-Format in einem Webbrowser an.

      Die Daten sind identisch mit der Ausgabe des Befehls oc get <resource>.

12.3.2. Anzeige eines Protokolls für einen Migrationsplan

Sie können ein aggregiertes Protokoll für einen Migrationsplan anzeigen. Sie können die MTC-Webkonsole verwenden, um einen Befehl in die Zwischenablage zu kopieren und dann den Befehl über die Command Line Interface (CLI) auszuführen.

Der Befehl zeigt die gefilterten Protokolle der folgenden Pods an:

  • Migration Controller
  • Velero
  • Restic
  • Rsync
  • Stunnel
  • Registry

Vorgehensweise

  1. Klicken Sie in der MTC-Webkonsole auf Migration Plans.
  2. Klicken Sie auf Migrations (Zahl) neben einem Migrationsplan.
  3. Klicken Sie auf View logs.
  4. Klicken Sie auf das Kopiersymbol, um den Befehl oc logs in Ihre Zwischenablage zu kopieren.
  5. Melden Sie sich bei dem betreffenden Cluster an und geben Sie den Befehl über die CLI ein.

    Das aggregierte Protokoll für den Migrationsplan wird angezeigt.

12.3.3. Verwendung des Lesers für Migrationsprotokolle

Sie können den Leser für Migrationsprotokolle verwenden, um eine gefilterte Ansicht aller Migrationsprotokolle anzuzeigen.

Vorgehensweise

  1. Rufen Sie den Pod mig-log-reader ab:

    $ oc -n openshift-migration get pods | grep log
  2. Geben Sie den folgenden Befehl ein, um ein einzelnes Migrationsprotokoll anzuzeigen:

    $ oc -n openshift-migration logs -f <mig-log-reader-pod> -c color 1
    1
    Die Option -c plain zeigt das Protokoll ohne Farben an.

12.3.4. Zugriff auf Leistungsmetriken

Die Custom Resource (CR) MigrationController zeichnet Metriken auf und speichert sie im Überwachungsspeicher des Clusters. Sie können die Metriken mit der Prometheus Query Language (PromQL) abfragen, um Probleme mit der Migrationsleistung zu diagnostizieren. Alle Metriken werden zurückgesetzt, wenn der Pod „Migration Controller“ neu gestartet wird.

Sie können über die Webkonsole der OpenShift Container Platform auf die Leistungsmetriken zugreifen und Abfragen durchführen.

Vorgehensweise

  1. Klicken Sie in der Webkonsole der OpenShift Container Platform auf ObserveMetrics.
  2. Geben Sie eine PromQL-Abfrage ein, wählen Sie ein anzuzeigendes Zeitfenster und klicken Sie auf Run Queries.

    Wenn Ihr Webbrowser nicht alle Ergebnisse anzeigt, verwenden Sie die Prometheus-Konsole.

12.3.4.1. Bereitgestellte Metriken

Die Custom Ressource (CR) MigrationController liefert Metriken für die Anzahl der MigMigration-CRs und die dazugehörigen API-Anfragen.

12.3.4.1.1. cam_app_workload_migrations

Diese Metrik ist die Anzahl der MigMigration-CRs im Laufe der Zeit. Sie kann zusammen mit den Metriken mtc_client_request_count und mtc_client_request_elapsed angezeigt werden, um Informationen zu API-Anfragen mit Änderungen des Migrationsstatus abzugleichen. Diese Metrik ist in der Telemetrie enthalten.

Tabelle 12.1. Metrik „cam_app_workload_migrations“

Abfragbarer BezeichnungsnameBeispielwerte für BezeichnungenBeschreibung der Bezeichnung

status

running, idle, failed, completed

Status der CR MigMigration

type

stage, final

Typ der CR MigMigration

12.3.4.1.2. mtc_client_request_count

Bei dieser Metrik handelt es sich um eine kumulative Anzahl von Kubernetes-API-Anfragen, die von MigrationController ausgehen. Sie ist nicht in der Telemetrie enthalten.

Tabelle 12.2. Metrik mtc_client_request_count

Abfragbarer BezeichnungsnameBeispielwerte für BezeichnungenBeschreibung der Bezeichnung

cluster

https://migcluster-url:443

Cluster, an den die Anfrage gestellt wurde

component

MigPlan, MigCluster

Sub-Controller-API, die die Anfrage gestellt hat

function

(*ReconcileMigPlan).Reconcile

Funktion, von der aus die Anfrage gestellt wurde

kind

SecretList, Deployment

Kubernetes-Art, für die die Anfrage gestellt wurde

12.3.4.1.3. mtc_client_request_elapsed

Bei dieser Metrik handelt es sich um eine kumulative Latenz in Millisekunden von Kubernetes-API-Anfragen, die von MigrationController ausgehen. Sie ist nicht in der Telemetrie enthalten.

Tabelle 12.3. Metrik mtc_client_request_elapsed

Abfragbarer BezeichnungsnameBeispielwerte für BezeichnungenBeschreibung der Bezeichnung

cluster

https://cluster-url.com:443

Cluster, an den die Anfrage gestellt wurde

component

migplan, migcluster

Sub-Controller-API, die die Anfrage gestellt hat

function

(*ReconcileMigPlan).Reconcile

Funktion, von der aus die Anfrage gestellt wurde

kind

SecretList, Deployment

Kubernetes-Ressource, für die die Anfrage gestellt wurde

12.3.4.1.4. Nützliche Abfragen

In der Tabelle sind einige hilfreiche Abfragen aufgeführt, die für die Leistungsüberwachung verwendet werden können.

Tabelle 12.4. Nützliche Abfragen

AbfrageBeschreibung

mtc_client_request_count

Anzahl der gestellten API-Anfragen, sortiert nach Anfragetyp

sum(mtc_client_request_count)

Gesamtzahl der ausgehenden API-Anfragen

mtc_client_request_elapsed

Latenz für API-Anfragen, sortiert nach Anfragetyp

sum(mtc_client_request_elapsed)

Gesamtlatenz der API-Anfragen

sum(mtc_client_request_elapsed) / sum(mtc_client_request_count)

Durchschnittliche Latenz der API-Anfragen

mtc_client_request_elapsed / mtc_client_request_count

Durchschnittliche Latenz der API-Anfragen, sortiert nach Anfragetyp

cam_app_workload_migrations{status="running"} * 100

Anzahl der ausgeführten Migrationen, multipliziert mit 100 zur besseren Übersicht neben der Anzahl der Anfragen

12.3.5. Verwendung des Tools „must-gather“

Sie können Protokolle, Metriken und Informationen über benutzerdefinierte MTC-Ressourcen mit dem Tool must-gather sammeln.

Die must-gather-Daten müssen allen Kundenfällen beigefügt werden.

Sie können Daten für einen Zeitraum von einer Stunde oder von 24 Stunden sammeln und die Daten mit der Prometheus-Konsole anzeigen.

Voraussetzungen

  • Sie müssen am OpenShift Container Platform-Cluster als Benutzer mit der Rolle cluster-admin angemeldet sein.
  • Sie müssen die OpenShift CLI (oc) installiert haben.

Vorgehensweise

  1. Navigieren Sie zu dem Verzeichnis, in dem Sie die must-gather-Daten speichern möchten.
  2. Führen Sie den Befehl oc adm must-gather für eine der folgenden Datensammlungsoptionen aus:

    • So sammeln Sie die Daten der letzten Stunde:

      $ oc adm must-gather --image=registry.redhat.io/rhmtc/openshift-migration-must-gather-rhel8:v1.6

      Die Daten werden als must-gather/must-gather.tar.gz gespeichert. Sie können diese Datei in einen Support-Fall im Red Hat Customer Portal hochladen.

    • So sammeln Sie die Daten der letzten 24 Stunden:

      $ oc adm must-gather --image=registry.redhat.io/rhmtc/openshift-migration-must-gather-rhel8:v1.6 \
        -- /usr/bin/gather_metrics_dump

      Dieser Vorgang kann viel Zeit in Anspruch nehmen. Die Daten werden als must-gather/metrics/prom_data.tar.gz gespeichert.

Anzeigen von Metrikdaten mit der Prometheus-Konsole

Sie können die Metrikdaten über die Prometheus-Konsole anzeigen.

Vorgehensweise

  1. Dekomprimieren Sie die Datei prom_data.tar.gz:

    $ tar -xvzf must-gather/metrics/prom_data.tar.gz
  2. Erstellen Sie eine lokale Prometheus-Instanz:

    $ make prometheus-run

    Der Befehl gibt die Prometheus-URL aus.

    Ausgabe

    Started Prometheus on http://localhost:9090

  3. Starten Sie einen Webbrowser und navigieren Sie zu der URL, um die Daten mithilfe der Prometheus-Webkonsole anzuzeigen.
  4. Nachdem Sie die Daten angesehen haben, löschen Sie die Prometheus-Instanz und die Daten:

    $ make prometheus-cleanup

12.3.6. Debuggen von Velero-Ressourcen mit dem CLI-Tool von Velero

Mit dem CLI-Tool von Velero können Sie die Custom Resources (CRs) backup und restore debuggen sowie Protokolle abrufen.

Das CLI-Tool von Velero liefert detailliertere Informationen als das von OpenShift.

Syntax

Verwenden Sie den Befehl oc exec, um einen Velero-CLI-Befehl auszuführen:

$ oc exec $(oc get pods -n openshift-migration -o name | grep velero) \
  -- ./velero <backup_restore_cr> <command> <cr_name>

Beispiel

$ oc exec $(oc get pods -n openshift-migration -o name | grep velero) \
  -- ./velero backup describe 0e44ae00-5dc3-11eb-9ca8-df7e5254778b-2d8ql

Sie können velero-<pod> -n openshift-migration anstelle von $(oc get pods -n openshift-migration -o name | grep velero) angeben.

Beispiel

$ oc exec velero-<pod> -n openshift-migration -- ./velero backup describe 0e44ae00-5dc3-11eb-9ca8-df7e5254778b-2d8ql

Option „help“

Verwenden Sie die Option velero --help, um alle Velero-CLI-Befehle aufzulisten:

$ oc exec $(oc get pods -n openshift-migration -o name | grep velero) -- ./velero --help
Befehl „describe“

Verwenden Sie den Befehl velero describe, um eine Zusammenfassung der Warnungen und Fehler im Zusammenhang mit einer Backup- oder Restore-CR abzurufen:

$ oc exec $(oc get pods -n openshift-migration -o name | grep velero) \
  -- ./velero <backup_restore_cr> describe <cr_name>

Beispiel

$ oc exec $(oc get pods -n openshift-migration -o name | grep velero) \
  -- ./velero backup describe 0e44ae00-5dc3-11eb-9ca8-df7e5254778b-2d8ql

Befehl „logs“

Verwenden Sie den Befehl velero logs, um die Protokolle einer Backup- oder Restore-CR abzurufen:

$ oc exec $(oc get pods -n openshift-migration -o name | grep velero) \
  -- ./velero <backup_restore_cr> logs <cr_name>

Beispiel

$ oc exec $(oc get pods -n openshift-migration -o name | grep velero) \
  -- ./velero restore logs ccc7c2d0-6017-11eb-afab-85d0007f5a19-x4lbf

12.3.7. Debuggen einer teilweisen fehlgeschlagenen Migration

Sie können eine Warnmeldung über eine teilweise fehlgeschlagene Migration debuggen, indem Sie die Velero-CLI verwenden, um die Protokolle der Custom Resource (CR) restore zu untersuchen.

Ein Teilfehler tritt auf, wenn bei Velero ein Problem auftritt, das nicht zum Scheitern einer Migration führt. Wenn beispielsweise eine Custom Resource Definition (CRD) fehlt oder eine Diskrepanz zwischen den CRD-Versionen auf dem Quell- und dem Ziel-Cluster besteht, wird die Migration zwar abgeschlossen, aber die CR wird nicht auf dem Ziel-Cluster erstellt.

Velero protokolliert das Problem als Teilfehler und verarbeitet dann die restlichen Objekte in der CR Backup.

Vorgehensweise

  1. Prüfen Sie den Status einer MigMigration-CR:

    $ oc get migmigration <migmigration> -o yaml

    Beispielausgabe

    status:
      conditions:
      - category: Warn
        durable: true
        lastTransitionTime: "2021-01-26T20:48:40Z"
        message: 'Final Restore openshift-migration/ccc7c2d0-6017-11eb-afab-85d0007f5a19-x4lbf: partially failed on destination cluster'
        status: "True"
        type: VeleroFinalRestorePartiallyFailed
      - category: Advisory
        durable: true
        lastTransitionTime: "2021-01-26T20:48:42Z"
        message: The migration has completed with warnings, please look at `Warn` conditions.
        reason: Completed
        status: "True"
        type: SucceededWithWarnings

  2. Überprüfen Sie den Status der CR Restore mit dem Velero-Befehl describe:

    $ oc exec $(oc get pods -n openshift-migration -o name | grep velero) -n openshift-migration -- ./velero restore describe <restore>

    Beispielausgabe

    Phase:  PartiallyFailed (run 'velero restore logs ccc7c2d0-6017-11eb-afab-85d0007f5a19-x4lbf' for more information)
    
    Errors:
      Velero:     <none>
      Cluster:    <none>
      Namespaces:
        migration-example:  error restoring example.com/migration-example/migration-example: the server could not find the requested resource

  3. Überprüfen Sie die Protokolle der CR Restore mit dem Velero-Befehl logs:

    $ oc exec $(oc get pods -n openshift-migration -o name | grep velero) -n openshift-migration -- ./velero restore logs <restore>

    Beispielausgabe

    time="2021-01-26T20:48:37Z" level=info msg="Attempting to restore migration-example: migration-example" logSource="pkg/restore/restore.go:1107" restore=openshift-migration/ccc7c2d0-6017-11eb-afab-85d0007f5a19-x4lbf
    time="2021-01-26T20:48:37Z" level=info msg="error restoring migration-example: the server could not find the requested resource" logSource="pkg/restore/restore.go:1170" restore=openshift-migration/ccc7c2d0-6017-11eb-afab-85d0007f5a19-x4lbf

    Die Protokoll-Fehlermeldung der CR Restore, the server could not find the requested resource, gibt die Ursache für die teilweise fehlgeschlagene Migration an.

12.3.8. Verwendung benutzerdefinierter MTC-Ressourcen für die Problembehandlung

Sie können die folgenden Custom Resources (CRs) des Migration Toolkit for Containers (MTC) überprüfen, um Probleme bei einer fehlgeschlagenen Migration zu beheben:

  • MigCluster
  • MigStorage
  • MigPlan
  • BackupStorageLocation

    Die CR BackupStorageLocation enthält die Bezeichnung migrationcontroller zur Identifizierung der MTC-Instanz, die die CR erstellt hat:

        labels:
          migrationcontroller: ebe13bee-c803-47d0-a9e9-83f380328b93
  • VolumeSnapshotLocation

    Die CR VolumeSnapshotLocation enthält die Bezeichnung migrationcontroller zur Identifizierung der MTC-Instanz, die die CR erstellt hat:

        labels:
          migrationcontroller: ebe13bee-c803-47d0-a9e9-83f380328b93
  • MigMigration
  • Backup

    MTC ändert die Rückforderungsrichtlinie für migrierte Persistent Volumes (PVs) auf dem Ziel-Cluster in Retain. Die CR Backup enthält die Annotation openshift.io/orig-reclaim-policy, die die ursprüngliche Rückforderungsrichtlinie angibt. Sie können die Rückforderungsrichtlinie für die migrierten PVs manuell wiederherstellen.

  • Restore

Vorgehensweise

  1. Liste der MigMigration-CRs im Namespace openshift-migration:

    $ oc get migmigration -n openshift-migration

    Beispielausgabe

    NAME                                   AGE
    88435fe0-c9f8-11e9-85e6-5d593ce65e10   6m42s

  2. Überprüfen Sie die CR MigMigration:

    $ oc describe migmigration 88435fe0-c9f8-11e9-85e6-5d593ce65e10 -n openshift-migration

    Die Ausgabe ist sieht so ähnlich wie die folgenden Beispiele aus.

Beispielausgabe für MigMigration

name:         88435fe0-c9f8-11e9-85e6-5d593ce65e10
namespace:    openshift-migration
labels:       <none>
annotations:  touch: 3b48b543-b53e-4e44-9d34-33563f0f8147
apiVersion:  migration.openshift.io/v1alpha1
kind:         MigMigration
metadata:
  creationTimestamp:  2019-08-29T01:01:29Z
  generation:          20
  resourceVersion:    88179
  selfLink:           /apis/migration.openshift.io/v1alpha1/namespaces/openshift-migration/migmigrations/88435fe0-c9f8-11e9-85e6-5d593ce65e10
  uid:                 8886de4c-c9f8-11e9-95ad-0205fe66cbb6
spec:
  migPlanRef:
    name:        socks-shop-mig-plan
    namespace:   openshift-migration
  quiescePods:  true
  stage:         false
status:
  conditions:
    category:              Advisory
    durable:               True
    lastTransitionTime:  2019-08-29T01:03:40Z
    message:               The migration has completed successfully.
    reason:                Completed
    status:                True
    type:                  Succeeded
  phase:                   Completed
  startTimestamp:         2019-08-29T01:01:29Z
events:                    <none>

Beispielausgabe für Backup-CR 2 Velero, die die PV-Daten beschreibt

apiVersion: velero.io/v1
kind: Backup
metadata:
  annotations:
    openshift.io/migrate-copy-phase: final
    openshift.io/migrate-quiesce-pods: "true"
    openshift.io/migration-registry: 172.30.105.179:5000
    openshift.io/migration-registry-dir: /socks-shop-mig-plan-registry-44dd3bd5-c9f8-11e9-95ad-0205fe66cbb6
    openshift.io/orig-reclaim-policy: delete
  creationTimestamp: "2019-08-29T01:03:15Z"
  generateName: 88435fe0-c9f8-11e9-85e6-5d593ce65e10-
  generation: 1
  labels:
    app.kubernetes.io/part-of: migration
    migmigration: 8886de4c-c9f8-11e9-95ad-0205fe66cbb6
    migration-stage-backup: 8886de4c-c9f8-11e9-95ad-0205fe66cbb6
    velero.io/storage-location: myrepo-vpzq9
  name: 88435fe0-c9f8-11e9-85e6-5d593ce65e10-59gb7
  namespace: openshift-migration
  resourceVersion: "87313"
  selfLink: /apis/velero.io/v1/namespaces/openshift-migration/backups/88435fe0-c9f8-11e9-85e6-5d593ce65e10-59gb7
  uid: c80dbbc0-c9f8-11e9-95ad-0205fe66cbb6
spec:
  excludedNamespaces: []
  excludedResources: []
  hooks:
    resources: []
  includeClusterResources: null
  includedNamespaces:
  - sock-shop
  includedResources:
  - persistentvolumes
  - persistentvolumeclaims
  - namespaces
  - imagestreams
  - imagestreamtags
  - secrets
  - configmaps
  - pods
  labelSelector:
    matchLabels:
      migration-included-stage-backup: 8886de4c-c9f8-11e9-95ad-0205fe66cbb6
  storageLocation: myrepo-vpzq9
  ttl: 720h0m0s
  volumeSnapshotLocations:
  - myrepo-wv6fx
status:
  completionTimestamp: "2019-08-29T01:02:36Z"
  errors: 0
  expiration: "2019-09-28T01:02:35Z"
  phase: Completed
  startTimestamp: "2019-08-29T01:02:35Z"
  validationErrors: null
  version: 1
  volumeSnapshotsAttempted: 0
  volumeSnapshotsCompleted: 0
  warnings: 0

Beispielausgabe für Restore-CR 2 Velero, die die Kubernetes-Ressourcen beschreibt

apiVersion: velero.io/v1
kind: Restore
metadata:
  annotations:
    openshift.io/migrate-copy-phase: final
    openshift.io/migrate-quiesce-pods: "true"
    openshift.io/migration-registry: 172.30.90.187:5000
    openshift.io/migration-registry-dir: /socks-shop-mig-plan-registry-36f54ca7-c925-11e9-825a-06fa9fb68c88
  creationTimestamp: "2019-08-28T00:09:49Z"
  generateName: e13a1b60-c927-11e9-9555-d129df7f3b96-
  generation: 3
  labels:
    app.kubernetes.io/part-of: migration
    migmigration: e18252c9-c927-11e9-825a-06fa9fb68c88
    migration-final-restore: e18252c9-c927-11e9-825a-06fa9fb68c88
  name: e13a1b60-c927-11e9-9555-d129df7f3b96-gb8nx
  namespace: openshift-migration
  resourceVersion: "82329"
  selfLink: /apis/velero.io/v1/namespaces/openshift-migration/restores/e13a1b60-c927-11e9-9555-d129df7f3b96-gb8nx
  uid: 26983ec0-c928-11e9-825a-06fa9fb68c88
spec:
  backupName: e13a1b60-c927-11e9-9555-d129df7f3b96-sz24f
  excludedNamespaces: null
  excludedResources:
  - nodes
  - events
  - events.events.k8s.io
  - backups.velero.io
  - restores.velero.io
  - resticrepositories.velero.io
  includedNamespaces: null
  includedResources: null
  namespaceMapping: null
  restorePVs: true
status:
  errors: 0
  failureReason: ""
  phase: Completed
  validationErrors: null
  warnings: 15

12.4. Häufige Probleme und Schwierigkeiten

In diesem Abschnitt werden häufige Probleme und Schwierigkeiten beschrieben, die während der Migration auftreten können.

12.4.1. Aktualisieren veralteter interner Images

Wenn Ihre Anwendung Images aus dem Namespace openshift verwendet, müssen die erforderlichen Versionen der Images auf dem Ziel-Cluster vorhanden sein.

Wenn ein Image von OpenShift Container Platform 3 in OpenShift Container Platform 4.10 veraltet ist, können Sie das Image Stream-Tag manuell aktualisieren, indem Sie podman verwenden.

Voraussetzungen

  • Sie müssen podman installiert haben.
  • Sie müssen als Benutzer mit cluster-admin-Privilegien angemeldet sein.
  • Wenn Sie unsichere Registrierungen verwenden, fügen Sie die Werte Ihres Registrierungshosts in den Abschnitt [registries.insecure] von /etc/container/registries.conf ein, um sicherzustellen, dass podman keinen TLS-Verifizierungsfehler erhält.
  • Die internen Registrierungen müssen auf den Quell- und Ziel-Clustern zugänglich gemacht werden.

Vorgehensweise

  1. Stellen Sie sicher, dass die internen Registrierungen auf den Clustern von OpenShift Container Platform 3 und 4 zugänglich sind.

    Die interne Registrierung ist auf OpenShift Container Platform 4 standardmäßig zugänglich.

  2. Wenn Sie unsichere Registrierungen verwenden, fügen Sie die Werte Ihres Registrierungshosts in den Abschnitt [registries.insecure] von /etc/container/registries.conf ein, um sicherzustellen, dass podman keinen TLS-Verifizierungsfehler erhält.
  3. Melden Sie sich bei der OpenShift Container Platform 3-Registrierung an:

    $ podman login -u $(oc whoami) -p $(oc whoami -t) --tls-verify=false <registry_url>:<port>
  4. Melden Sie sich bei der OpenShift Container Platform 4-Registrierung an:

    $ podman login -u $(oc whoami) -p $(oc whoami -t) --tls-verify=false <registry_url>:<port>
  5. Rufen Sie das OpenShift Container Platform 3-Image ab:

    $ podman pull <registry_url>:<port>/openshift/<image>
  6. Taggen Sie das OpenShift Container Platform 3-Image für die OpenShift Container Platform 4-Registrierung:

    $ podman tag <registry_url>:<port>/openshift/<image> \ 1
      <registry_url>:<port>/openshift/<image> 2
    1
    Geben Sie die URL für die Registrierung und den Port für den OpenShift Container Platform 3-Cluster an.
    2
    Geben Sie die URL für die Registrierung und den Port für den OpenShift Container Platform 4-Cluster an.
  7. Übertragen Sie das Image in die OpenShift Container Platform 4-Registrierung:

    $ podman push <registry_url>:<port>/openshift/<image> 1
    1
    Geben Sie den OpenShift Container Platform 4-Cluster an.
  8. Überprüfen Sie, ob das Image einen gültigen Image Stream hat:

    $ oc get imagestream -n openshift | grep <image>

    Beispielausgabe

    NAME      IMAGE REPOSITORY                                                      TAGS    UPDATED
    my_image  image-registry.openshift-image-registry.svc:5000/openshift/my_image  latest  32 seconds ago

12.4.2. Direct Volume Migration wird nicht abgeschlossen

Wenn die Direct Volume Migration nicht abgeschlossen wird, hat der Ziel-Cluster möglicherweise nicht dieselben node-selector-Annotationen wie der Quell-Cluster.

Migration Toolkit for Containers (MTC) migriert Namespaces mit allen Annotationen, um Sicherheitskontextbeschränkungen und Planungsanforderungen zu erhalten. Bei der Direct Volume Migration erstellt MTC Rsync-Transfer-Pods auf dem Ziel-Cluster in den Namespaces, die vom Quell-Cluster migriert wurden. Wenn ein Ziel-Cluster-Namespace nicht dieselben Annotationen wie der Quell-Cluster-Namespace hat, können die Rsync-Transfer-Pods nicht geplant werden. Die Rsync-Pods bleiben im Status Pending.

Sie können dieses Problem mit dem folgenden Verfahren ermitteln und beheben.

Vorgehensweise

  1. Überprüfen Sie den Status der CR MigMigration:

    $ oc describe migmigration <pod> -n openshift-migration

    Die Ausgabe enthält die folgende Statusmeldung:

    Beispielausgabe

    Some or all transfer pods are not running for more than 10 mins on destination cluster

  2. Rufen Sie auf dem Quell-Cluster die Details eines migrierten Namespace ab:

    $ oc get namespace <namespace> -o yaml 1
    1
    Geben Sie den migrierten Namespace an.
  3. Bearbeiten Sie auf dem Ziel-Cluster den migrierten Namespace:

    $ oc edit namespace <namespace>
  4. Fügen Sie die fehlenden openshift.io/node-selector-Annotationen zum migrierten Namespace hinzu, wie im folgenden Beispiel:

    apiVersion: v1
    kind: Namespace
    metadata:
      annotations:
        openshift.io/node-selector: "region=east"
    ...
  5. Führen Sie den Migrationsplan erneut aus.

12.4.3. Fehlermeldungen und Lösungen

In diesem Abschnitt werden häufige Fehlermeldungen beschrieben, die im Zusammenhang mit dem Migration Toolkit for Containers (MTC) auftreten können, und es wird erläutert, wie Sie die zugrunde liegenden Ursachen beheben können.

12.4.3.1. Beim ersten Zugriff auf die MTC-Konsole wird „CA certificate error“ angezeigt

Wenn beim ersten Versuch, auf die MTC-Konsole zuzugreifen, CA certificate error angezeigt wird, ist die wahrscheinliche Ursache die Verwendung von selbstsignierten CA-Zertifikaten in einem der Cluster.

Um dieses Problem zu beheben, navigieren Sie zu der in der Fehlermeldung angezeigten URL oauth-authorization-server und akzeptieren Sie das Zertifikat. Um dieses Problem dauerhaft zu beheben, fügen Sie das Zertifikat den vertrauenswürdigen Zertifikaten Ihres Webbrowsers hinzu.

Wenn nach dem Akzeptieren des Zertifikats die Meldung Unauthorized angezeigt wird, navigieren Sie zur MTC-Konsole und aktualisieren Sie die Webseite.

12.4.3.2. OAuth-Zeitüberschreitungsfehler in der MTC-Konsole

Wenn nach dem Akzeptieren eines selbstsignierten Zertifikats in der MTC-Konsole die Meldung connection has timed out angezeigt wird, kann dies folgende Ursachen haben:

So ermitteln Sie die Ursache der Zeitüberschreitung:

  • Überprüfen Sie die Webseite der MTC-Konsole mit dem Webinspektor Ihres Browsers.
  • Überprüfen Sie das Protokoll des Pod Migration UI auf Fehler.

12.4.3.3. Fehlermeldung: „Certificate signed by unknown authority error“

Wenn Sie ein selbstsigniertes Zertifikat zum Sichern eines Clusters oder eines Replikations-Repositorys für das Migration Toolkit for Containers (MTC) verwenden, schlägt die Zertifikatsüberprüfung möglicherweise mit der folgenden Fehlermeldung fehl: Certificate signed by unknown authority.

Sie können eine benutzerdefinierte CA-Paketdatei mit Zertifikat erstellen und sie in der MTC-Webkonsole hochladen, wenn Sie einen Cluster oder ein Replikations-Repository hinzufügen.

Vorgehensweise

Laden Sie ein CA-Zertifikat von einem Remote-Endpunkt herunter und speichern Sie es als CA-Paketdatei:

$ echo -n | openssl s_client -connect <host_FQDN>:<port> \ 1
  | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > <ca_bundle.cert> 2
1
Geben Sie den FQDN des Hosts und den Port des Endpunkts an, z. B. api.my-cluster.example.com:6443.
2
Geben Sie den Namen der CA-Paketdatei an.

12.4.3.4. Backup Storage Location-Fehler im Protokoll des Pod „Velero“

Wenn die Custom Resource Velero Backup einen Verweis auf eine Backup Storage Location (BSL) enthält, die nicht existiert, zeigt das Protokoll des Pod Velero möglicherweise die folgenden Fehlermeldungen an:

$ oc logs <MigrationUI_Pod> -n openshift-migration

Sie können diese Fehlermeldungen ignorieren. Eine fehlende BSL kann nicht dazu führen, dass eine Migration fehlschlägt.

12.4.3.5. Zeitüberschreitungsfehler beim Backup des Pod-Volume im Protokoll des Pod „Velero“

Wenn eine Migration fehlschlägt, weil Restic eine Zeitüberschreitung verursacht, wird der folgende Fehler im Protokoll des Pod Velero angezeigt.

level=error msg="Error backing up item" backup=velero/monitoring error="timed out waiting for all PodVolumeBackups to complete" error.file="/go/src/github.com/heptio/velero/pkg/restic/backupper.go:165" error.function="github.com/heptio/velero/pkg/restic.(*backupper).BackupPodVolumes" group=v1

Der Standardwert für restic_timeout ist eine Stunde. Bei umfangreichen Migrationen können Sie diesen Parameter erhöhen, wobei zu beachten ist, dass ein höherer Wert die Rückgabe von Fehlermeldungen verzögern kann.

Vorgehensweise

  1. Navigieren Sie in der OpenShift Container Platform-Webkonsole zu OperatorsInstalled Operators.
  2. Klicken Sie auf Migration Toolkit for Containers Operator.
  3. Klicken Sie auf der Registerkarte MigrationController auf migration-controller.
  4. Aktualisieren Sie auf der Registerkarte YAML den folgenden Parameterwert:

    spec:
      restic_timeout: 1h 1
    1
    Gültige Einheiten sind h (Stunden), m (Minuten) und s (Sekunden) – zum Beispiel 3h30m15s.
  5. Klicken Sie auf Save.

12.4.3.6. Restic-Verifizierungsfehler in der Custom Resource „MigMigration“

Wenn die Datenverifizierung bei der Migration eines Persistent Volume mit der Dateisystem-Datenkopiermethode fehlschlägt, wird der folgende Fehler in der CR MigMigration angezeigt.

Beispielausgabe

status:
  conditions:
  - category: Warn
    durable: true
    lastTransitionTime: 2020-04-16T20:35:16Z
    message: There were verify errors found in 1 Restic volume restores. See restore `<registry-example-migration-rvwcm>`
      for details 1
    status: "True"
    type: ResticVerifyErrors 2

1
In der Fehlermeldung wird der Name der CR Restore angegeben.
2
ResticVerifyErrors ist ein allgemeiner Fehlerwarntyp, der Verifizierungsfehler umfasst.
Anmerkung

Ein Datenverifizierungsfehler führt nicht zum Fehlschlagen des Migrationsvorgangs.

Sie können die CR Restore überprüfen, um die Ursache des Datenverifizierungsfehlers zu ermitteln.

Vorgehensweise

  1. Melden Sie sich beim Ziel-Cluster an.
  2. Zeigen Sie die CR Restore an:

    $ oc describe <registry-example-migration-rvwcm> -n openshift-migration

    Die Ausgabe identifiziert das Persistent Volume mit PodVolumeRestore-Fehlern.

    Beispielausgabe

    status:
      phase: Completed
      podVolumeRestoreErrors:
      - kind: PodVolumeRestore
        name: <registry-example-migration-rvwcm-98t49>
        namespace: openshift-migration
      podVolumeRestoreResticErrors:
      - kind: PodVolumeRestore
        name: <registry-example-migration-rvwcm-98t49>
        namespace: openshift-migration

  3. Zeigen Sie die CR PodVolumeRestore an:

    $ oc describe <migration-example-rvwcm-98t49>

    Die Ausgabe identifiziert den Pod Restic, der die Fehler protokolliert hat.

    Beispielausgabe

      completionTimestamp: 2020-05-01T20:49:12Z
      errors: 1
      resticErrors: 1
      ...
      resticPod: <restic-nr2v5>

  4. Sehen Sie sich das Protokoll des Pod Restic an, um die Fehler zu lokalisieren:

    $ oc logs -f <restic-nr2v5>

12.4.3.7. Restic-Berechtigungsfehler bei der Migration von einem NFS-Speicher mit aktiviertem „root_squash“

Wenn Sie Daten von einem NFS-Speicher migrieren und root_squash aktiviert ist, wird Restic zu nfsnobody zugeordnet und hat keine Berechtigung, die Migration durchzuführen. Der folgende Fehler wird im Protokoll des Pod Restic angezeigt.

Beispielausgabe

backup=openshift-migration/<backup_id> controller=pod-volume-backup error="fork/exec /usr/bin/restic: permission denied" error.file="/go/src/github.com/vmware-tanzu/velero/pkg/controller/pod_volume_backup_controller.go:280" error.function="github.com/vmware-tanzu/velero/pkg/controller.(*podVolumeBackupController).processBackup" logSource="pkg/controller/pod_volume_backup_controller.go:280" name=<backup_id> namespace=openshift-migration

Sie können dieses Problem beheben, indem Sie eine ergänzende Gruppe für Restic erstellen und die Gruppen-ID zum Manifest der CR MigrationController hinzufügen.

Vorgehensweise

  1. Erstellen Sie eine ergänzende Gruppe für Restic auf dem NFS-Speicher.
  2. Legen Sie das Bit setgid in den NFS-Verzeichnissen fest, sodass das Gruppeneigentum vererbt wird.
  3. Fügen Sie auf den Quell- und Ziel-Clustern den Parameter restic_supplemental_groups zum Manifest der CR MigrationController hinzu:

    spec:
      restic_supplemental_groups: <group_id> 1
    1
    Geben Sie die ergänzende Gruppen-ID an.
  4. Warten Sie den Neustart der Restic-Pods ab, damit die Änderungen übernommen werden.

12.4.4. Bekannte Probleme

Diese Version hat die folgenden bekannten Probleme:

  • Während der Migration behält das Migration Toolkit for Containers (MTC) die folgenden Namespace-Annotationen bei:

    • openshift.io/sa.scc.mcs
    • openshift.io/sa.scc.supplemental-groups
    • openshift.io/sa.scc.uid-range

      Diese Annotationen bewahren den UID-Bereich und stellen sicher, dass die Container ihre Dateisystemberechtigungen auf dem Ziel-Cluster beibehalten. Es besteht das Risiko, dass die migrierten UIDs sich in einem bestehenden oder zukünftigen Namespace auf dem Ziel-Cluster duplizieren. (BZ#1748440)

  • Die meisten Cluster-Ressourcen werden noch nicht von MTC gehandhabt. Wenn Ihre Anwendungen Cluster-Ressourcen benötigen, müssen Sie diese möglicherweise manuell auf dem Ziel-Cluster erstellen.
  • Wenn eine Migration fehlschlägt, behält der Migrationsplan die benutzerdefinierten PV-Einstellungen für stillgelegte Pods nicht bei. Sie müssen die Migration manuell zurücksetzen, den Migrationsplan löschen und einen neuen Migrationsplan mit Ihren PV-Einstellungen erstellen. (BZ#1784899)
  • Wenn eine große Migration fehlschlägt, weil Restic eine Zeitüberschreitung verursacht, können Sie den Wert des Parameters restic_timeout (Standard: 1h) im Manifest der Custom Resource (CR) MigrationController erhöhen.
  • Wenn Sie die Datenverifizierungsoption für PVs wählen, die mit der Dateisystem-Kopiermethode migriert werden, ist die Leistung deutlich langsamer.
  • Wenn Sie Daten von einem NFS-Speicher migrieren und root_squash aktiviert ist, wird Restic zu nfsnobody zugeordnet. Die Migration schlägt fehl und im Pod-Protokoll Restic wird ein Berechtigungsfehler angezeigt. (BZ#1873641)

    Sie können dieses Problem beheben, indem Sie dem Manifest der CR MigrationController zusätzliche Gruppen für Restic hinzufügen:

    spec:
    ...
      restic_supplemental_groups:
      - 5555
      - 6666
  • Wenn Sie eine Direct Volume Migration mit Knoten durchführen, die sich in unterschiedlichen Verfügbarkeitszonen oder Verfügbarkeitsgruppen befinden, kann die Migration fehlschlagen, weil die migrierten Pods nicht auf den PVC zugreifen können. (BZ#1947487)

12.5. Zurücksetzen einer Migration

Sie können eine Migration über die MTC-Webkonsole oder die CLI zurücksetzen.

Sie können eine Migration auch manuell zurücksetzen.

12.5.1. Zurücksetzen einer Migration über die MTC-Webkonsole

Sie können eine Migration mithilfe der MTC-Webkonsole (Migration Toolkit for Containers) zurücksetzen.

Anmerkung

Die folgenden Ressourcen verbleiben in den migrierten Namespaces, um nach einer fehlgeschlagenen Direct Volume Migration (DVM) ein Debugging durchführen zu können:

  • Config-Zuordnungen (Quell- und Ziel-Cluster)
  • Secret-Objekte (Quell- und Ziel-Cluster)
  • Rsync-CRs (Quell-Cluster)

Diese Ressourcen haben keine Auswirkungen auf das Rollback. Sie können sie manuell löschen.

Wenn Sie später denselben Migrationsplan erfolgreich ausführen, werden die Ressourcen der fehlgeschlagenen Migration automatisch gelöscht.

Wenn Ihre Anwendung während einer fehlgeschlagenen Migration angehalten wurde, müssen Sie die Migration zurücksetzen, um eine Datenbeschädigung im Persistent Volume zu verhindern.

Ein Rollback ist nicht erforderlich, wenn die Anwendung während der Migration nicht angehalten wurde, da die ursprüngliche Anwendung noch auf dem Quell-Cluster ausgeführt wird.

Vorgehensweise

  1. Klicken Sie in der MTC-Webkonsole auf Migration plans.
  2. Klicken Sie auf das Optionsmenü kebab neben einem Migrationsplan und wählen Sie unter Migration die Option Rollback.
  3. Klicken Sie auf Rollback und warten Sie, bis das Rollback abgeschlossen ist.

    In den Details des Migrationsplans wird Rollback succeeded angezeigt.

  4. Überprüfen Sie in der OpenShift Container Platform-Webkonsole des Quell-Clusters, ob das Rollback erfolgreich war:

    1. Klicken Sie auf HomeProjects.
    2. Klicken Sie auf das migrierte Projekt, um seinen Status anzuzeigen.
    3. Klicken Sie im Bereich Routes auf Location, um zu verifizieren, ob die Anwendung funktioniert (falls zutreffend).
    4. Klicken Sie auf WorkloadsPods, um zu verifizieren, ob die Pods im migrierten Namespace ausgeführt werden.
    5. Klicken Sie auf StoragePersistent volumes, um zu überprüfen, ob das migrierte Persistent Volume korrekt bereitgestellt wurde.

12.5.2. Zurücksetzen einer Migration über die Command Line Interface

Sie können eine Migration zurücksetzen, indem Sie eine MigMigration-Custom Resource (CR) über die Command Line Interface erstellen.

Anmerkung

Die folgenden Ressourcen verbleiben in den migrierten Namespaces, um nach einer fehlgeschlagenen Direct Volume Migration (DVM) ein Debugging durchführen zu können:

  • Config-Zuordnungen (Quell- und Ziel-Cluster)
  • Secret-Objekte (Quell- und Ziel-Cluster)
  • Rsync-CRs (Quell-Cluster)

Diese Ressourcen haben keine Auswirkungen auf das Rollback. Sie können sie manuell löschen.

Wenn Sie später denselben Migrationsplan erfolgreich ausführen, werden die Ressourcen der fehlgeschlagenen Migration automatisch gelöscht.

Wenn Ihre Anwendung während einer fehlgeschlagenen Migration angehalten wurde, müssen Sie die Migration zurücksetzen, um eine Datenbeschädigung im Persistent Volume zu verhindern.

Ein Rollback ist nicht erforderlich, wenn die Anwendung während der Migration nicht angehalten wurde, da die ursprüngliche Anwendung noch auf dem Quell-Cluster ausgeführt wird.

Vorgehensweise

  1. Erstellen Sie eine MigMigration-CR anhand des folgenden Beispiels:

    $ cat << EOF | oc apply -f -
    apiVersion: migration.openshift.io/v1alpha1
    kind: MigMigration
    metadata:
      labels:
        controller-tools.k8s.io: "1.0"
      name: <migmigration>
      namespace: openshift-migration
    spec:
    ...
      rollback: true
    ...
      migPlanRef:
        name: <migplan> 1
        namespace: openshift-migration
    EOF
    1
    Geben Sie den Namen der zugehörigen MigPlan-CR an.
  2. Überprüfen Sie in der MTC-Webkonsole, ob die migrierten Projektressourcen aus dem Ziel-Cluster entfernt wurden.
  3. Überprüfen Sie, ob die migrierten Projektressourcen im Quell-Cluster vorhanden sind und ob die Anwendung ausgeführt wird.

12.5.3. Manuelles Zurücksetzen einer Migration

Sie können eine fehlgeschlagene Migration manuell zurücksetzen, indem Sie die stage-Pods löschen und die Stilllegung der Anwendung aufheben.

Wenn Sie denselben Migrationsplan erfolgreich ausführen, werden die Ressourcen der fehlgeschlagenen Migration automatisch gelöscht.

Anmerkung

Die folgenden Ressourcen verbleiben nach einer fehlgeschlagenen Direct Volume Migration (DVM) in den migrierten Namespaces:

  • Config-Zuordnungen (Quell- und Ziel-Cluster)
  • Secret-Objekte (Quell- und Ziel-Cluster)
  • Rsync-CRs (Quell-Cluster)

Diese Ressourcen haben keine Auswirkungen auf das Rollback. Sie können sie manuell löschen.

Vorgehensweise

  1. Löschen Sie die stage-Pods auf allen Clustern:

    $ oc delete $(oc get pods -l migration.openshift.io/is-stage-pod -n <namespace>) 1
    1
    In der CR MigPlan angegebene Namespaces.
  2. Heben Sie die Stilllegung der Anwendung auf dem Quell-Cluster auf, indem Sie die Replikate auf ihre Anzahl vor der Migration skalieren:

    $ oc scale deployment <deployment> --replicas=<premigration_replicas>

    Die Annotation migration.openshift.io/preQuiesceReplicas in der CR Deployment zeigt die Anzahl der Replikate vor der Migration an:

    apiVersion: extensions/v1beta1
    kind: Deployment
    metadata:
      annotations:
        deployment.kubernetes.io/revision: "1"
        migration.openshift.io/preQuiesceReplicas: "1"
  3. Überprüfen Sie, ob die Anwendungspods auf dem Quell-Cluster ausgeführt werden:

    $ oc get pod -n <namespace>

Zusätzliche Ressourcen