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

Standard

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

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

このドキュメントでは、ノードシステム構成で使用可能な構成と、その構成を GKE Standard ノードプールに適用する方法について詳しく説明します。GKE Autopilot クラスタはノード環境の管理が強化されているため、GKE Standard ノードプールと比較して、直接的なノードシステム構成のオプションが制限されている点に注意してください。

ノードシステム構成を使用する理由

ノードシステム構成には次の利点があります。

パフォーマンスチューニング: 要求の厳しいアプリケーション（AI トレーニングやサービング、データベース、高トラフィックのウェブサーバー、レイテンシの影響を受けやすいサービスなど）向けに、ネットワークスタックのパフォーマンス、メモリ管理、CPU スケジューリング、I/O 動作を最適化します。
セキュリティ強化: 特定のカーネルレベルのセキュリティ設定を適用するか、特定のシステム動作を制限して攻撃対象領域を減らします。
リソース管理: kubelet による PID、ディスク容量、イメージのガベージコレクション、CPU とメモリリソースの管理方法を微調整します。
ワークロードの互換性: 特定のカーネル設定を必要とする特殊なソフトウェアや古いアプリケーションの特定の前提条件をノード環境が満たせるようにします。

ノード構成をカスタマイズするためのその他のオプション

以下の方法でノード構成をカスタマイズすることもできます。

ランタイム構成ファイル: GKE ノードで containerd コンテナランタイムをカスタマイズするには、「ランタイム構成ファイル」という別のファイルを使用します。詳細については、GKE ノードで containerd 構成をカスタマイズするをご覧ください。
ComputeClass: GKE ComputeClass 仕様でノード属性を指定できます。GKE バージョン 1.32.1-gke.1729000 以降では、GKE Autopilot モードと Standard モードの両方で ComputeClass を使用できます。詳細については、ノードシステム構成のカスタマイズをご覧ください。
DaemonSet: DaemonSet を使用してノードをカスタマイズすることもできます。詳細については、DaemonSet を使用して GKE ノードを自動的にブートストラップするをご覧ください。

ノードシステム構成は、Windows Server ノードではサポートされていません。

始める前に

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

コマンドラインツールをインストールする:
- このドキュメントの gcloud CLI の例を使用する場合は、Google Cloud CLI のインストールと構成が行われていることを確認してください。
- Terraform の例を使用する場合は、Terraform のインストールと構成が行われていることを確認してください。
権限を付与する: GKE クラスタとノードプールを作成して更新するには、container.clusterAdmin などの適切な IAM 権限、または同等の権限を持つ別のロールが必要です。
ワークロードの停止の可能性を考慮して計画する: カスタムノード構成はノードプールレベルで適用されます。変更が発生すると、通常、プール内のノードのローリングアップデートがトリガーされます。これには、ノードの再作成が伴います。ワークロードの中断の可能性を考慮した計画を立て、必要に応じて Pod Disruption Budget（PDB）を使用します。
すべての変更をバックアップしてテストする: 構成変更は、本番環境に適用する前に、必ずステージング環境または開発環境でテストしてください。誤った設定は、ノードの不安定化やワークロードの障害につながる可能性があります。
GKE のデフォルト設定を確認する: GKE ノードイメージには、最適化されたデフォルト構成が付属しています。パラメータのカスタマイズは、具体的なニーズがあり、変更の影響を理解している場合にのみ行ってください。

GKE Standard モードでノードシステム構成を使用する

ノードシステム構成を使用する場合は、kubelet と Linux カーネルの構成パラメータを含む YAML ファイルを使用します。ノードシステム構成は GKE Autopilot モードでも使用できますが、このドキュメントの手順では、GKE Standard モードでの構成ファイルの作成方法と使用方法について説明します。

GKE Standard モードでノードシステム構成を使用するには、次の操作を行います。

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

構成ファイルを作成する

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

kubeletConfig:
  cpuManagerPolicy: static
  allowedUnsafeSysctls:
    - 'kernel.shm*'
    - 'kernel.msg*'
    - 'kernel.sem'
    - 'fs.mqueue*'
    - 'net.*'
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 構成オプションの各セクションをご覧ください。

Standard ノードプールに構成を追加する

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

ノードシステム構成を使用してクラスタを作成する

ノードシステム構成は、gcloud CLI または Terraform を使用してクラスタの作成時に追加できます。次の手順では、ノードシステム構成をデフォルトのノードプールに適用します。

gcloud CLI

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

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

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

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

Terraform

カスタマイズされたノードシステム構成を持つリージョンクラスタを Terraform を使用して作成するには、次の例をご覧ください。

resource "google_container_cluster" "default" {
  name     = "gke-standard-regional-cluster"
  location = "us-central1"

  initial_node_count = 1

  node_config {
    # Kubelet configuration
    kubelet_config {
      cpu_manager_policy = "static"
    }

    linux_node_config {
      # Sysctl configuration
      sysctls = {
        "net.core.netdev_max_backlog" = "10000"
      }

      # Linux cgroup mode configuration
      cgroup_mode = "CGROUP_MODE_V2"

      # Linux huge page configuration
      hugepages_config {
        hugepage_size_2m = "1024"
      }
    }
  }
}

Terraform の使用方法の詳細については、GKE での Terraform のサポートをご覧ください。

