ノードシステム構成のカスタマイズ

Standard

このドキュメントでは、「ノードシステム構成」という構成ファイルを使用して、Google Kubernetes Engine（GKE）ノード構成をカスタマイズする方法について説明します。

概要

ノードの構成はさまざまな方法でカスタマイズできます。たとえば、ノードプールを作成するときに、マシンタイプや最小 CPU プラットフォームなどのパラメータを指定できます。

ノードシステム構成は、限定された一連のシステム設定を調整するための構成ファイルです。ノードシステム構成を使用すると、ノードプールで Kubernetes ノードエージェント（kubelet）と低レベルの Linux カーネル構成（sysctl）に対してカスタム設定を指定できます。

また、ランタイム構成ファイルという別のファイルを使用して、GKE ノードで containerd コンテナランタイムをカスタマイズすることもできます。手順については、GKE ノードで containerd 構成をカスタマイズするをご覧ください。

DaemonSet による GKE ノードの自動ブートストラップを行う場合などは、DaemonSet を使用してノードをカスタマイズできます。

ノードシステム構成の使用

ノードシステム構成を使用するには:

構成ファイルを作成します。このファイルには、kubelet 構成と sysctl 構成が含まれています。
クラスタまたはノードプールの作成または更新時に構成を追加します。

構成ファイルの作成

ノードシステム構成ファイルを YAML で記述します。次の例は、kubelet オプションと sysctl オプションの構成を追加する方法を示しています。

kubeletConfig:
  cpuManagerPolicy: static
linuxConfig:
 sysctl:
   net.core.somaxconn: '2048'
   net.ipv4.tcp_rmem: '4096 87380 6291456'

この例では、次のようになります。

cpuManagerPolicy: static は、静的 CPU 管理ポリシーを使用するように kubelet を構成します。
net.core.somaxconn: '2048' は、socket listen() バックログを 2,048 バイトに制限します。
net.ipv4.tcp_rmem: '4096 87380 6291456' は、TCP ソケットの受信バッファの最小値、デフォルト値、最大値をそれぞれ 4,096 バイト、87,380 バイト、6,291,456 バイトに設定します。

kubelet または sysctl の構成のみを追加する場合は、そのセクションのみを構成ファイルに追加します。たとえば、kubelet 構成を追加するには、次のファイルを作成します。

kubeletConfig:
  cpuManagerPolicy: static

構成ファイルに追加できるフィールドの完全なリストについては、Kubelet 構成オプションと Sysctl 構成オプションのセクションをご覧ください。

ノードプールへの構成の追加

構成ファイルを作成したら、Google Cloud CLI を使用して --system-config-from-file フラグを追加します。このフラグは、クラスタの作成時か、ノードプールの作成または更新時に追加できます。Google Cloud Console でノードシステム構成を追加することはできません。

ノードシステム構成を追加するには、次のコマンドを実行します。

クラスタの作成

gcloud container clusters create CLUSTER_NAME \
    --location=LOCATION \
    --system-config-from-file=SYSTEM_CONFIG_PATH

次のように置き換えます。

CLUSTER_NAME: クラスタの名前
LOCATION: クラスタの Compute Engine ゾーンまたはリージョン
SYSTEM_CONFIG_PATH: kubelet 構成と sysctl 構成を含むファイルのパス

ノードシステム構成を適用すると、定義したデフォルトの設定がクラスタのデフォルトノードプールで使用されます。

ノードプールの作成

gcloud container node-pools create POOL_NAME \
     --cluster CLUSTER_NAME \
     --location=LOCATION \
     --system-config-from-file=SYSTEM_CONFIG_PATH

次のように置き換えます。

POOL_NAME: ノードプールの名前
CLUSTER_NAME: ノードプールを追加するクラスタの名前
LOCATION: クラスタの Compute Engine ゾーンまたはリージョン
SYSTEM_CONFIG_PATH: kubelet 構成と sysctl 構成を含むファイルのパス

ノードプールの更新

gcloud container node-pools update POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --system-config-from-file=SYSTEM_CONFIG_PATH

次のように置き換えます。

POOL_NAME: 更新するノードプールの名前
CLUSTER_NAME: 更新するクラスタの名前
LOCATION: クラスタの Compute Engine ゾーンまたはリージョン
SYSTEM_CONFIG_PATH: kubelet 構成と sysctl 構成を含むファイルのパス

ノードシステム構成を編集する

ノードシステム構成を編集するには、必要な構成で新しいノードプールを作成するか、既存のノードプールのノードシステム構成を更新します。

