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

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

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

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

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

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

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

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

      Kubernetesエンジンは、「クラスタの移行」ダイアログに示すように、クラスタの移行を開始します。

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

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

   2. 「クラスタの詳細」ページの上部で、「クラスタの移行」をクリックして、クラスタの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. 「移行」をクリックして、新しいネットワーク・リソースを作成し、クラスタを移行します。

      Kubernetesエンジンは、クラスタの移行を開始します。

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

移行が完了すると、「クラスタ詳細」ページに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パイプラインの構成を更新する必要があります。少なくとも、このトピックで説明するように、クラスタのKubernetes構成ファイル(通常は「kubeconfig」ファイル)を更新して、kubectlを使用して移行されたクラスタにアクセスできるようにする必要があります。クラスタの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エンドポイントを使用してクラスタで操作を実行できるようになりました。