ノードを Linux cgroupv2 に移行する

バージョン 1.33 以降、Google Kubernetes Engine（GKE）は cgroupv1 を実行しているクラスタを cgroupv2 に移行します。このページでは、次の方法について説明します。

• クラスタのノードで実行されている cgroup モードと、ワークロードが cgroup モード間の遷移の影響を受ける可能性があるかどうかを確認する。
• GKE Autopilot クラスタノードまたは Standard クラスタノード プールを cgroupv2 に移行する。
• GKE を一時的に無効にする。これにより、cgroupv1 を使用しているノードが自動的に cgroupv2 に移行されます。cgroup モードの移行による影響を受ける可能性があるワークロードをクラスタで実行している場合は、次の手順に沿って操作します。

ワークロードが cgroupv2 で想定どおりに実行されていること、または cgroup モードの構成の影響を受けないことがわかっている場合、このページを読む必要はありません。バージョン 1.33 以降では、GKE は cgroupv1 を実行しているクラスタを cgroupv2 に自動的に移行します。

Linux コントロール グループについて

kubelet とコンテナ ランタイムは、Pod 内の各コンテナがアクセスできる CPU やメモリの量の制限など、リソース管理に Linux カーネルのコントロール グループ（cgroups）を使用します。カーネルの cgroup サブシステムには、cgroupv1 と cgroupv2 の 2 つのモードがあります。 cgroupv2 の Kubernetes サポートは、Kubernetes v1.18 でアルファ版、v1.22 でベータ版、v1.25 で一般提供されました。詳細については、Kubernetes cgroups v2 のドキュメントをご覧ください。

Standard クラスタの cgroup モードの構成については、Linux cgroup モード構成オプションをご覧ください。

GKE が cgroupv2 に移行する仕組み

次のタイムラインを確認して、cgroupv2 を使用するために GKE が既存のクラスタを移行する過程を確認してください。

• 1.26 より前のバージョンでは、cgroupv1 がノードのデフォルトでした。バージョン 1.26 以降では、cgroupv2 が新しいノードのデフォルトです。既存のノードには変更はありません。GKE クラスタがデフォルトで実行する cgroup モードの詳細については、クラスタノードの cgroup モードを確認するをご覧ください。
• GKE では、マイナー バージョン 1.31 で cgroupv1 が非推奨になりました。
• バージョン 1.33 以降、GKE は cgroupv1 を実行しているクラスタを cgroupv2 に移行します。ノードプールが cgroupv1 を使用することを明示的に指定することで、この自動移行を一時的に停止できます。
• GKE は、マイナー バージョン 1.35 で cgroupv1 のサポートを終了します。

1.31 や 1.33 などの新しいマイナー バージョンへの自動アップグレードのおおよそのタイミングについては、リリース チャンネルのおおよそのスケジュールをご覧ください。

始める前に

作業を始める前に、次のことを確認してください。

• Google Kubernetes Engine API を有効にする。
Google Kubernetes Engine API の有効化
• このタスクに Google Cloud CLI を使用する場合は、gcloud CLI をインストールして初期化する。すでに gcloud CLI をインストールしている場合は、gcloud components update を実行して最新のバージョンを取得する。

クラスタノードの cgroup モードを確認する

デフォルトの cgroup モードは、クラスタまたはノードプールのタイプとバージョンによって異なります。バージョン 1.26 以降では、デフォルトは cgroupv2 です。バージョン 1.25 以前では、デフォルトは cgroupv1 です。

• Autopilot クラスタと、ノード自動プロビジョニングで作成された新しい Standard クラスタ ノードプールの場合、cgroup モードは最初のクラスタ バージョンに基づいています。 Autopilot クラスタの作成時に cgroup モードを設定することはできません。新しいノードの自動プロビジョニング ノードの場合、マイナー バージョンに基づいてデフォルトの cgroup モードとは異なるモードを設定することはできません。
• ノード自動プロビジョニングを使用せずに手動で作成された Standard クラスタ ノードプールの場合、cgroup モードは最初のノードプール バージョンまたはカスタマイズされたノードシステム構成に基づいています。

cgroup モードを確認するには、クラスタモードに基づいていずれかの手順に沿って操作します。

gcloud container clusters describe CLUSTER_NAME \
    --format='value(nodePools[0].config.effectiveCgroupMode)'

ノードを cgroupv2 に移行する

バージョン 1.33 以降で GKE が既存のノードを自動的に移行する前に、既存のノードを移行しておくことをおすすめします。

cgroupv1 を実行しているノードを移行する手順は次のとおりです。

1. ノードの cgroup モードを確認します。クラスタのノードがすでに cgroupv2 を使用している場合は、追加の操作は必要ありません。
2. 移行に関する考慮事項（cgroup v2 への移行）を確認し、ワークロードが新しいバージョンの API を使用できるように準備されていることを確認します。

3. クラスタのノードを移行します。

   Autopilot

   cgroupv2 を使用するようにクラスタのノードを明示的に設定します。

   gcloud container clusters update CLUSTER_NAME \
       --autoprovisioning-cgroup-mode=v2
   

   CLUSTER_NAME は、使用するクラスタの名前に置き換えます。

   Standard

   1. クラスタにノードの自動プロビジョニングを使用する場合は、次のコマンドを実行して、ノードの自動プロビジョニングで作成された既存のノードプールと今後のノードプールが cgroupv2 を使用するようにします。

      gcloud container clusters update CLUSTER_NAME \
          --autoprovisioning-cgroup-mode=v2
      

      CLUSTER_NAME は、使用するクラスタの名前に置き換えます。

   2. ノードの自動プロビジョニングなしで作成された既存のノードプールの場合は、ノードプールを更新して、ノードシステム構成に以下を追加します。

      linuxConfig:
        cgroupMode: 'CGROUP_MODE_V2'
      

      詳細については、ノードシステム構成のカスタマイズをご覧ください。

      ノードの自動プロビジョニングを使用せずに新しいノードプールを手動で作成する場合、GKE はデフォルトで cgroupv2 を使用します。

cgroupv2 への自動移行を一時的に無効にする

一時的にマイナー バージョン 1.33 以降で cgroupv1 を実行しているノードを cgroupv2 に自動的に移行しないようにするには、cgroupv1 を明示的に設定する必要があります。ノードを cgroupv2 に移行したときにクラスタのワークロードに問題が発生した場合は、これらの手順を使用して一時的に cgroupv1 に戻すこともできます。

gcloud container clusters update CLUSTER_NAME \
    --autoprovisioning-cgroup-mode=v1