VCNネイティブ・クラスタへの移行

既存のクラスタを移行して、そのKubernetes APIエンドポイントを独自のVCNに統合するには:

1. ナビゲーション・メニューを開き、「開発者サービス」をクリックします「コンテナとアーティファクト」で、「Kubernetesクラスタ(OKE)」をクリックします。

2. 作業する権限があるコンパートメントを選択します。

   移行が必要なラベルは、クラスタ・リスト・ページで、VCNに統合されていないKubernetes APIエンドポイントを持つクラスタの名前の横に表示されます。

3. 「クラスタ・リスト」ページで、移行するクラスタの名前をクリックします。

   移行可能なクラスタを選択すると、「クラスタ詳細」ページの上部に「クラスタの移行」ボタンが表示されます。

4. クラスタのKubernetes APIエンドポイントをインターネットからパブリックにアクセス可能にし、(必要に応じて新しいネットワーク・リソースを作成および構成して)クラスタと同じVCNの新しいパブリック・サブネットでホストするには、次のように自動移行を実行します。
   1. 「Cluster Details」ページの上部で、「Migrate Cluster」をクリックして、クラスタのKubernetes APIエンドポイントを独自のVCNに統合します。
   2. 「VCNネイティブ・クラスタへの移行」ダイアログ・ボックスで、「自動移行」を選択して、10.0.0.0/28 CIDRブロックを持つクラスタのVCNに、セキュリティ・リストおよびルート表とともに新しいリージョナル・サブネットを作成します。
   3. 「ワークフローの起動」をクリックし、「VCNネイティブ・エンドポイント・クラスタ移行」ダイアログ・ボックスで移行サマリーを確認します。
   4. 「移行」をクリックして新しいネットワーク・リソースを作成し、クラスタを移行します。

      「クラスタの移行」ダイアログに示すように、Container Engine for Kubernetesによってクラスタの移行が開始されます。

   5. 「閉じる」をクリックして「クラスタの移行中」ダイアログを閉じます。
5. クラスタのKubernetes APIエンドポイントをVCN内でプライベートにアクセス可能にするか、インターネットからパブリックにアクセス可能にし、クラスタと同じVCN内の既存のリージョナル・パブリック・サブネットまたはプライベート・サブネットでホストする場合は、次のようにカスタム移行を実行します。
   1. 次のネットワーク・リソースがVCNにすでに存在し、Kubernetes APIエンドポイントをホストするように正しく構成されていることを確認します(存在しない場合は、適切に作成して構成します)。
      • リージョナル・パブリック・サブネットまたはプライベート・サブネット(「Kubernetes APIエンドポイント・サブネットの構成」を参照)
      • サブネットがパブリックの場合は、インターネット・ゲートウェイ(「インターネット・ゲートウェイの構成」を参照)
      • サブネットがプライベートの場合は、NATゲートウェイ(NAT Gateway Configurationを参照)およびサービス・ゲートウェイ(Service Gateway Configurationを参照)
      • 必要なルート・ルールを含むルート表(「Kubernetes APIエンドポイント・サブネットのルート表」を参照)
      • 必要なイングレスおよびエグレス・ルールを含むネットワーク・セキュリティ・グループ(推奨)またはセキュリティ・リスト(あるいはその両方) (Kubernetes APIエンドポイントのセキュリティ・ルールを参照)

      構成例については、ネットワーク・リソース構成例を参照してください。

   2. 「Cluster Details」ページの上部で、「Migrate Cluster」をクリックして、クラスタのKubernetes APIエンドポイントを独自のVCNに統合します。
   3. 「VCNネイティブ・クラスタに移行」ダイアログ・ボックスで、「カスタム移行」を選択します。
   4. 「ワークフローの起動」をクリックし、次を指定します。
      • Kubernetes APIエンドポイント・サブネット: クラスタのKubernetes APIエンドポイントをホストするリージョナル・サブネット。指定するサブネットは、パブリックでもプライベートでもかまいません。Kubernetes APIエンドポイントには常にプライベートIPアドレスが割り当てられます。パブリック・サブネットを指定する場合、パブリックIPアドレス(およびプライベートIPアドレス)をエンドポイントに割り当てることで、Kubernetes APIエンドポイントをインターネットにオプションで公開できます。アクセス管理を簡素化するために、Kubernetes APIエンドポイントをワーカー・ノードおよびロード・バランサとは異なるサブネットに配置することをお薦めします。詳細は、Kubernetesクラスタ・コントロール・プレーンおよびKubernetes APIを参照してください。
      • ネットワーク・セキュリティ・グループを使用してトラフィックを制御: オプションで、指定した1つ以上のネットワーク・セキュリティ・グループ(NSG)を使用して、クラスタのKubernetes APIエンドポイントへのアクセスを制限します。NSGに指定するセキュリティ・ルールの詳細は、Kubernetes APIエンドポイントのセキュリティ・ルールを参照してください。
      • APIエンドポイントにパブリックIPアドレスを割り当てます: Kubernetes APIエンドポイントのパブリック・サブネットを選択した場合(およびプライベートIPアドレス)にパブリックIPアドレスを割り当てることで、オプションでエンドポイントをインターネットに公開できます。パブリックIPアドレスを割り当てない場合は、サービス・ゲートウェイおよびNATゲートウェイを使用してエンドポイントへのアクセスを有効にするルート・ルールおよびセキュリティ・ルールを更新します(Kubernetes APIエンドポイント・サブネット構成を参照)。
   5. 「移行」をクリックして新しいネットワーク・リソースを作成し、クラスタを移行します。

      Container Engine for Kubernetesがクラスタの移行を開始します。