ノードプールを作成して編集する

ノードプールを作成して、ノードシステム構成を編集するには:

必要な構成で構成ファイルを作成します。
新しいノードプールに構成を追加します。
ワークロードを新しいノードプールに移行します。
古いノードプールを削除します。

既存のノードプールを更新して編集する

既存のノードプールを更新してノードシステム構成を編集するには、ノードシステム構成を必要な値で更新します。ノードシステム構成を更新すると、ノードプールの構成が新しい構成で上書きされます。更新中にパラメータを省略すると、それぞれがデフォルトに設定されます。

ノードシステム構成をデフォルトに戻す場合は、kubelet と sysctl の空の値で構成ファイルを更新します。次に例を示します。

kubeletConfig: {}
linuxConfig:
  sysctl: {}

ノードシステム構成を削除する

ノードシステム構成を削除するには:

ノードプールを作成します。
ワークロードを新しいノードプールに移行します。
古いノードシステム構成を持つノードプールを削除します。

Kubelet 構成オプション

次の表に、変更可能な kubelet オプションを示します。

Kubelet 構成の設定	制限事項	デフォルト設定	説明
cpuManagerPolicy	値は `none` または `static` にする必要があります。	`none`	この設定は、kubelet の CPU Manager ポリシーを制御します。デフォルト値は `none` で、デフォルトの CPU アフィニティスキームになります。OS スケジューラによって自動的に実行される範囲を超えるアフィニティはありません。この値を `static` に設定すると、整数演算の CPU リクエストを含む保証型 QoS クラスの Pod に CPU の排他的使用を割り当てることができます。
cpuCFSQuota	値は `true` または `false` にする必要があります。	`true`	この設定では、Pod の CPU 上限が適用されます。この値を `false` に設定すると、Pod の CPU 制限は無視されます。 Pod が CPU の制限を受ける可能性がある特定のシナリオでは、CPU 制限を無視することが望ましい場合があります。`cpuCFSQuota` を無効にすると、誤った Pod が想定よりも多くの CPU リソースを消費するリスクがあります。
cpuCFSQuotaPeriod	値は実行時間である必要があります。	`"100ms"`	この設定では、CPU の CFS 割り当て期間値 `cpu.cfs_period_us` を設定します。この値は、cgroup による CPU リソースへのアクセス頻度を指定します。このオプションを使用すると、CPU スロットルの動作を調整できます。
`insecureKubeletReadonlyPortEnabled`	値はブール値（`true` または `false`）にする必要があります	`true`	この設定により、クラスタ内の新しいノードプールごとに、安全でない kubelet 読み取り専用ポート `10255` が無効になります。このファイルでこの設定を行うと、GKE API クライアントを使用してクラスタレベルで設定を変更できなくなります。
podPidsLimit	値は 1024～4194304 の範囲で指定してください。	`none`	この設定は、各 Pod が使用できるプロセス ID（PID）の最大数を設定します。

Sysctl 構成オプション

システムのパフォーマンスを調整するには、次の Kernel 属性を変更します。

複数の Linux Namespace が特定の sysctl に対して一意の値を持ち、その他はノード全体でグローバルな値を持っている場合があります。ノードシステム構成を使用して sysctl オプションを更新すると、sysctl がノードと各 Namespace にグローバルに適用されるため、各 Pod の Linux Namespace での sysctl の値が同じになります。

Linux cgroup モード構成オプション

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

ノードのシステム構成を使用すると、ノードプールの cgroup 構成をカスタマイズできます。cgroupv1 または cgroupv2 を使用できます。GKE は、バージョン 1.26 以降を実行する新しい Standard ノードプールには cgroupv2 を使用し、1.26 より前のバージョンには cgroupv1 を使用します。ノードの自動プロビジョニングで作成されたノードプールの場合、cgroup 構成はノードプールのバージョンではなく、初期クラスタバージョンによって異なります。

ノードのシステム構成を使用して、cgroupv1 または cgroupv2 を明示的に使用するようにノードプールを変更できます。既存のノードプールを 1.26 にアップグレードしただけでは、設定は cgroupv2 に変更されません。カスタマイズされた cgroup 構成のない 1.26 より前のバージョンで作成された既存のノードプールは、明示的に指定しない限り、cgroupv1 になります。

たとえば、cgroupv2 を使用するようにノードプールを構成するには、次のようなノードのシステム構成ファイルを使用します。

linuxConfig:
  cgroupMode: 'CGROUP_MODE_V2'

