Oracle Cloud Infrastructure - Dokumentation

In VCN-native Cluster migrieren

Erfahren Sie, wie Sie ein Cluster mit der Kubernetes Engine (OKE) migrieren, um seinen Kubernetes-API-Endpunkt in Ihr eigenes VCN zu integrieren.

In früheren Releases (vor dem 16. März 2021) stellte Kubernetes Engine Cluster mit Kubernetes-API-Endpunkten bereit, die nicht in Ihr eigenes VCN integriert waren. Der Kubernetes-API-Endpunkt war öffentlich, und Sie konnten den Zugriff darauf nicht einschränken. Sie können solche Cluster weiterhin mit der CLI oder API erstellen (bis zu dem Datum, das hier in der Ankündigung zur Serviceänderung angegeben ist), jedoch nicht über die Konsole.

Nach dem 16. März 2021 kann die Kubernetes-Engine Cluster mit ihren Kubernetes-API-Endpunkten in einem Subnetz in Ihrem eigenen VCN bereitstellen (diese Cluster werden als "VCN-native Cluster" bezeichnet). Sie können VCN-native Cluster flexibler konfigurieren, um Ihre eigenen Sicherheits- und Netzwerkanforderungen zu erfüllen. Sie können den Kubernetes-API-Endpunkt so konfigurieren, dass er in Ihrem VCN (und einem Peer-On-Premise-Netzwerk) privat zugänglich ist, oder dass er öffentlich über das Internet zugänglich ist:

  • Um den Kubernetes-API-Endpunkt privat zugänglich zu machen, hosten Sie den Kubernetes-API-Endpunkt in einem privaten Subnetz, und weisen Sie ihm keine öffentliche IP-Adresse zu.
  • Um den Kubernetes-API-Endpunkt öffentlich über das Internet zugänglich zu machen, hosten Sie den Kubernetes-API-Endpunkt in einem öffentlichen Subnetz, und weisen Sie ihm eine öffentliche IP-Adresse zu.

Der Zugriff auf das Kubernetes-API-Subnetz kann mit Sicherheitsregeln kontrolliert werden, die für Netzwerksicherheitsgruppen (empfohlen) oder Sicherheitslisten definiert sind.

Um die Sicherheitskontrolle zu nutzen, die von VCN-nativen Clustern angeboten wird, können Sie ein vorhandenes Cluster migrieren, um seinen Kubernetes-API-Endpunkt in Ihr eigenes VCN zu integrieren.

Die Clustermigration umfasst die folgenden Phasen:

  • Phase 1: Cluster migrieren

    Sie starten die Migration, indem Sie das zu migrierende Cluster auswählen und dann das vorhandene VCN und das private oder öffentliche Subnetz angeben, in dem der neue Kubernetes-API-Endpunkt gehostet werden soll. Die Migration dauert in der Regel etwa 15 Minuten.

    Während dieser Zeit ist die Kubernetes-API weiterhin über den ursprünglichen ö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.

    Siehe Vorhandenes Cluster zu VCN-nativ migrieren.

  • Phase 2: Zugriff auf das migrierte Cluster einrichten

    Wenn die Migration abgeschlossen ist, wird das Cluster über den neuen Kubernetes-API-Endpunkt in Ihrem eigenen VCN sowie über den ursprünglichen öffentlichen Kubernetes-API-Endpunkt zugänglich, der nicht in Ihr VCN integriert ist. Sie können jetzt die Konfiguration Ihrer kubectl-, Tools- und CI/CD-Pipelines aktualisieren, um den neuen Kubernetes-API-Endpunkt zu verwenden.

    Um zu prüfen, ob Sie Ihre kubectl-, Tools- und CI/CD-Pipelines korrekt aktualisiert haben, können Sie den ursprünglichen öffentlichen Kubernetes-API-Endpunkt vorübergehend außer Betrieb nehmen, testen, ob die aktualisierten Konfigurationen den neuen Kubernetes-API-Endpunkt verwenden, und dann die Außerbetriebnahme des ursprünglichen Endpunkts zurücksetzen.

    Siehe Zugriff auf ein migriertes Cluster einrichten.

  • Phase 3: Außerbetriebnahme des ursprünglichen öffentlichen Kubernetes-API-Endpunkts, der nicht in Ihr eigenes VCN integriert ist

    Wenn Sie sicher sind, dass Sie die Konfiguration Ihrer kubectl-, Tools- und CI/CD-Pipelines korrekt aktualisiert haben, um den neuen Kubernetes-API-Endpunkt in Ihrem eigenen VCN zu verwenden, können Sie den ursprünglichen öffentlichen Kubernetes-API-Endpunkt außer Betrieb nehmen, der nicht in Ihr VCN integriert ist. Wenn Sie den ursprünglichen Kubernetes-API-Endpunkt außer Betrieb setzen, ist der Zugriff auf das Cluster nur über den neuen Kubernetes-API-Endpunkt möglich. Die Außerbetriebnahme dauert in der Regel weniger als fünf Minuten.

    Wenn Sie den ursprünglichen Endpunkt nicht explizit außer Betrieb setzen, ist der Zugriff auf das Cluster weiterhin sowohl über den ursprünglichen Endpunkt als auch über den neuen Endpunkt möglich.

    Nachdem Sie den ursprünglichen Endpunkt außer Betrieb genommen haben, können Sie den Außerbetriebnahmevorgang zurücksetzen und diesen ursprünglichen Endpunkt erneut aktivieren. Die Standard-Rollback-Periode beträgt 30 Tage. Sie können die Rollback-Periode jedoch auf maximal 60 Tage erhöhen.

    Siehe Ursprünglichen öffentlichen Kubernetes-API-Endpunkt eines migrierten Clusters außer Betrieb setzen.