ノードシステム構成を使用して新しいノードプールを作成する

ノードシステム構成は、gcloud CLI または Terraform を使用して新しいノードプールを作成するときに追加できます。

次の手順では、ノードシステム構成を新しいノードプールに適用します。

gcloud CLI

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

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

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

Terraform

カスタマイズされたノードシステム構成を持つノードプールを Terraform を使用して作成するには、次の例をご覧ください。

resource "google_container_node_pool" "default" {
  name    = "gke-standard-regional-node-pool"
  cluster = google_container_cluster.default.name

  node_config {
    # Kubelet configuration
    kubelet_config {
      cpu_manager_policy = "static"
    }

    linux_node_config {
      # Sysctl configuration
      sysctls = {
        "net.core.netdev_max_backlog" = "10000"
      }

      # Linux cgroup mode configuration
      cgroup_mode = "CGROUP_MODE_V2"

      # Linux huge page configuration
      hugepages_config {
        hugepage_size_2m = "1024"
      }
    }
  }
}

Terraform の使用方法の詳細については、GKE での Terraform のサポートをご覧ください。

既存のノードプールのノードシステム構成を更新する

次のコマンドを実行すると、既存のノードプールのノードシステム構成を更新できます。

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

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

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

この変更を行うにはノードの再作成が必要になり、実行中のワークロードが中断する可能性があります。この変更について詳しくは、メンテナンスポリシーを遵守せずにノードアップグレード戦略を使用してノードを再作成する手動変更の表で対応する行をご覧ください。

ノードの更新の詳細については、ノードの更新による中断に備えた計画をご覧ください。

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

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

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

ノードプールを作成してノードシステム構成を編集するには、次の操作を行います。

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

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

既存のノードプールのノードシステム構成を編集するには、[ノードプールの更新] タブでノードプールへの構成の追加の手順に沿って操作します。ノードシステム構成を更新し、ノードプールの既存のシステム構成が新しい構成でオーバーライドされる場合は、ノードを再作成する必要があります。更新中にパラメータを省略すると、パラメータはそれぞれがデフォルトに設定されます。

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

kubeletConfig: {}
linuxConfig:
  sysctl: {}

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

ノードシステム構成を削除するには、次の操作を行います。

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

`kubelet` の構成オプション

このセクションの表は、変更可能な kubelet オプションを示しています。

CPU 管理

次の表に、kubelet の CPU 管理オプションを示します。

