In VCN-native Cluster migrieren

So migrieren Sie ein vorhandenes Cluster, um den zugehörigen Kubernetes-API-Endpunkt in Ihr eigenes VCN zu integrieren:

1. Öffnen Sie das Navigationsmenü , und wählen Sie Entwicklerservices aus. Wählen Sie unter Container und Artefakte die Option Kubernetes-Cluster (OKE) aus.

2. Wählen Sie ein Compartment aus, für das Sie eine Berechtigung besitzen.

   Migration erforderlich-Labels werden auf der Seite Clusterliste neben den Namen von Clustern mit Kubernetes-API-Endpunkten angezeigt, die nicht in Ihr VCN integriert sind.

3. Wählen Sie auf der Seite Clusterliste den Namen des Clusters aus, das Sie migrieren möchten.

   Wenn Sie ein Cluster auswählen, das Sie migrieren können, wird die Schaltfläche Cluster migrieren oben auf der Seite Clusterdetails angezeigt.

4. Wenn der Kubernetes-API-Endpunkt des Clusters öffentlich über das Internet zugänglich sein und in einem neuen öffentlichen Subnetz im selben VCN wie das Cluster gehostet werden soll (neue Netzwerkressourcen nach Bedarf erstellen und konfigurieren), führen Sie eine automatische Migration wie folgt aus:
   1. Wählen Sie oben auf der Seite Clusterdetails die Option Cluster migrieren aus, um den Kubernetes-API-Endpunkt des Clusters in Ihr eigenes VCN zu integrieren.
   2. Wählen Sie im Dialogfeld In VCN-natives Cluster migrieren die Option Automatische Migration aus, um ein neues regionales Subnetz im VCN des Clusters mit einem 10.0.0.0/28-CIDR-Block sowie Sicherheitslisten und Routentabellen zu erstellen.
   3. Wählen Sie Workflow starten aus, und prüfen Sie die Migrationsübersicht im Dialogfeld Clustermigration für VCN-nativen Endpunkt.
   4. Wählen Sie Migrieren aus, um neue Netzwerkressourcen zu erstellen und das Cluster zu migrieren.

      Kubernetes Engine beginnt mit der Migration des Clusters, wie im Dialogfeld Cluster migrieren dargestellt.

   5. Wählen Sie Schließen, um das Dialogfeld Cluster migrieren zu schließen.
