Oracle Cloud Infrastructureドキュメント

管理対象ノードからKubernetesバージョン1.35 (以降)へのアップグレード

OKE OL7イメージ、OL7プラットフォーム・イメージまたはOL7イメージに基づくカスタム・イメージを現在使用している管理対象ノードをアップグレードし、Kubernetes Engine (OKE)を使用してKubernetesバージョン1.35 (以降)およびOL8を実行する方法について説明します。

ノート

この項は、管理対象ノードにのみ適用されます。自己管理ノードをアップグレードする方法の詳細は、既存の自己管理ノードを置き換えることで新しいKubernetesバージョンへの自己管理ノードのアップグレードを参照してください。

Kubernetesバージョン1.35以降、Kubernetesにはコンテナ・リソース管理用のcgroup v2が必要です。

制御グループ(cgroups)は、プロセスまたはプロセスのグループのリソース割り当てを管理および制御するためのメカニズムを提供する Linuxカーネル機能です。コントロール・グループ・バージョン2 (cgroups v2)グループは、すべてのリソース・コントローラがマウントされる単一の制御グループ階層を提供します。この階層では、様々なリソース・コントローラ間でリソースの使用を調整できます。

Oracle Linux 7 (OL7)ではcgroup v1がサポートされますが、cgroup v2はサポートされません。Oracle Linux 8 (OL8)以降のバージョンでは、cgroups v1とcgroups v2の両方がサポートされていますが、cgroups v2がデフォルトでOL8で常に有効になっているわけではありません。

要約すると、Kubernetesバージョン1.35では、cgroup v2を有効にしたOL8 (またはそれ以降)が必要です。

ビルド番号が1367以上のOKE OL8イメージでは、Cgroups v2がデフォルトで有効になっています。ただし、ビルド番号が1367 (およびOL8プラットフォーム・イメージ)より小さいOKE OL8イメージでは、cgroups v1がデフォルトで有効になっています。

Kubernetesバージョン1.35 (以降)を実行しているクラスタ上のワーカー・ノードの場合、Kubernetes Engineは次のイメージをサポートします:

Kubernetesバージョン1.35 (以降)を実行しているクラスタでは、プラットフォーム・イメージ(OL7プラットフォーム・イメージとOL8プラットフォーム・イメージの両方)の使用はお薦めしません。すべての新規デプロイメントおよびアップグレードにOKEイメージを使用することを強くお薦めします。プラットフォーム・イメージを引き続き使用する場合は、プラットフォーム・イメージに基づいてカスタム・イメージを作成し、ノード・プールの作成または更新時にカスタム・イメージのOCIDを指定します(この方法はお薦めしません)。

現在OL8イメージを使用している管理対象ノードを、Kubernetesバージョン1.35 (以降)にアップグレードする場合は、次の点に注意してください:

  • ビルド番号が1367未満のOKE OL8イメージ(またはOKE OL8イメージに基づくカスタム・イメージ)を現在使用している管理対象ノードをアップグレードするには、インプレース・アップグレードを実行し、ビルド番号が1367以上のOKE OL8イメージを指定します。
  • インプレース・アップグレードを実行し、ビルド番号が1367以上のOKE OL8イメージを指定することで、現在OL8プラットフォーム・イメージを使用している管理対象ノードをアップグレードできます。
  • ノードをホストしているコンピュート・インスタンスのLinuxカーネルでcgroup v2がすでに有効になっているかどうかに関係なく、現在OL8イメージを使用している管理対象ノードのインプレース・アップグレードを実行できます。
  • インプレース・アップグレードを実行する手順は、新しいKubernetesバージョンへの管理対象ノードのアップグレードを参照してください。
  • Kubernetesバージョン1.35のサポートの導入の詳細は、OKE Welcomes Kubernetes 1.35: What's new、 what's change、 and what to do nextを参照してください。

cgroups v2のワークロードの検証

本番ワーカー・ノードをアップグレードする前に、アプリケーションおよびサポート・エージェントがcgroups v2と互換性があることを確認します。

cgroups v2は、コンテナ・メモリーの計上方法を変更できます。レポートされるコンテナ・メモリー使用量のみの増加は、メモリーの飽和を示すとはかぎりません。昇給に次の1つ以上の条件が伴う場合は、その昇給を調査します。

  • コンテナのメモリー不足(OOM)の終了。
  • コンテナまたはポッドが再起動します。
  • ポッドの削除。
  • MemoryPressureノード条件。

cgroups v2の要件、メモリー・アカウンティング、実行時互換性、およびノードで使用されるcgroupsバージョンの決定の詳細は、Kubernetesドキュメントのcgroup v2についてを参照してください。

古いアプリケーション・ランタイムでは、cgroups v2を使用するシステムのコンテナ・リソース制限が正しく検出されない場合があります。たとえば、Javaアプリケーションでは、コンテナのメモリー制限ではなく、ワーカー・ノードのリソースからヒープまたはその他のメモリー設定を計算できます。その結果、コンテナは構成済のメモリー制限を超え、Linux OOMキラーで終了する可能性があります。

Javaワークロードの場合は、次のJDKリリースまたはそれ以降のリリースのいずれかを使用します。

  • JDK 15
  • JDK 11.0.16
  • JDK 8u381