サポートされている cgroupMode オプションは次のとおりです。

CGROUP_MODE_V1: ノードプールで cgroupv1 を使用します。
CGROUP_MODE_V2: ノードプールで cgroupv2 を使用します。
CGROUP_MODE_UNSPECIFIED: デフォルトの GKE cgroup 構成を使用します。

cgroupv2 を使用するには、次の要件と制限が適用されます。

1.26 より前のバージョンを実行しているノードプールの場合は、gcloud CLI バージョン 408.0.0 以降を使用する必要があります。また、バージョン 395.0.0 以降では gcloud beta を使用します。
クラスタとノードプールで GKE バージョン 1.24.2-gke.300 以降を実行する必要があります。
コンテナ化されたノードイメージで Container-Optimized OS を使用する必要があります。
いずれかのワークロードが cgroup ファイルシステム（/sys/fs/cgroup/...）の読み取りに依存している場合は、cgroupv2 API と互換性があることを確認してください。
- モニタリングツールまたはサードパーティ製ツールが cgroupv2 と互換性があることを確認します。
JDK（Java ワークロード）を使用している場合は、cgroupv2 を完全にサポートしているバージョン（JDK 8u372、JDK 11.0.16 以降、JDK 15 以降など）を使用することをおすすめします。

cgroup の構成を確認する

ノードシステム構成を追加する場合、GKE は変更を実装するためにノードを再作成します。ノードプールに構成を追加してノードが再作成されたら、新しい構成を確認できます。

ノードプール内のノードの cgroup 構成を確認するには、gcloud CLI または kubectl コマンドラインツールを使用します。

gcloud CLI

ノードプールの cgroup 構成を確認します。

gcloud container node-pools describe POOL_NAME \
    --format='value(Config.effectiveCgroupMode)'

POOL_NAME は、ノードプールの名前に置き換えます。

出力は次のいずれかになります。

EFFECTIVE_CGROUP_MODE_V1: ノードは cgroupv1 を使用します。
EFFECTIVE_CGROUP_MODE_V2: ノードは cgroupv2 を使用します。

出力には、ノードプールのノードが再作成された後の新しい cgroup 構成のみが表示されます。Windows Server ノードプールの場合、出力は空になります。これは、cgroup をサポートしていないためです。

kubectl

kubectl を使用して、このノードプール内のノードの cgroup 構成を確認するには、ノードを選択し、次の手順でそのノードに接続します。

ノードプール内の任意のノードでインタラクティブシェルを作成します。コマンドの mynode は、ノードプール内の任意のノードの名前に置き換えます。
Linux ノードの cgroup のバージョンを確認します。

Linux huge page の構成オプション

ノードシステム構成ファイルを使用して、Linux カーネル機能の huge page を使用できます。

Kubernetes は、CPU やメモリと同様に、リソースの一種としてノード上の huge page をサポートしています。次のパラメータを使用して、Pod で使用する huge page を事前に割り当てるように Kubernetes ノードに指示します。Pod の huge page の使用量を管理するには、HugePages を管理するをご覧ください。

ノードに huge page を事前割り当てするには、量とサイズを指定します。たとえば、1 GB の 3 つの huge page と 2 MB の 1,024 個の huge page を割り当てるようにノードを構成するには、次のようなノードシステム構成を使用します。

linuxConfig:
  hugepageConfig:
    hugepage_size2m: 1024
    hugepage_size1g: 3

huge page を使用するには、次の制限と要件が適用されます。

ノードが huge page によって完全に占有されないようにするには、割り当てられた huge page の全体サイズが合計メモリの 60% を超えないようにします。たとえば、8 GB のメモリを搭載した e2-standard-2 マシンでは、huge page に 4.8 GB を超えるメモリを割り当てることはできません。
1 GB の huge page は、A3、C2D、C3、C3A、C3D、C4、CT5E、CT5L、CT5LP、CT6E、H3、M2、M3、または Z3 のマシンタイプでのみ使用できます。

ノードシステム構成のカスタマイズ

概要

ノードシステム構成の使用

構成ファイルの作成

ノードプールへの構成の追加

クラスタの作成

ノードプールの作成

ノードプールの更新

ノードシステム構成を編集する

ノードプールを作成して編集する

既存のノードプールを更新して編集する

ノードシステム構成を削除する

Kubelet 構成オプション

Sysctl 構成オプション

Linux cgroup モード構成オプション

cgroup の構成を確認する

gcloud CLI

kubectl

Linux huge page の構成オプション

次のステップ