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

コンソールの使用

VCNの新しいKubernetes APIエンドポイントを介してアクセスできるようにすることで、既存のクラスタをVCNネイティブになるように移行するには:

1. 「クラスタ」リスト・ページで、移行するクラスタの名前を選択します。リスト・ページまたはクラスタの検索に関するヘルプが必要な場合は、クラスタのリストを参照してください。

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

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

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

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

   5. 「クローズ」を選択して、「クラスタの移行」ダイアログをクローズします。
3. クラスタの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アドレスが表示されます。

メッセージは、クラスタが移行され、パブリックAPIエンドポイントのデコミッションが保留中であることを示します。この時点で、新しく移行されたクラスタには、VCNの新しいKubernetes APIエンドポイントと、独自のVCNに統合されていない元のパブリックKubernetes APIエンドポイントの両方からアクセスできます。

CLIの使用

既存のクラスタを移行してKubernetes APIエンドポイントを独自のVCNに統合するには、oci ce cluster-migrate-to-native-vcnコマンドと必要なパラメータを使用します:

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

CLIコマンドのパラメータおよび値の完全なリストは、CLIコマンド・リファレンスを参照してください。

APIの使用

ClusterMigrateToNativeVcn操作を実行して、クラスタを移行し、そのKubernetes APIエンドポイントを独自のVCNに統合します。

コンソールの使用

独自のVCNに統合されていない元のパブリックKubernetes APIエンドポイントをデコミッションするには:

1. 「クラスタ詳細」タブの上部で、次の場合に「デコミッション」を選択します。

   • 元のエンドポイントを一時的にデコミッションし、更新された構成が新しいKubernetes APIエンドポイントを使用することをテストしてから、デコミッションをロールバックします。
   • 元のエンドポイントを永続的にデコミッションします。

   通常、デコミッションの完了には5分未満かかります。デコミッションが完了すると、デフォルトのロールバック期間である30日が追加されます。ロールバック期間中は、次のことができます。

   • 元のエンドポイントのリストア
   • ロールバック期間の延長
   重要
   
   

   ロールバック期間が終了すると、元のエンドポイントの廃止をロールバックできなくなります。元のエンドポイントは完全にデコミッションされ、デコミッション・プロセスは元に戻せません。

2. (オプション)「ロールバック」を選択して、デコミッションをロールバックし、元のエンドポイントをリストアします。通常、ロールバックの完了には5分未満かかります。
3. (オプション)ロールバック期間を最大60日に増やすには、「ロールバック期限の延長」を選択します。

CLIの使用

クラスタの元のエンドポイントをデコミッションするには、oci ce cluster start-public-api-endpoint-decommissionコマンドと必要なパラメータを使用します:

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

クラスタの元のエンドポイントのデコミッションをロールバックするには、oci ce cluster rollback-public-api-endpoint-decommissionコマンドと必要なパラメータを使用します:

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

クラスタの元のエンドポイントをデコミッションするときにロールバック期間を長くするには、oci ce cluster extended-endpoint-decommission-rollback-deadlineコマンドと必要なパラメータを使用します:

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

ここで、--rollback-deadline-delay <delay>はISO 8601形式の期間を指定します。たとえば、ロールバック期間を10日増やす場合は--rollback-deadline-delay P10dです。

CLIコマンドのパラメータおよび値の完全なリストは、CLIコマンド・リファレンスを参照してください。

VCNネイティブ・クラスタとは

Kubernetes Engineは、Oracle Cloud Infrastructure Virtual Cloud Network (VCN)に完全に統合されたKubernetesクラスタを作成します。ワーカー・ノード、ロード・バランサおよびKubernetes APIエンドポイントは、独自のVCNの一部であり、パブリックまたはプライベートとして構成できます。独自のVCNに完全に統合されたクラスタは、VCNネイティブ・クラスタと呼ばれます。

クラスタがすでにVCNネイティブ・クラスタかどうかを確認するにはどうすればよいですか。

クラスタがすでにVCNネイティブ・クラスタであるかどうかわからない場合は、クラスタに関する情報(たとえば、コンソールの「クラスタ詳細」タブ)を表示します。クラスタがすでにVCNネイティブ・クラスタである場合、クラスタの詳細にはKubernetes APIエンドポイント情報が含まれます。クラスタがまだVCNネイティブ・クラスタでない場合、クラスタの詳細にはKubernetesアドレスのみが含まれます。

既存のクラスタをすべて移行する必要がありますか。

いいえ。移行する必要があるのは、VCNネイティブ・クラスタに変換する既存のクラスタのみです。クラスタのKubernetes APIエンドポイントを独自のVCNに統合しない場合は、そのクラスタを移行しないでください。

移行には停止時間が必要ですか。

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

自動移行またはカスタム移行を選択する必要がありますか。

自動移行では、セキュリティ・リストおよびルート表とともに、10.0.0.0/28 CIDRブロックを含むリージョナル・サブネットがクラスタのVCNに作成されます。サブネットはパブリックで、APIエンドポイントにはパブリックIPアドレスが割り当てられます。自動移行では、クラスタと同じコンパートメントにノード・プールがあるクラスタのみがサポートされます。異なるコンパートメントにノード・プールがあるクラスタの場合は、カスタム移行を実行します。

カスタム移行では、クラスタのKubernetes APIエンドポイントをホストする既存のパブリックまたはプライベートのリージョナル・サブネットを選択できます。パブリック・リージョナル・サブネットを選択した場合、エンドポイントにパブリックIPアドレスを割り当てることで、オプションでKubernetes APIエンドポイントをインターネットに公開できます。オプションで、ネットワーク・セキュリティ・グループを使用できます。

Kubernetes APIエンドポイントをホストするようにVCNのサブネットを構成するにはどうすればいいですか。

Kubernetes APIエンドポイント・サブネット、セキュリティ・リストおよびルート表の構成の詳細は、クラスタ作成およびデプロイメントのネットワーク・リソース構成を参照してください。

VCNネイティブ・クラスタへの移行をテストします。VCNに統合されていないKubernetes APIエンドポイントを使用してクラスタを作成するにはどうすればよいですか?

通常、Oracle Cloud Infrastructure CLIコマンドを実行するターミナル・ウィンドウ(およびここでサービス変更のお知らせで指定された日付まで)で、次のコマンドを実行して、VCNに統合されていないKubernetes APIエンドポイントを含むテスト・クラスタを作成します:

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

ここでは:

• --compartment-id <compartment-ocid>は、テスト・クラスタを所属させるコンパートメントのOCIDです。
• --kubernetes-version v<kubernetes-version-number>は、サポートされているKubernetesのバージョンです(現在サポートされているKubernetesのバージョンを参照)。たとえば、--kubernetes-version v1.19.7です。
• --name <cluster-name>は、テスト・クラスタに対して選択した名前です。たとえば、--name test-vcn-native-migrationです。
• --vcn-id <vcn-ocid>は、テスト・クラスタを作成するVCNのOCIDです。

VCNに統合されていないKubernetes APIエンドポイントを含むテスト・クラスタを作成した後、テスト・クラスタを移行してVCNネイティブ・クラスタにできるようになりました。VCNネイティブになる既存のクラスタの移行を参照してください。

テスト・クラスタが不要になった場合は、必ず削除してください。