Vorhandenes Cluster zu VCN-nativ migrieren

Konsole verwenden

So migrieren Sie ein vorhandenes Cluster zu einem VCN-nativen Cluster, indem Sie es über einen neuen Kubernetes-API-Endpunkt in Ihrem VCN zugänglich machen:

  1. Wählen Sie auf der Listenseite Cluster den Namen des Clusters aus, das Sie migrieren möchten. Wenn Sie Hilfe beim Suchen der Listenseite oder des Clusters benötigen, finden Sie weitere Informationen unter Cluster auflisten.

    Labels für Migration erforderlich werden auf der Listenseite Cluster neben den Namen von Clustern mit Kubernetes-API-Endpunkten angezeigt, die nicht in Ihr VCN integriert sind.

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

  2. 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 Registerkarte 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.
  3. 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): Beispielkonfigurationen finden Sie unter Example Network Resource Configurations.
    2. Wählen Sie oben auf der Registerkarte 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 ursprünglichen ö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 Registerkarte 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.

Eine Meldung gibt an, dass das Cluster migriert wurde und die Außerbetriebnahme des öffentlichen API-Endpunkts aussteht. Zu diesem Zeitpunkt ist das neu migrierte Cluster sowohl über den neuen Kubernetes-API-Endpunkt in Ihrem VCN als auch über den ursprünglichen öffentlichen Kubernetes-API-Endpunkt zugänglich, der nicht in Ihr eigenes VCN integriert ist.

CLI verwenden

Verwenden Sie den Befehl oci ce cluster cluster cluster-migrate-to-native-vcn und die erforderlichen Parameter, um ein vorhandenes Cluster zu migrieren und seinen Kubernetes-API-Endpunkt in Ihr eigenes VCN zu integrieren:

oci ce cluster cluster-migrate-to-native-vcn --cluster-id <cluster-ocid> --endpoint-config "{\"subnetId\":\"<kube-api-endpoint-subnet-ocid>\"}" [OPTIONS]

Eine vollständige Liste der Parameter und Werte für CLI-Befehle finden Sie in der CLI-Befehlsreferenz.

API verwenden

Führen Sie den Vorgang ClusterMigrateToNativeVcn aus, um ein Cluster zu migrieren und dessen Kubernetes-API-Endpunkt in Ihr eigenes VCN zu integrieren.

Zugriff auf ein migriertes Cluster einrichten

Nachdem Sie ein Cluster zur Integration seines Kubernetes-API-Endpunkts in Ihr eigenes VCN migriert haben, müssen Sie die Konfiguration Ihrer kubectl-, Tools- und CI/CD-Pipelines aktualisieren, um den neuen Kubernetes-API-Endpunkt zu verwenden. Sie sollten 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. Außerdem müssen Sie alle Manifestdateien aktualisieren, die Referenzen auf die ursprüngliche 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. Prüfen Sie, ob kubectl eine Verbindung zum Cluster mit dem neuen Kubernetes-API-Endpunkt des Clusters 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 neuen Kubernetes-API-Endpunkt des Clusters ausführen.