5. Wenn der Kubernetes-API-Endpunkt des Clusters privat innerhalb Ihres VCN oder öffentlich über das Internet zugänglich sein und in einem vorhandenen regionalen öffentlichen oder privaten Subnetz im selben VCN wie das Cluster gehostet werden soll, führen Sie eine benutzerdefinierte Migration wie folgt aus:
   1. Stellen Sie sicher, dass die folgenden Netzwerkressourcen bereits im VCN vorhanden sind und korrekt für das Hosten des Kubernetes-API-Endpunkts konfiguriert sind (wenn nicht, erstellen und konfigurieren Sie sie entsprechend):
      • ein regionales öffentliches oder privates Subnetz (siehe Kubernetes-API-Endpunktsubnetzkonfiguration)
      • wenn das Subnetz öffentlich ist, ein Internetgateway (siehe Internetgatewaykonfiguration)
      • Wenn das Subnetz privat ist, ein NAT-Gateway (siehe NAT-Gatewaykonfiguration) und ein Servicegateway (siehe Servicegatewaykonfiguration)
      • eine Routentabelle mit den erforderlichen Routingregeln (siehe Routentabelle für Kubernetes-API-Endpunktsubnetze)
      • eine Netzwerksicherheitsgruppe (empfohlen) und/oder Sicherheitsliste mit den erforderlichen Ingress- und Egress-Regeln (siehe Sicherheitsregeln für den Kubernetes-API-Endpunkt)

      Beispielkonfigurationen finden Sie unter Beispielkonfigurationen für Netzwerkressourcen.

   2. Wählen Sie oben auf der Seite Clusterdetails die Option Cluster migrieren aus, um den Kubernetes-API-Endpunkt des Clusters in Ihr eigenes VCN zu integrieren.
   3. Wählen Sie im Dialogfeld In VCN-natives Cluster migrieren die Option Benutzerdefinierte Migration aus.
   4. Wählen Sie Workflow starten aus, und geben Sie Folgendes an:
      • Kubernetes-API-Endpunktsubnetz: Ein regionales Subnetz zum Hosten des Kubernetes-API-Endpunkts des Clusters. Das angegebene Subnetz kann öffentlich oder privat sein. Dem Kubernetes-API-Endpunkt wird immer eine private IP-Adresse zugewiesen. Wenn Sie ein öffentliches Subnetz angeben, können Sie den Kubernetes-API-Endpunkt optional dem Internet bereitstellen, indem Sie dem Endpunkt (sowie der privaten IP-Adresse) eine öffentliche IP-Adresse zuweisen. Um die Zugriffsverwaltung zu vereinfachen, empfiehlt Oracle, dass sich der Kubernetes-API-Endpunkt in einem anderen Subnetz als Worker-Knoten und Load Balancer befindet. Weitere Informationen finden Sie unter Kubernetes-Cluster-Control-Plane und Kubernetes-API.
      • Netzwerksicherheitsgruppen zur Steuerung des Traffics verwenden: Beschränken Sie den Zugriff auf den Kubernetes-API-Endpunkt des Clusters mit einer oder mehreren von Ihnen angegebene Netzwerksicherheitsgruppen (NSGs). Weitere Informationen zu den für die NSG anzugebenden Sicherheitsregeln finden Sie unter Sicherheitsregeln für den Kubernetes-API-Endpunkt.
      • Öffentliche IP-Adresse dem API-Endpunkt zuweisen: Wenn Sie ein öffentliches Subnetz für den Kubernetes-API-Endpunkt ausgewählt haben, können Sie den Endpunkt optional dem Internet bereitstellen, indem Sie dem Endpunkt (sowie der privaten IP-Adresse) eine öffentliche IP-Adresse zuweisen. Wenn Sie keine öffentliche IP-Adresse zuweisen, aktualisieren Sie Routingregeln und Sicherheitsregeln, um den Zugriff auf den Endpunkt über ein Servicegateway und ein NAT-Gateway zu ermöglichen (siehe Kubernetes-API-Endpunktsubnetzkonfiguration).
   5. Wählen Sie Migrieren aus, um neue Netzwerkressourcen zu erstellen und das Cluster zu migrieren.

      Die Kubernetes-Engine startet die Migration des Clusters.

Die Migration dauert in der Regel etwa 15 Minuten. Während dieser Zeit ist die Kubernetes-API weiterhin über den öffentlichen Endpunkt zugänglich, der nicht in Ihr eigenes VCN integriert ist. Clusterlebenszyklusvorgänge (wie Clusterupdates, Erstellen und Löschen von Knotenpools) sind jedoch nicht verfügbar.

Wenn die Migration abgeschlossen ist, werden auf der Seite Clusterdetails der Name des Kubernetes-API-Endpunktsubnetzes, die IP-Adresse des privaten Kubernetes-API-Endpunkts und (wenn Sie dem Kubernetes-API-Endpunkt eine öffentliche IP-Adresse zugewiesen haben) die IP-Adresse des öffentlichen Kubernetes-API-Endpunkts angezeigt.

Die Seite Clusterdetails gibt außerdem an, dass Sie 30 Tage Zeit haben, die Konfiguration Ihrer kubectl-, Tools- und CI/CD-Pipelines zu aktualisieren, um auf den neuen Kubernetes-API-Endpunkt zuzugreifen (siehe Zugriff auf ein migriertes Cluster einrichten). Während dieses Außerbetriebnahmezeitraums ist das neu migrierte Cluster sowohl über den neuen Kubernetes-API-Endpunkt in Ihrem VCN als auch über den öffentlichen Kubernetes-API-Endpunkt zugänglich, der nicht in Ihr eigenes VCN integriert ist.