通常、移行の完了には約15分かかります。この間、Kubernetes APIには、独自のVCNに統合されていないパブリック・エンドポイントを介して引き続きアクセスできます。ただし、クラスタのライフサイクル操作(クラスタの更新、ノード・プールの作成、削除など)は使用できません。

移行が完了すると、「Cluster Details」ページに、Kubernetes APIエンドポイント・サブネットの名前、Kubernetes APIプライベート・エンドポイントのIPアドレス、および(Kubernetes APIエンドポイントにパブリックIPアドレスを割り当てた場合) Kubernetes APIパブリック・エンドポイントのIPアドレスが表示されます。

「クラスタ詳細」ページには、新しいKubernetes APIエンドポイントにアクセスするためにkubectl、ツールおよびCI/CDパイプラインの構成を更新する日数が30日あることも示されます(「移行されたクラスタへのアクセスの設定」を参照)。この廃止期間中、新しく移行されたクラスタには、VCNの新しいKubernetes APIエンドポイントと、独自のVCNに統合されていないパブリックKubernetes APIエンドポイントの両方を介してアクセスできます。

クラスタを移行してKubernetes APIエンドポイントを独自のVCNに統合した後、新しいKubernetes APIエンドポイントを使用するようにkubectl、ツールおよびCI/CDパイプラインの構成を更新する必要があります。少なくとも、このトピックで説明するように、kubectlを使用して移行したクラスタにアクセスできるように、クラスタのKubernetes構成ファイル(通常は'kubeconfig'ファイルと呼ばれる)を更新する必要があります。また、クラスタのKubernetes APIエンドポイントIPアドレスへの参照を含むマニフェスト・ファイルも更新する必要があります。

このトピックの手順に従って、新しいkubeconfigファイルを生成します。この手順では、クラスタのkubeconfigファイルがデフォルトの場所($HOME/.kube)にデフォルト名(config)で保存されていることを前提としています。そうでない場合は、それに応じて手順を調整します。

1. 通常はOracle Cloud Infrastructure CLIコマンドを実行する端末ウィンドウで、次のコマンドを実行してクラスタの既存のkubeconfigファイルを更新します。

   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

   ここでは:

   • --cluster-id <cluster-OCID>は、VCNネイティブにする既存のクラスタのOCIDです。
   • --file <kubeconfig-file-location>は、クラスタのkubeconfigファイルの場所です。
   • --region <region-name>は、クラスタが存在するリージョンです。
   • --kube-endpoint PRIVATE_ENDPOINT|PUBLIC_ENDPOINTでは、クラスタのKubernetes APIエンドポイントのプライベートIPアドレスまたはパブリックIPアドレスをkubeconfigファイルに追加するかどうかを指定します。詳細は、Kubernetesクラスタ・コントロール・プレーンおよびKubernetes APIを参照してください。

   例:

   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

   指定した場所にkubeconfigファイルがすでに存在する場合、クラスタの詳細は、独自のVCNでのクラスタの新しいKubernetes APIエンドポイントなど、既存のkubeconfigファイルに新しいコンテキストとして追加されます。kubeconfigファイルのcurrent-context:要素は、新しく追加されたコンテキストを指すように設定されます。

   kubeconfigファイルの設定の詳細は、クラスタ・アクセスの設定を参照してください。

2. 次のコマンドを入力して、kubectlが独自のVCNのKubernetes APIエンドポイントを使用してクラスタに接続できることを確認します。

   kubectl get nodes

   クラスタ内のノードに関する情報が表示されます。

   kubectlを使用して、独自のVCNのKubernetes APIエンドポイントを使用してクラスタで操作を実行できるようになりました。