Hinweis

Bis der ursprüngliche API-Endpunkt, der nicht in Ihr VCN integriert ist, außer Betrieb genommen wird, können Sie die ursprüngliche kubeconfig-Datei weiterhin generieren, indem Sie die Option --kube-endpoint aus dem Befehl oci ce cluster create-kubeconfig weglassen.

Ursprünglichen öffentlichen Kubernetes-API-Endpunkt eines migrierten Clusters außer Betrieb setzen

Konsole verwenden

So heben Sie den ursprünglichen öffentlichen Kubernetes-API-Endpunkt auf, der nicht in Ihr eigenes VCN integriert ist:

  1. Wählen Sie oben in der Registerkarte Clusterdetails die Option Deaktivieren aus, wenn Sie:

    • Setzen Sie den ursprünglichen Endpunkt vorübergehend außer Betrieb, testen Sie, ob die aktualisierten Konfigurationen den neuen Kubernetes-API-Endpunkt verwenden, und setzen Sie dann die Außerbetriebnahme zurück.
    • Den ursprünglichen Endpunkt dauerhaft außer Betrieb setzen.

    Die Außerbetriebnahme dauert in der Regel weniger als fünf Minuten. Wenn die Außerbetriebnahme abgeschlossen ist, wird eine Standard-Rollback-Periode von 30 Tagen hinzugefügt. Während der Rollback-Periode können Sie:

    • Ursprünglichen Endpunkt wiederherstellen
    • Rollback-Periode verlängern
    Wichtig

    Wenn die Rollback-Periode endet, können Sie die Außerbetriebnahme des ursprünglichen Endpunkts nicht mehr rückgängig machen. Der ursprüngliche Endpunkt wird dauerhaft außer Betrieb genommen, und der Außerbetriebnahmeprozess kann nicht rückgängig gemacht werden.

  2. (Optional) Wählen Sie Rollback aus, um das Außerbetriebnahme-Rollback rückgängig zu machen und den ursprünglichen Endpunkt wiederherzustellen. Das Rollback dauert in der Regel weniger als fünf Minuten.
  3. (Optional) Wählen Sie Rollback-Termin verlängern aus, um die Rollback-Periode auf maximal 60 Tage zu erhöhen.

CLI verwenden

Verwenden Sie den Befehl oci ce cluster start-public-api-endpoint-decommission und die erforderlichen Parameter, um den ursprünglichen Endpunkt eines Clusters außer Betrieb zu setzen:

oci ce cluster start-public-api-endpoint-decommission --cluster-id <cluster-ocid> [OPTIONS]

Verwenden Sie den Befehl oci ce cluster rollback-public-api-endpoint-decommission und die erforderlichen Parameter, um die Außerbetriebnahme des ursprünglichen Endpunkts eines Clusters zurückzusetzen:

oci ce cluster rollback-public-api-endpoint-decommission --cluster-id <cluster-ocid> [OPTIONS]

Verwenden Sie den Befehl oci ce cluster extend-endpoint-decommission-rollback-deadline und die erforderlichen Parameter, um den Rollback-Zeitraum zu erhöhen, wenn der ursprüngliche Endpunkt eines Clusters außer Betrieb genommen wird:

oci ce cluster extend-endpoint-decommission-rollback-deadline --cluster-id <cluster-ocid> --rollback-deadline-delay <duration> [OPTIONS]

wobei --rollback-deadline-delay <delay> eine Dauer im ISO 8601-Format angibt. Beispiel: --rollback-deadline-delay P10d, um die Rollback-Periode um 10 Tage zu erhöhen.

Eine vollständige Liste der Parameter und Werte für CLI-Befehle finden Sie in der CLI-Befehlsreferenz.

Häufig gestellte Fragen zur Clustermigration

Was sind VCN-native Cluster?

Kubernetes Engine erstellt Kubernetes-Cluster, die vollständig in Ihr virtuelles VCN (Oracle Cloud Infrastructure) integriert sind. Worker-Knoten, Load Balancer und der Kubernetes-API-Endpunkt sind Teil Ihres eigenen VCN und können als öffentlich oder privat konfiguriert werden. Solche Cluster, die vollständig in das eigene VCN integriert sind, werden als "VCN-native Cluster" bezeichnet.

Wie kann ich feststellen, ob ein Cluster bereits ein VCN-natives Cluster ist?