Nachdem Sie ein Cluster migriert haben, um seinen Kubernetes-API-Endpunkt in Ihr eigenes VCN zu integrieren, müssen Sie die Konfiguration Ihrer kubectl-, Tools- und CI/CD-Pipelines aktualisieren, um den neuen Kubernetes-API-Endpunkt zu verwenden. Sie müssen mindestens die Kubernetes-Konfigurationsdatei des Clusters (allgemein als "kubeconfig"-Datei bezeichnet) aktualisieren, um den Zugriff auf das migrierte Cluster mit kubectl zu ermöglichen, wie in diesem Thema beschrieben. Sie müssen auch alle Manifestdateien aktualisieren, die Referenzen auf die IP-Adresse des Kubernetes-API-Endpunkts des Clusters enthalten.

Befolgen Sie die Anweisungen in diesem Thema, um eine neue kubeconfig-Datei zu generieren. Bei diesen Anweisungen wird davon ausgegangen, dass die kubeconfig-Datei des Clusters im Standardspeicherort ($HOME/.kube) und mit dem Standardnamen (config) gespeichert wird. Ist dies nicht der Fall, passen Sie die Anweisungen entsprechend an.

1. Führen Sie im Terminalfenster, in dem Sie normalerweise Oracle Cloud Infrastructure-CLI-Befehle ausführen, den folgenden Befehl aus, um die vorhandene kubeconfig-Datei des Clusters zu aktualisieren:

   oci ce cluster create-kubeconfig --cluster-id <cluster-ocid> --file <kubeconfig-file-location> --region <region-name> --token-version 2.0.0 --kube-endpoint PRIVATE_ENDPOINT|PUBLIC_ENDPOINT

   Hierbei gilt:

   • --cluster-id <cluster-ocid> ist die OCID des vorhandenen Clusters, das Sie als VCN-nativ festlegen möchten.
   • --file <kubeconfig-file-location> ist der Speicherort der kubeconfig-Datei des Clusters.
   • --region <region-name> ist die Region, in der sich das Cluster befindet.
   • --kube-endpoint PRIVATE_ENDPOINT|PUBLIC_ENDPOINT gibt an, ob die private IP-Adresse oder die öffentliche IP-Adresse des Kubernetes-API-Endpunkts des Clusters zur kubeconfig-Datei hinzugefügt werden soll. Weitere Informationen finden Sie unter Kubernetes-Cluster-Control-Plane und Kubernetes-API.

   Beispiel:

   oci ce cluster create-kubeconfig --cluster-id ocid1.cluster.oc1.phx.aaaaaaaaae... --file $HOME/.kube/config --region us-phoenix-1 --token-version 2.0.0 --kube-endpoint PUBLIC_ENDPOINT

   Wenn die kubeconfig-Datei bereits in dem von Ihnen angegebenen Verzeichnis vorhanden ist, werden Details über das Cluster als neuer Kontext zu der vorhandenen kubeconfig-Datei hinzugefügt, einschließlich des neuen Kubernetes-API-Endpunkts des Clusters in Ihrem eigenen VCN. Das Element current-context: in der kubeconfig-Datei ist so eingestellt, dass es auf den neu hinzugefügtem Kontext verweist.

   Weitere Informationen zum Einrichten der kubeconfig-Datei finden Sie unter Clusterzugriff einrichten.

2. Stellen Sie sicher, dass kubectl mit dem Kubernetes-API-Endpunkt in Ihrem eigenen VCN eine Verbindung zum Cluster herstellen kann, indem Sie den folgenden Befehl eingeben:

   kubectl get nodes

   Es werden Informationen über die Knoten im Cluster angezeigt.

   Sie können jetzt mit kubectl Vorgänge im Cluster mit dem Kubernetes-API-Endpunkt in Ihrem eigenen VCN ausführen.