JDK 8u372では、cgroups v2の認識が導入されました。JDK 8u381には、cgroups v1およびcgroups v2のリソース制限検出、コンテナ・メトリックおよびアプリケーションの安定性に対するさらなる改善が含まれています。他のJDKディストリビューションおよびアプリケーション・ランタイムについては、ベンダーのドキュメントを参照して、cgroups v2をサポートするリリースを特定してください。

また、/sys/fs/cgroupに直接アクセスする監視、セキュリティおよびその他のエージェントの互換性も確認します。互換性のないエージェントをcgroups v2をサポートするバージョンに更新します。

本番ワーカー・ノードをアップグレードする前に、非本番環境で次の検証を実行します。

  1. 代表的なワークロードをテストし、cgroups v2を使用するノードでエージェントをサポートします。
  2. cgroups v2を有効にする前と後に、次の情報を比較します。
    • レポートされたコンテナ・メモリー使用量
    • コンテナOOMイベント
    • コンテナとポッドの再起動
    • ポッドの削除
    • MemoryPressureノード条件
    • アプリケーション・ランタイムによって検出されたメモリー制限

  3. Javaワークロードの場合:

    • 次のように入力して、JDKバージョンを記録します。

      java -version

    • 次のように入力して、JVMによって検出されたシステムおよびコンテナ設定を確認します。 

      java -XshowSettings:system -version

    • ワークロードに適切な場合は、明示的な-Xmsおよび-Xmx値を構成します。

OL7管理対象ノードをアップグレードして、Kubernetesバージョン1.35 (以降)を実行します

OKE OL7イメージを現在使用している管理対象ノード、OL7プラットフォーム・イメージまたはOL7イメージに基づくカスタム・イメージをアップグレードしてKubernetesバージョン1.35 (以降)を実行するには、アウトオブプレース・アップグレードを実行して、既存のノード・プールを新しいノード・プールに置き換えます:

  1. コンソールまたはCLIを使用して、OL7を使用する既存のノード・プールを次のように識別します。

    • コンソールの使用:

      1. 「クラスタ」リスト・ページで、表示するノード・プールを含むクラスタの名前を選択します。リスト・ページまたはクラスタの検索に関するヘルプが必要な場合は、クラスタのリストを参照してください。
      2. 「ノード・プール」タブを選択します。
      3. 「イメージ名」列を使用して、Oracle-Linux-7.9.xイメージを使用するノード・プールを識別します。

    • CLIの使用:次のようなコマンドを入力して、OL7を使用する既存のノード・プールを識別します。

      oci ce node-pool list --cluster-id <cluster-ocid> --compartment-id <compartment-ocid> --query 'data[*].{name:"name", image:"node-source"."image-id"}'

  2. コンソールまたはCLIを使用して、次のようにOL8イメージを使用する置換ノード・プールを作成します。

    • コンソールの使用:

      1. 「ノード・プール」タブで、「ノード・プールの追加」を選択し、新しいノード・プールの詳細を入力します。
      2. Oracle Linux 8.xイメージに基づいて「OKEワーカー・ノード・イメージ」を選択します。
      3. OL7ノード・プールと同じシェイプ、サイズおよび配置で新しいノード・プールを構成します。
      4. 「作成」を選択します。

    • CLIの使用:次のようなコマンドを入力して、OL8イメージを使用する置換ノード・プールを作成します。

      oci ce node-pool create --cluster-id <cluster-ocid> --compartment-id <compartment-ocid> --name "nodepool-ol8-workers" --node-shape "VM.Standard.E4.Flex" --kubernetes-version "v1.35.0" --node-image-id <ol8-image-ocid> --size 3 --placement-configs '[{"availabilityDomain":"AD-1","subnetId":"<subnet-ocid>"}]'

  3. OL7ノードをコード化します。

    1. 次のように入力して、OL7ノードの名前を取得します。

      kubectl get nodes -l node.kubernetes.io/os=ol7

    2. 次のように入力して、各ノードをコード化します。

      kubectl cordon <node-name>

  4. OL7ノードをドレインして、ワークロードを正常に移行します。

    1. 次のように入力して、各OL7ノードを排出します。
      kubectl drain <node-name> --ignore-daemonsets --delete-emptydir-data --force
    2. 次のように入力して、ワークロードが新しいノードで再スケジュールされていることを確認します。
      kubectl get pods -A -o wide | grep <node-name>

  5. コンソールまたはCLIを使用して、次のようにOL7ノード・プールを削除します。

    • コンソールの使用:

      1. 「ノード・プール」タブで、OL7ノード・プールの横にある「アクション」メニュー(3つのドット)から「ノード・プールの削除」を選択します。
      2. 「削除」をクリックします。
      3. ノード・プールを削除することを確認し、「削除」を選択します。

    • CLIの使用: OL7ノード・プールを削除します。

      oci ce node-pool delete --node-pool-id <ol7-nodepool-ocid>

  6. クラスタをアップグレードします(たとえば、Kubernetesバージョン1.35)。

    oci ce cluster update --cluster-id <cluster-ocid> --kubernetes-version "v1.35.0"

詳細は、「既存のノード・プールを新しいノード・プールに置き換えることで管理対象ノードKubernetesアップグレードの実行」を参照してください。