Wenn Sie nicht sicher sind, ob ein Cluster bereits ein VCN-natives Cluster ist, zeigen Sie Informationen zum Cluster an (z.B. auf der Registerkarte Clusterdetails in der Konsole). Wenn das Cluster bereits ein VCN-natives Cluster ist, enthalten die Clusterdetails Informationen zum Kubernetes-API-Endpunkt. Wenn das Cluster noch kein VCN-natives Cluster ist, enthalten die Clusterdetails einfach die Kubernetes-Adresse.

Muss ich alle meine vorhandenen Cluster migrieren?

Nein, Sie müssen nur vorhandene Cluster migrieren, die Sie in VCN-native Cluster umwandeln möchten. Wenn Sie den Kubernetes-API-Endpunkt eines Clusters nicht in Ihr eigenes VCN integrieren möchten, migrieren Sie dieses Cluster einfach nicht.

Beinhaltet die Migration Ausfallzeiten?

Während ein Cluster in ein VCN-natives Cluster migriert wird, ist die Kubernetes-API des Clusters weiterhin über den ursprünglichen ö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.

Soll ich automatische Migration oder benutzerdefinierte Migration wählen?

Bei der automatischen Migration wird ein regionales Subnetz im VCN des Clusters mit einem 10.0.0.0/28-CIDR-Block zusammen mit Sicherheitslisten und Routentabellen erstellt. Das Subnetz ist öffentlich, und dem API-Endpunkt wird eine öffentliche IP-Adresse zugewiesen. Die automatische Migration unterstützt nur Cluster mit Knotenpools im selben Compartment wie das Cluster. Führen Sie für Cluster mit Knotenpools in verschiedenen Compartments eine benutzerdefinierte Migration aus.

Mit der benutzerdefinierten Migration können Sie ein vorhandenes öffentliches oder privates regionales Subnetz auswählen, in dem der Kubernetes-API-Endpunkt des Clusters gehostet wird. Wenn Sie ein öffentliches regionales Subnetz auswählen, können Sie den Kubernetes-API-Endpunkt optional dem Internet bereitstellen, indem Sie dem Endpunkt eine öffentliche IP-Adresse zuweisen. Sie können optional Netzwerksicherheitsgruppen verwenden.

Wie konfiguriere ich ein Subnetz in meinem VCN zum Hosten des Kubernetes-API-Endpunkts?

Weitere Informationen zum Konfigurieren des Kubernetes-API-Endpunktsubnetzes, der Sicherheitslisten und der Routentabelle finden Sie unter Netzwerkressourcenkonfiguration für Clustererstellung und -Deployment.

Ich möchte die Migration in ein VCN-natives Cluster testen. Wie kann ich ein Cluster mit einem Kubernetes-API-Endpunkt erstellen, der nicht in mein VCN integriert ist?

Führen Sie im Terminalfenster, in dem Sie normalerweise Oracle Cloud Infrastructure-CLI-Befehle ausführen (und bis zu dem Datum, das in der Serviceänderungsankündigung hier angegeben ist), den folgenden Befehl aus, um ein Testcluster mit einem Kubernetes-API-Endpunkt zu erstellen, der nicht in Ihr VCN integriert ist:

oci ce cluster create --compartment-id <compartment-ocid> --kubernetes-version v<kubernetes-version-number> --name <cluster-name> --vcn-id <vcn-ocid>

Hierbei gilt:

  • --compartment-id <compartment-ocid> ist die OCID des Compartments, zu dem das Testcluster gehören soll.
  • --kubernetes-version v<kubernetes-version-number> ist eine unterstützte Version von Kubernetes (siehe Aktuell unterstützte Kubernetes-Versionen). Beispiel: --kubernetes-version v1.19.7
  • --name <cluster-name> ist ein Name Ihrer Wahl für das Testcluster. Beispiel: --name test-vcn-native-migration
  • --vcn-id <vcn-ocid> ist die OCID des VCN, in dem das Testcluster erstellt werden soll.

Nachdem Sie ein Testcluster mit einem Kubernetes-API-Endpunkt erstellt haben, der nicht in Ihr VCN integriert ist, können Sie das Testcluster jetzt migrieren, um es zu einem VCN-nativen Cluster zu machen. Siehe Vorhandenes Cluster zu VCN-nativ migrieren.

Denken Sie daran, das Testcluster zu löschen, wenn Sie es nicht mehr benötigen.