`kubelet` 構成設定	制限事項	デフォルト設定	説明
`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 スロットルの動作を調整できます。

メモリ管理と強制排除

次の表に、メモリ管理と強制排除の変更可能なオプションを示します。このセクションには、evictionSoft フラグの変更可能なオプションを示す別の表も含まれています。

`kubelet` 構成設定	制限事項	デフォルト設定	説明
`evictionSoft`	シグナル名のマップ。値の制限については、次の表をご覧ください。	`none`	この設定では、シグナル名を強制排除（復元可能）のしきい値を定義する数量または割合にマッピングします。強制排除（復元可能）のしきい値には猶予期間が必要です。`kubelet` は、猶予期間が経過するまで Pod を強制排除しません。
`evictionSoftGracePeriod`	シグナル名のマップ。各シグナル名について、値は `5m` 未満の正の期間である必要があります。有効な時間単位は、`ns`、`us`（または `µs`）、`ms`、`s`、`m` のいずれかです。	`none`	この設定は、シグナル名を、強制排除（復元可能）のしきい値の猶予期間を定義する期間にマッピングします。強制排除（復元可能）のしきい値には、対応する猶予期間が必要です。
`evictionMinimumReclaim`	シグナル名のマップ。各シグナル名について、値は `10%` 未満の正の割合にする必要があります。	`none`	この設定は、シグナル名を、`kubelet` が Pod の強制排除を実行するときに再利用する特定のリソースの最小量を定義する割合にマッピングします。
`evictionMaxPodGracePeriodSeconds`	値には `0`～`300` の整数を指定してください。	`0`	この設定は、削除時の Pod 終了の最大猶予期間を秒単位で定義します。

次の表に、evictionSoft フラグの変更可能なオプションを示します。同じオプションが evictionSoftGracePeriod フラグと evictionMinimumReclaim フラグにも適用されますが、制限は異なります。

`kubelet` 構成設定	制限事項	デフォルト設定	説明
`memoryAvailable`	値は、ノードのメモリの `100Mi` より大きく `50%` より小さい量にする必要があります。	`none`	この設定は、強制排除（復元可能）前に使用可能なメモリ量を表します。`kubelet` の `memory.available` シグナルの量を定義します。
`nodefsAvailable`	値は `10%`～`50%` の範囲で指定してください	`none`	この設定は、強制排除（復元可能）前に使用可能な nodefs を表します。`kubelet` の `nodefs.available` シグナルの量を定義します。
`nodefsInodesFree`	値は `5%`～`50%` の範囲で指定してください	`none`	この設定は、強制排除（復元可能）前に空いている nodefs inode を表します。`kubelet` の `nodefs.inodesFree` シグナルの量を定義します。
`imagefsAvailable`	値は `15%`～`50%` の範囲で指定してください	`none`	この設定は、強制排除（復元可能）前に使用可能な imagefs を表します。`kubelet` の `imagefs.available` シグナルの量を定義します。
`imagefsInodesFree`	値は `5%`～`50%` の範囲で指定してください	`none`	この設定は、強制排除（復元可能）前に空いている imagefs inode を表します。`kubelet` の `imagefs.inodesFree` シグナルの量を定義します。
`pidAvailable`	値は `10%`～`50%` の範囲で指定してください	`none`	この設定は、強制排除（復元可能）前に使用可能な PID を表します。`kubelet` の `pid.available` シグナルの量を定義します。
`singleProcessOOMKill`	値は `true` または `false` にする必要があります。	cgroupv1 ノードの場合は `true`、cgroupv2 ノードの場合は `false`。	この設定では、コンテナ内のプロセスが個別に OOMkill されるか、グループとして OOMkill されるかを設定します。 GKE バージョン 1.32.4-gke.1132000、1.33.0-gke.1748000 以降で使用できます。

PID の管理

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

`kubelet` 構成設定	制限事項	デフォルト設定	説明
`podPidsLimit`	値は `1024`～`4194304` の範囲で指定してください	`none`	この設定は、各 Pod が使用できるプロセス ID（PID）の最大数を設定します。

ロギング

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

`kubelet` 構成設定	制限事項	デフォルト設定	説明
`containerLogMaxSize`	値は `10Mi`～`500Mi` の正の数と単位の接尾辞の組み合わせにする必要があります。	`10Mi`	この設定で、コンテナログローテーションポリシーの containerLogMaxSize 設定が制御されます。これにより、各ログファイルの最大サイズを構成できます。デフォルト値は `10Mi` です。有効な単位は `Ki`、`Mi`、`Gi` です。
`containerLogMaxFiles`	値は `2`～`10` の整数（両端の値を含む）にする必要があります。	`5`	この設定で、コンテナログファイルローテーションポリシーの containerLogMaxFiles 設定が制御されます。これにより、各コンテナで許可されるファイルの最大数をそれぞれ構成できます。デフォルト値は `5` です。コンテナあたりのログの合計サイズ `(container_log_max_size*container_log_max_files)` がノードの合計ストレージの 1% を超えてはいけません。

イメージのガベージコレクション

次の表に、イメージのガベージコレクションの変更可能なオプションを示します。

`kubelet` 構成設定	制限事項	デフォルト設定	説明
`imageGCHighThresholdPercent`	値は 10～85 の整数で、`imageGcLowThresholdPercent` より大きくする必要があります。	`85`	この設定では、この値を超えるまでイメージガベージコレクションが実行されるディスク使用量の割合を定義します。ガベージコレクションの対象となるディスク使用量の上限を表します。このフィールドの値を 100 で割って割合が計算されます。
`imageGCLowThresholdPercent`	値は 10～85 の整数で、`imageGcHighThresholdPercent` より小さくする必要があります。	`80`	この設定では、この値を超えるまではイメージガベージコレクションが実行されないディスク使用量の割合を定義します。ガベージコレクションの対象となるディスク使用量の下限を表します。このフィールドの値を 100 で割って割合が計算されます。
`imageMinimumGcAge`	値は `2m` 以下の期間である必要があります。有効な時間単位は、`ns`、`us`（または `µs`）、`ms`、`s`、`m`、`h` のいずれかです。	`2m`	この設定では、使用されていないイメージがガベージコレクションの対象になるまでの最短時間が定義されます。
`imageMaximumGcAge`	値は期間とする必要があります。	`0s`	この設定では、使用されていないイメージがガベージコレクションの対象になるまでの最長期間が定義されます。このフィールドのデフォルト値は `0s` で、このフィールドは無効になります。そのため、イメージが使用されていないという理由でガベージコレクションの対象になることはありません。この値を指定する場合は、`imageMinimumGcAge` フィールドの値より大きくする必要があります。 GKE バージョン 1.30.7-gke.1076000、1.31.3-gke.1023000 以降で使用できます。

イメージの pull

次の表に、イメージの pull の変更可能なオプションを示します。

`kubelet` 構成設定	制限事項	デフォルト設定	説明
`maxParallelImagePulls`	値は 2～5 の整数（両端の値を含む）にする必要があります。	ディスクタイプに応じて `2` または `3`。	この設定は、並列で実行できるイメージプルの最大数を定義します。デフォルト値は、ブートディスクのタイプによって決まります。

セキュリティと安全でないオペレーション

次の表に、セキュリティを構成し、安全でないオペレーションを処理するための変更可能なオプションを示します。

kubelet 構成設定制限事項デフォルト設定説明

`kubelet` 構成設定	制限事項	デフォルト設定	説明
`allowedUnsafeSysctls`	`sysctl` の名前またはグループのリスト。許可される `sysctl` グループは次のとおりです。 `kernel.shm` `kernel.msg` `kernel.sem` `fs.mqueue.` `net.`。	`none`	この設定では、Pod に設定できる安全でない `sysctl` 名または `sysctl` グループのカンマ区切りの許可リストを定義します。
`insecureKubeletReadonlyPortEnabled`	値はブール値（`true` または `false`）にする必要があります。	`true`	この設定により、クラスタ内の新しいノードプールごとに、安全でない `kubelet` 読み取り専用ポート `10255` が無効になります。このファイルでこの設定を構成すると、GKE API クライアントを使用してクラスタレベルで設定を変更できなくなります。

allowedUnsafeSysctls

sysctl の名前またはグループのリスト。許可される sysctl グループは次のとおりです。

kernel.shm*
kernel.msg*
kernel.sem
fs.mqueue.*
net.*。

none

この設定では、Pod に設定できる安全でない sysctl 名または sysctl グループのカンマ区切りの許可リストを定義します。

insecureKubeletReadonlyPortEnabled 値はブール値（true または false）にする必要があります。 true この設定により、クラスタ内の新しいノードプールごとに、安全でない kubelet 読み取り専用ポート 10255 が無効になります。このファイルでこの設定を構成すると、GKE API クライアントを使用してクラスタレベルで設定を変更できなくなります。

リソースマネージャー

Kubernetes には、一連のリソースマネージャーが用意されています。これらのリソースマネージャーを構成して、CPU、デバイス、メモリ（hugepage）リソースの特定の要件が構成された Pod のためにノードリソースの調整と最適化を行うことができます。

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

kubelet 構成設定制限事項デフォルト設定説明

cpuManagerPolicy 値は none または static にする必要があります。 none この設定で、kubelet CPU マネージャーポリシーが制御されます。デフォルト値は none で、デフォルトの CPU アフィニティスキームになります。OS スケジューラによって自動的に実行される範囲を超えるアフィニティはありません。

この値を static に設定すると、Guaranteed QoS クラスに属し、かつ整数の CPU リクエストを持つ Pod に排他的な CPU を割り当てることができます。

`kubelet` 構成設定	制限事項	デフォルト設定	説明
`cpuManagerPolicy`	値は `none` または `static` にする必要があります。	`none`	この設定で、`kubelet` CPU マネージャーポリシーが制御されます。デフォルト値は `none` で、デフォルトの CPU アフィニティスキームになります。OS スケジューラによって自動的に実行される範囲を超えるアフィニティはありません。この値を `static` に設定すると、`Guaranteed` QoS クラスに属し、かつ整数の CPU リクエストを持つ Pod に排他的な CPU を割り当てることができます。
`memoryManager.policy`	値は `None` または `Static` にする必要があります。	`None`	この設定で、`kubelet` のメモリマネージャーポリシーが制御されます。デフォルト値の `None` を使用すると、Kubernetes はメモリマネージャーが存在しない場合と同じように動作します。この値を `Static` に設定すると、Pod のタイプに依存するトポロジヒントが送信されます。詳しくは、Static ポリシーをご覧ください。この設定は、コントロールプレーンで GKE バージョン 1.32.3-gke.1785000 以降が実行されているクラスタでサポートされています。
`topologyManager`	値は、それぞれのフィールドでサポートされている設定のいずれかにする必要があります。 Terraform の手順を使用して構成を Standard ノードプールに追加する場合、`topologyManager` フィールドを設定することはできません。	`policy`: `none` `scope`: `container`	これらの設定で、`policy` サブフィールドと `scope` サブフィールドを使用して `kubelet` トポロジマネージャー構成が制御されます。トポロジマネージャーは、CPU 分離、メモリ、デバイスのローカリティに関連するパフォーマンス最適化のために関連コンポーネントを調整します。ポリシーとスコープの設定は、互いに独立して設定できます。これらの設定の詳細については、トポロジマネージャーのスコープとポリシーをご覧ください。次の GKE リソースがこの設定をサポートしています。コントロールプレーンで GKE バージョン 1.32.3-gke.1785000 以降が実行されているクラスタ。コントロールプレーンとノードで 1.33.0-gke.1712000 以降が実行されているクラスタの場合、トポロジマネージャーは GPU トポロジに関する情報も受信します。次のマシンタイプを使用するノード: A2、A3、A4、C3、C4、C4A、G2、G4、M3、N4

memoryManager.policy

値は None または Static にする必要があります。

None

この設定で、kubelet のメモリマネージャーポリシーが制御されます。デフォルト値の None を使用すると、Kubernetes はメモリマネージャーが存在しない場合と同じように動作します。

この値を Static に設定すると、Pod のタイプに依存するトポロジヒントが送信されます。詳しくは、Static ポリシーをご覧ください。

この設定は、コントロールプレーンで GKE バージョン 1.32.3-gke.1785000 以降が実行されているクラスタでサポートされています。

topologyManager

値は、それぞれのフィールドでサポートされている設定のいずれかにする必要があります。

Terraform の手順を使用して構成を Standard ノードプールに追加する場合、topologyManager フィールドを設定することはできません。

policy: none
scope: container

これらの設定で、policy サブフィールドと scope サブフィールドを使用して kubelet トポロジマネージャー構成が制御されます。トポロジマネージャーは、CPU 分離、メモリ、デバイスのローカリティに関連するパフォーマンス最適化のために関連コンポーネントを調整します。

ポリシーとスコープの設定は、互いに独立して設定できます。これらの設定の詳細については、トポロジマネージャーのスコープとポリシーをご覧ください。

次の GKE リソースがこの設定をサポートしています。

コントロールプレーンで GKE バージョン 1.32.3-gke.1785000 以降が実行されているクラスタ。コントロールプレーンとノードで 1.33.0-gke.1712000 以降が実行されているクラスタの場合、トポロジマネージャーは GPU トポロジに関する情報も受信します。
次のマシンタイプを使用するノード: A2、A3、A4、C3、C4、C4A、G2、G4、M3、N4

Sysctl 構成オプション

システムのパフォーマンスをチューニングするには、Linux カーネルパラメータを変更します。このセクションの表は、構成可能なさまざまなカーネルパラメータを示しています。

ファイルシステムパラメータ（`fs.*`）

次の表に、Linux ファイルシステムの変更可能なパラメータを示します。これらの設定で、ファイルハンドルの上限やイベントモニタリングなど、Linux ファイルシステムの動作が制御されます。

`Sysctl` パラメータ	制限事項	説明
`fs.aio-max-nr`	65,536～4,194,304 で指定してください。	この設定は、システム全体の非同期 I/O リクエストの最大数を定義します。
`fs.file-max`	104,857～67,108,864 で指定してください。	この設定は、Linux カーネルが割り当てることができるファイルハンドルの最大数を定義します。
`fs.inotify.max_user_instances`	8,192～1,048,576 で指定してください。	この設定は、ユーザーが作成できる inotify インスタンスの最大数を定義します。
`fs.inotify.max_user_watches`	8,192～1,048,576 で指定してください。	この設定は、ユーザーが作成できる inotify ウォッチの最大数を定義します。
`fs.nr_open`	1,048,576～2,147,483,584 で指定してください。	この設定は、プロセスで開くことができるファイル記述子の最大数を定義します。

カーネルパラメータ（`kernel.*`）

次の表に、Linux カーネルの変更可能なパラメータを示します。これらの設定で、共有メモリ割り当てなどのコアカーネル機能が構成されます。

Sysctl パラメータ	制限事項	説明
`kernel.shmmni`	4,096～32,768 で指定してください。	この設定は、システム全体の共有メモリセグメントの最大数を定義します。この値が設定されていない場合、デフォルトは `4096` です。
`kernel.shmmax`	0～18,446,744,073,692,774,399 で指定してください。	この設定は、カーネルで許可される単一の共有メモリセグメントの最大サイズ（バイト単位）を定義します。この値が実際の RAM 容量より大きい場合は無視されます。つまり、使用可能なすべての RAM を共有できます。
`kernel.shmall`	0～18,446,744,073,692,774,399 で指定してください。	この設定は、システムで一度に使用できる共有メモリページの合計量を定義します。AMD64 アーキテクチャおよび Intel 64 アーキテクチャでは、ページは 4,096 バイトです。
`kernel.perf_event_paranoid`	-1～3 で指定してください。	この設定で、CAP_PERFMON を持たない非特権ユーザーによるパフォーマンスイベントシステムの使用が制御されます。デフォルト値はカーネルの `2` です。
`kernel.sched_rt_runtime_us`	-1～1,000,000 で指定してください。	この設定は、リアルタイムスケジューリングで使用できる時間のグローバル上限を定義します。
`kernel.softlockup_panic`	省略可（ブール値）	この設定で、ソフトロックアップが検出されたときにカーネルパニックが発生するかどうかが制御されます。
`kernel.yama.ptrace_scope`	0～3 で指定してください。	この設定は、`ptrace()` システムコールのスコープと上限を定義し、プロセスのデバッグとトレースに影響します。サポートされている値は次のとおりです。 `0`: 従来の ptrace 権限。 `1`: 制限付き ptrace。多くのディストリビューションでデフォルトです。子プロセスまたは CAP_SYS_PTRACE のみ。 `2`: 管理者専用の ptrace。CAP_SYS_PTRACE を持つプロセスのみ。 `3`: ptrace なし。ptrace 呼び出しは許可されません。
`kernel.kptr_restrict`	0～2 で指定してください。	この設定は、`/proc` などのインターフェースを介してカーネルアドレスを公開する際に制限が適用されるかどうかを示します。
`kernel.dmesg_restrict`	省略可（ブール値）	この設定は、権限のないユーザーがカーネルのログバッファのメッセージを表示するために `dmesg(8)` を使用させないようにするかどうかを示します。
`kernel.sysrq`	0～511 で指定してください。	この設定で、SysRq キーで呼び出すことができる機能が制御されます。有効な値は次のとおりです。 `0`: sysrq を完全に無効にします。 `1`: すべての sysrq 関数を有効にします。 `>1`: 許可された sysrq 関数のビットマスク。詳しくは、Linux Magic System Request Key Hacks をご覧ください。

ネットワークパラメータ（`net.*`）

次の表に、ネットワーキングの変更可能なパラメータを示します。これらの設定で、ソケットバッファから接続トラッキングまで、ネットワーキングスタックのパフォーマンスと動作がチューニングされます。

Sysctl パラメータ	制限事項	説明
`net.core.busy_poll`	2,147,483,647 より小さい任意の正の整数。	この設定は、ポーリングと選択の低レイテンシのビジーポーリングタイムアウトを定義します。イベントを待機するビジーループの概算時間（マイクロ秒単位）を表します。
`net.core.busy_read`	2,147,483,647 より小さい任意の正の整数。	この設定は、ソケット読み取りの低レイテンシのビジーポーリングタイムアウトを定義します。デバイスキューでパケットを待機するビジーループの概算時間（マイクロ秒単位）を表します。
`net.core.netdev_max_backlog`	2,147,483,647 より小さい任意の正の整数。	この設定は、インターフェースがカーネルで処理できるよりも速い速度でパケットを受信した場合に、INPUT 側でキューに登録されるパケットの最大数を定義します。
`net.core.rmem_default`	2,147,483,647 より小さい任意の正の整数。	この設定は、デフォルトの受信ソケットバッファサイズ（バイト単位）を定義します。
`net.core.rmem_max`	2,147,483,647 より小さい任意の正の整数。	この設定は、受信ソケットバッファの最大サイズ（バイト単位）を定義します。
`net.core.wmem_default`	2,147,483,647 より小さい任意の正の整数。	この設定は、ソケット送信バッファのデフォルト設定（バイト単位）を定義します。
`net.core.wmem_max`	2,147,483,647 より小さい任意の正の整数。	この設定は、送信ソケットバッファの最大サイズ（バイト単位）を定義します。
`net.core.optmem_max`	2,147,483,647 より小さい任意の正の整数。	この設定は、ソケットごとに許可される補助バッファの最大サイズを定義します。
`net.core.somaxconn`	128～2,147,483,647 で指定してください。	この設定は、`socket listen()` バックログの上限を定義します。これは、ユーザー空間では SOMAXCONN として知られています。この設定のデフォルトは `128` です。
`net.ipv4.tcp_rmem`	{min, default, max}（それぞれ 0 より大きい、メモリはバイト単位）。	この設定は、モデレーションで UDP ソケットが使用する受信バッファの最小サイズ（バイト単位）を定義します。デフォルトの設定は 1 ページです。
`net.ipv4.tcp_wmem`	{min, default, max}（それぞれ 0 より大きい、メモリはバイト単位）。	この設定は、モデレーションで UDP ソケットが使用する送信バッファの最小サイズ（バイト単位）を定義します。デフォルトの設定は 1 ページです。
`net.ipv4.tcp_tw_reuse`	0～1 で指定してください。	この設定は、プロトコル上安全であると判断された場合に、新しい接続で `TIME_WAIT` 状態のソケットの再利用を許可するかどうかを定義します。デフォルト値は `0` です。
`net.ipv4.tcp_max_orphans`	16,384～262,144 で指定してください。	この設定は、ユーザーファイルハンドルに関連付けられていない TCP ソケットの最大数を定義します。
`net.ipv4.tcp_max_tw_buckets`	4,096～2,147,483,647 で指定してください。	この設定は、システムが同時に保持する timewait ソケットの最大数を定義します。この数を超えると、time-wait ソケットはすぐに破棄され、警告が出力されます。
`net.ipv4.tcp_syn_retries`	1～127 で指定してください。	この設定は、アクティブな TCP 接続の試行で初期 SYN が再送信される回数を定義します。
`net.ipv4.tcp_ecn`	0～2 で指定してください。	この設定で、TCP による明示的輻輳通知（ECN）の使用が制御されます。ECN は、TCP 接続の両端で ECN のサポートが指定されている場合にのみ使用されます。
`net.ipv4.tcp_mtu_probing`	0～2 で指定してください。	この設定で、TCP パケット化レイヤパス MTU 探索が制御されます。サポートされている値は次のとおりです。 `0`: 無効。 `1`: デフォルトでは無効。ICMP ブラックホールが検出されると有効になります。 `2`: 常に有効。初期 MSS `tcp_base_mss` を使用します。
`net.ipv4.tcp_congestion_control`		この設定は、クラスタで Dataplane V2 が有効になっている場合はサポートされていません。
`net.ipv6.conf.all.disable_ipv6`	ブール値	この値を変更することは、`conf/default/disable_ipv6` 設定と、インターフェースごとのすべての `disable_ipv6` 設定を同じ値に変更することと同じです。
`net.ipv6.conf.default.disable_ipv6`	ブール値	この設定により IPv6 の動作は無効になります。
`net.netfilter.nf_conntrack_acct`	0～1 で指定してください。	この設定により、接続トラッキングフローのアカウンティングが有効になります。デフォルト値は `0` で、設定が無効になっていることを意味します。GKE バージョン 1.32.0-gke.1448000 以降で使用できます。
`net.netfilter.nf_conntrack_max`	65,536～4,194,304 で指定してください。	この設定は、接続トラッキングテーブルのサイズを定義します。最大値に達すると、新しい接続は失敗します。GKE バージョン 1.32.0-gke.1448000 以降で使用できます。
`net.netfilter.nf_conntrack_buckets`	65,536～524,288 で指定してください。	この設定は、ハッシュテーブルのサイズを定義します。`nf_conntrack_max = nf_conntrack_buckets * 4` の結果を設定することをおすすめします。 GKE バージョン 1.32.0-gke.1448000 以降で使用できます。
`net.netfilter.nf_conntrack_tcp_timeout_close_wait`	60～3,600 で指定してください。	この設定は、TCP 接続が `CLOSE_WAIT` 状態を維持できる期間（秒単位）を定義します。デフォルト値は `3600` です。 GKE バージョン 1.32.0-gke.1448000 以降で使用できます。
`net.netfilter.nf_conntrack_tcp_timeout_established`	600～86,400 で指定してください。	この設定は、無効な接続が接続トラッキングテーブルから自動的に削除されるまでの期間（秒単位）を定義します。 GKE バージョン 1.32.0-gke.1448000 以降で使用できます。
`net.netfilter.nf_conntrack_tcp_timeout_time_wait`	1～600 で指定してください。	この設定は、TCP 接続が `TIME_WAIT` 状態を維持できる期間（秒単位）を定義します。デフォルト値は `120` です。 GKE バージョン 1.32.0-gke.1448000 以降で使用できます。

仮想メモリパラメータ（`vm.*`）

次の表に、仮想メモリサブシステムの変更可能なパラメータを示します。これらの設定で、カーネルによるメモリ、スワッピング、ディスクキャッシュの処理方法を制御する仮想メモリサブシステムが管理されます。

`sysctl` パラメータ	制限事項	説明
`vm.max_map_count`	65,536～2,147,483,647 で指定してください。	このファイルは、プロセスが保持できるメモリマップ領域の最大数を定義します。
`vm.dirty_background_ratio`	1～100 で指定してください。	この設定は、バックグラウンドカーネルフラッシャーのスレッドがライトバックを開始する前にダーティページで埋めることができるシステムメモリの割合を定義します。値は `vm.dirty_ratio` フィールドの値より小さくする必要があります。
`vm.dirty_background_bytes`	0～68,719,476,736 で指定してください。	この設定は、バックグラウンドカーネルフラッシャーのスレッドがライトバックを開始するダーティメモリの量を定義します。 `vm.dirty_background_bytes` は `vm.dirty_background_ratio` に対応していることに注意してください。指定できるのは、これらの設定のうち 1 つだけです。
`vm.dirty_expire_centisecs`	0～6,000 で指定してください。	この設定は、ダーティデータがカーネルフラッシャースレッドによってディスクに書き込まれるまでメモリに残すことができる最大期間（100 分の 1 秒単位）を定義します。
`vm.dirty_ratio`	1～100 で指定してください。	この設定は、書き込みを実行するプロセスが強制的にブロックされ、ダーティデータがそれに同期して書き出される前に、ダーティページで埋めることができるシステムメモリの割合を定義します。
`vm.dirty_bytes`	0～68,719,476,736 で指定してください。	この設定は、ディスク書き込みを生成するプロセスがライトバックを自動的に開始するダーティメモリの量を定義します。`vm.dirty_bytes` に許容される最小値は 2 ページ（バイト単位）です。この制限値を下回る値は無視され、従来の構成が保持されます。 `vm.dirty_bytes` は `vm.dirty_ratio` に対応していることに注意してください。指定できるのは、これらの設定のうち 1 つだけです。
`vm.dirty_writeback_centisecs`	0～1,000 で指定してください。	この設定は、カーネルフラッシャースレッドが古いダーティデータをディスクに書き込むために起動する間隔（100 分の 1 秒単位）を定義します。
`vm.overcommit_memory`	0、1、2 のいずれかを指定してください。	この設定により、メモリオーバーコミットを処理するためのカーネルの戦略が決定されます。値は次のとおりです。 `0`: 大規模な割り当てを拒否 `1`: 常に許可 `2`: スワップ領域 + RAM の比率を超える commit を防止
`vm.overcommit_ratio`	0～100 で指定してください。	この設定は、`vm.overcommit_memory` フィールドの値が `2` に設定されている場合に、オーバーコミットが許可される物理 RAM の割合を定義します。
`vm.vfs_cache_pressure`	0～100 で指定してください。	この設定により、dentry（ディレクトリ）と inode キャッシュに使用されるメモリを再利用するためのカーネルの優先度が調整されます。
`vm.swappiness`	0～200 で指定してください。	この設定により、カーネルがプロセスを物理メモリからスワップディスクに移動する流れが制御されます。デフォルト値は `60` です。
`vm.watermark_scale_factor`	10～3,000 で指定してください。	この設定で kswapd の aggressiveness が制御されます。これは、kswapd が復帰する前に残っているメモリと、スリープする前に解放するメモリを定義します。デフォルト値は `10` です。
`vm.min_free_kbytes`	67,584～1,048,576 で指定してください。	この設定は、OOM が発生する前の最小空きメモリ量を定義します。デフォルト値は `67584` です。

各 sysctl フラグでサポートされている値の詳細については、--system-config-from-file gcloud CLI ドキュメントをご覧ください。

複数の Linux の名前空間が特定の 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 は Arm マシンではサポートされていません。

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

たとえば、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 以降を実行する必要があります。
containerd を含む Container-Optimized OS または containerd を含む Ubuntu のノードイメージを使用する必要があります。
いずれかのワークロードが cgroup ファイルシステム（/sys/fs/cgroup/...）の読み取りに依存している場合は、cgroupv2 API と互換性があることを確認してください。
モニタリングツールまたはサードパーティ製ツールを使用する場合は、それらが cgroupv2 と互換性があることを確認してください。
Java ワークロード（JDK）を使用している場合は、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 hugepages の構成オプション

ノードシステム構成ファイルを使用して、hugepages を事前割り当てできます。Kubernetes は、CPU やメモリと同様に、リソースタイプとして事前に割り当てられた hugepages をサポートしています。

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

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

次の表に、Linux hugepages の変更可能な設定を示します。

Config パラメータ	制限事項	デフォルト値	説明
`hugepage_size2m`	整数の数。前述のメモリ割り当て上限が適用されます。	`0`	この設定では、特定の数の 2 MB の hugepages が事前割り当てされます。
`hugepage_size1g`	整数の数。前述のメモリとマシンタイプの両方の制限が適用されます。	`0`	この設定では、特定の数の 1 GB の hugepages が事前割り当てされます。

Transparent hugepages（THP）

ノードシステム構成ファイルを使用して、Linux カーネルの Transparent HugePage Support を有効にできます。THP を使用すると、カーネルがプロセスに hugepages を自動的に割り当てるため、手動で事前割り当てを行う必要はありません。

次の表に、THP の変更可能なパラメータを示します。

Config パラメータ	サポートされる値	デフォルト値	説明
`transparentHugepageEnabled`	`TRANSPARENT_HUGEPAGE_ENABLED_ALWAYS`: transparent hugepage がシステム全体で有効になっています。 `TRANSPARENT_HUGEPAGE_ENABLED_MADVISE`: MADV_HUGEPAGE リージョン内で transparent hugepage が有効になっています。この設定がデフォルトのカーネル構成です。 `TRANSPARENT_HUGEPAGE_ENABLED_NEVER`: transparent hugepage が無効になっています。 `TRANSPARENT_HUGEPAGE_ENABLED_UNSPECIFIED`: デフォルト値。GKE はカーネル構成を変更しません。	`UNSPECIFIED`	この設定で、anonymous メモリに対して THP を有効にするかどうかが制御されます。
`transparentHugepageDefrag`	`TRANSPARENT_HUGEPAGE_DEFRAG_ALWAYS`: THP をリクエストするアプリケーションは、割り当てに失敗すると停止し、THP を直ちに割り当てるために、ページを直接再利用してメモリを圧縮します。 `TRANSPARENT_HUGEPAGE_DEFRAG_DEFER`: アプリケーションがバックグラウンドで kswapd を起動してページを再利用します。kcompactd を起動してメモリを圧縮し、THP を近い将来利用できるようにします。後で THP ページをインストールするのは khugepaged です。 `TRANSPARENT_HUGEPAGE_DEFRAG_DEFER_WITH_MADVISE`: アプリケーションは、通常どおり直接再利用と圧縮に入りますが、`madvise(MADV_HUGEPAGE)` を使用したリージョンのみが対象となります。他のすべてのリージョンは、バックグラウンドで kswapd を起動してページを再利用します。さらに、kcompactd を起動してメモリを圧縮し、近い将来に THP を使用できるようにします。 `TRANSPARENT_HUGEPAGE_DEFRAG_MADVISE`: アプリケーションは、通常どおり直接再利用と圧縮に入りますが、`madvise(MADV_HUGEPAGE)` を使用したリージョンのみが対象となります。他のすべてのリージョンは、バックグラウンドで kswapd を起動してページを再利用します。さらに、kcompactd を起動してメモリを圧縮し、近い将来に THP を使用できるようにします。 `TRANSPARENT_HUGEPAGE_DEFRAG_NEVER`: アプリケーションが直接再利用や圧縮に入ることはありません。 `TRANSPARENT_HUGEPAGE_DEFRAG_UNSPECIFIED`: デフォルト値。GKE はカーネル構成を変更しません。	`UNSPECIFIED`	この設定は、THP のデフラグ構成を定義します。

THP は、GKE バージョン 1.33.2-gke.4655000 以降で使用できます。また、GKE バージョン 1.33.2-gke.4655000 以降では、新しい TPU ノードプールでデフォルトで有効になっています。既存のノードプールをサポートされているバージョン以降にアップグレードしても、THP は有効になりません。

ノードシステム構成のカスタマイズ コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

ノードシステム構成を使用する理由

ノード構成をカスタマイズするためのその他のオプション

始める前に

GKE Standard モードでノードシステム構成を使用する

構成ファイルを作成する

Standard ノードプールに構成を追加する

ノードシステム構成を使用してクラスタを作成する

gcloud CLI

Terraform

ノードシステム構成を使用して新しいノードプールを作成する

gcloud CLI

Terraform

既存のノードプールのノードシステム構成を更新する

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

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

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

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

kubelet の構成オプション

CPU 管理

メモリ管理と強制排除

PID の管理

ロギング

イメージのガベージ コレクション

イメージの pull

セキュリティと安全でないオペレーション

リソース マネージャー

Sysctl 構成オプション

ファイルシステム パラメータ（fs.*）

カーネル パラメータ（kernel.*）

ネットワーク パラメータ（net.*）

仮想メモリ パラメータ（vm.*）

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

cgroup の構成を確認する

gcloud CLI

kubectl

Linux hugepages の構成オプション

Transparent hugepages（THP）

次のステップ

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

`kubelet` の構成オプション

イメージのガベージコレクション

リソースマネージャー

ファイルシステムパラメータ（`fs.*`）

カーネルパラメータ（`kernel.*`）

ネットワークパラメータ（`net.*`）

仮想メモリパラメータ（`vm.*`）