Google は AI 技術を使用して、コンテンツをご希望の言語に翻訳しています。AI 翻訳には誤りが含まれる場合があります。

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

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 ノードイメージには、最適化されたデフォルト構成が付属しています。パラメータのカスタマイズは、具体的なニーズがあり、変更の影響を理解している場合にのみ行ってください。

ノードシステム構成を追加する

ノードシステム構成は、ComputeClass または構成ファイルを使用してカスタマイズできます。

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

カスタム ComputeClass を使用すると、kubelet と Linux カーネルの特定のパラメータをカスタマイズできます。この方法は、GKE バージョン 1.32.1-gke.1729000 以降で使用できます。

ComputeClass を使用してノードシステム構成をカスタマイズするには、次の操作を行います。

spec.nodePoolAutoCreation.enabled: true フィールド値ペアを含む ComputeClass を作成し、priorityDefaults フィールドにシステム構成を指定します。
ComputeClass を選択するワークロードをデプロイします。

ComputeClass を作成する

ComputeClass 構成を YAML で記述します。priorityDefaults 仕様内の nodeSystemConfig フィールドを使用して、すべての優先度でシステム構成を設定します。

次の ComputeClass の例では、静的 CPU マネージャーポリシーとカスタムカーネルパラメータを構成しています。

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: custom-sysconfig
spec:
  nodePoolAutoCreation:
    enabled: true
  priorityDefaults:
    nodeSystemConfig:
      kubeletConfig:
        cpuManagerPolicy: static
      linuxNodeConfig:
        sysctls:
          net.core.somaxconn: 2048
  priorities:
  - machineFamily: n4

ComputeClass を適用します。

kubectl apply -f custom-sysconfig.yaml

ComputeClass を選択するワークロードをデプロイする

Pod 仕様に、ComputeClass 名のノードセレクタを追加します。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 2
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      nodeSelector:
        cloud.google.com/compute-class: custom-sysconfig
      containers:
      - name: app-container
        image: nginx

ワークロードを適用します。

kubectl apply -f my-app.yaml

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

ノードシステム構成に構成ファイルを使用する

ノードシステム構成ファイルを使用する場合は、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'
  kernelOverrides:
    kernelCommandlineOverrides:
      specRstackOverflow: 'SPEC_RSTACK_OVERFLOW_OFF'
      initOnAlloc: 'INIT_ON_ALLOC_OFF'

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

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 バイトに設定します。
kernelCommandlineOverrides ブロックは、投機的リターンスタックオーバーフロー（SRSO）の緩和策と init_on_alloc カーネルパラメータを無効にします。

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 のサポートをご覧ください。

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

構成ファイルを使用してノードシステム構成を管理する場合は、次のいずれかの方法で既存のノードプールを更新できます。

中断のないライブアップデート: 更新された sysctl と kubelet の設定を、VM の再作成や Pod のエビクションを行わずに、実行中のノードに直接適用します。この方法は、sysctl または kubelet の設定のみを変更し、中断を最小限に抑える場合に使用します。
標準アップグレード戦略: 新しい構成でノードを再作成します。この方法は、ライブアップデートをサポートしていない設定を変更する場合、クラスタまたはノードプールで 1.37.1-gke.1954000 より前の GKE バージョンを実行している場合、または GKE で Pod をドレインして新しいノードに再スケジュールする場合に使用します。

ComputeClass を使用するノードの構成を変更するには、ComputeClass のノードシステム構成を編集するをご覧ください。

中断のないライブアップデートを使用して更新する

更新された sysctl と kubelet の設定を、構成ファイルから実行中のノードに直接適用できます。このプロセスでは、基盤となる VM を再作成または再起動せずにパラメータを更新するため、中断が減り、更新が高速化されます。次の linuxConfig オプションでは、引き続き標準のアップグレード戦略が必要です。

Linux cgroup モード
Linux の hugepage
Linux の正確な時刻同期
Linux VFIO
Linux ディスク I/O スケジューラ

ライブ情報の仕組み

ライブ情報は、サポートされている構成ごとに次のように機能します。

sysctl 構成: GKE は、各ノードで sysctl systemd サービスを再起動して、linuxConfig.sysctl フィールドのカーネルパラメータを適用します。名前空間付きの sysctl パラメータを更新すると、GKE は kubelet サービスも再起動して、Pod レベルの sysctl 構成を更新します。サポートされているパラメータについては、Sysctl 構成オプションをご覧ください。
kubelet 構成: GKE は、各ノードで kubelet サービスを再起動して、kubeletConfig フィールドのパラメータを適用します。ほとんどの kubelet 構成オプションは、ライブアップデートをサポートしています。ただし、cpuManagerPolicy、shutdownGracePeriodSeconds、shutdownGracePeriodCriticalPodsSeconds の各オプションには、標準のアップグレード戦略が必要です。

どちらの場合も、GKE は VM の再作成、Pod の強制排除、一時的なサージ VM の作成を行わずに、実行中のノードに変更を適用します。GKE は、ノードプールの --max-surge-upgrade 設定と --max-unavailable-upgrade 設定の合計を同時実行の上限として使用し、並行して更新される既存のノードの数を決定します。

ライブ情報の前提条件

ライブアップデートを使用するには、クラスタとノードプールが次の前提条件を満たしている必要があります。

GKE バージョン 1.37.1-gke.1954000 以降を実行します。
クラスタで NodeReadinessController アドオンを有効にします。ライブアップデート中、このコントローラは更新中の各ノードに readiness.k8s.io/gke-node-live-update-reconciling:NoSchedule taint を一時的に適用します。これにより、更新が完了するまで GKE は新しい Pod をノードにスケジュールしません。
- 新しいクラスタの場合は、クラスタの作成時に --addons フラグに NodeReadinessController アドオンを含めます。このフラグは、指定したアドオンのみを有効にし、他のすべてのアドオンを無効にします。そのため、保持するデフォルトのアドオンも指定してください。
- 既存のクラスタの場合は、クラスタの更新時に --update-addons=NodeReadinessController=ENABLED フラグを渡します。

ライブアップデートを適用する

ライブアップデートを適用する手順は次のとおりです。

変更する kubelet または sysctl の設定を含む、ノードプールの完全な構成が含まれるように、ノードシステム構成 YAML ファイルを作成または変更します。変更する予定のない設定をリセットしないようにするには、ノードプールの既存の構成から始めます。
構成ファイルを使用してノードプールを更新し、--node-config-update-mode フラグの値を LIVE_UPDATE_WITHOUT_DRAIN に設定します。
```
gcloud container node-pools update POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --system-config-from-file=SYSTEM_CONFIG_PATH \
    --node-config-update-mode=LIVE_UPDATE_WITHOUT_DRAIN
```
次のように置き換えます。
- POOL_NAME: 更新するノードプールの名前
- CLUSTER_NAME: ノードプールが含まれているクラスタの名前。
- LOCATION: クラスタのコンピューティングゾーンまたはリージョン
- SYSTEM_CONFIG_PATH: ノードシステム構成を含む YAML ファイルのパス。
GKE が更新された設定をノードプールに適用したことを確認します。
```
gcloud container node-pools describe POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --format="yaml(config.kubeletConfig, config.linuxNodeConfig)"
```
コマンド出力には、config.kubeletConfig フィールドと config.linuxNodeConfig フィールドにノードプールのアクティブな設定が表示されます。
省略可: 既存の Pod を再起動します。ライブアップデートは実行中の Pod を中断しないため、GKE はアップデートの完了後に起動する Pod にのみ更新された設定を適用します。すでに実行されているワークロードに設定を適用するには、Deployment で kubectl rollout restart を実行するなどして、Pod を再起動します。

ライブアップデートが想定どおりに実行されない場合、復元パスはアップデートオペレーションが完了したかどうかによって異なります。

ライブアップデートオペレーションが失敗した場合は、失敗したライブアップデートから復元するをご覧ください。
ライブアップデートオペレーションが成功しても、新しい設定によって意図しないワークロードの動作が発生する場合は、完了したライブアップデートを元に戻すをご覧ください。

ライブアップデートが失敗した場合の復元

ノードでライブアップデートが失敗すると、GKE はロールアウトを直ちに停止し、ノードプールを部分的に更新された状態のままにします。失敗の詳細を調べるには、次のいずれかを行います。

gcloud container operations describe コマンドを実行します。出力の statusMessage フィールドには、ライブアップデートが失敗したノードと、ノードが報告したエラーが示されます。次に例を示します。
```
statusMessage: 'Failed precondition: live update failed on node gke-my-cluster-default-pool-ae3770ee-2kk0:
  Live update fails with error: failed to write new kubelet config: ...'
```
ログエクスプローラで、影響を受けるノードの gke-node-live-update-reconciler コンポーネントのエラーを確認します。

ライブアップデートが失敗しても、ノードプールに保存されている構成は変更されないため、gcloud container node-pools update コマンドで以前の構成を再適用しても、アップデートはトリガーされません。障害を調査したら、次のいずれかの復元オプションを選択します。

問題を修正してライブアップデートを完了する（推奨）: 失敗の原因となった問題を解決してから、前の手順の gcloud container node-pools update コマンドをターゲット構成で再実行します。
以前の構成に戻す: 問題を解決できない場合は、gcloud container node-pools rollback コマンドを実行して、ノードプールを以前の構成に戻します。ライブアップデートとは異なり、このコマンドはノードプール内のすべてのノードを再作成します。これにより、ノードで実行されているワークロードが中断されます。

完了したライブアップデートを元に戻す

ライブアップデートオペレーションが成功しても、新しく適用された設定によって意図しないワークロードの動作が発生した場合は、以前の構成で別のライブアップデートを適用して、変更を元に戻します。このライブアップデートでは、Pod を強制排除したりノードを再起動したりすることなく、以前の構成が復元されます。gcloud container node-pools rollback コマンドは、オペレーションが成功した後は使用できません。オペレーションが失敗した場合にのみ機能します。

完了したライブアップデートを元に戻すには、次の操作を行います。

ノードプールの以前の構成がすべて含まれるように、ノードシステム構成 YAML ファイルを更新します。以前に構成されていない設定がある場合は、省略したりセクションを空のままにしたりせず、明示的にデフォルト値に設定します。デフォルト値については、Kubelet 構成オプションと Sysctl 構成オプションをご覧ください。

以前の構成をノードプールに適用します。

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

標準アップグレード戦略を使用して更新する

ライブアップデートをサポートしていない構成オプションを更新する場合、クラスタまたはノードプールで 1.37.1-gke.1954000 より前の GKE バージョンを実行している場合、または GKE が Pod を自動的にドレインして新しく作成されたノードに再スケジュールする場合は、標準のアップグレード戦略を使用します。

標準のアップグレード戦略を使用して既存のノードプールを更新するには、次のコマンドを実行します。

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: ノードシステム構成を含む YAML ファイルのパス。

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

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

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

ノードシステム構成は、ComputeClass または構成ファイルのどちらを使用しているかに応じて編集できます。

ComputeClass の場合

ComputeClass を使用するときにノードシステム構成を編集するには、次のいずれかの方法を選択します。

方法 1: 既存の ComputeClass を更新する

既存の ComputeClass で nodeSystemConfig を更新すると、GKE は更新された構成を新しく作成されたノードにのみ適用します。既存のノードは自動的に更新されません。

ワークロードを新しい構成のノードに移行するには、次のいずれかを行います。

ComputeClass でアクティブな移行を構成します。
新しいノードのスケールアップをトリガーするには、ワークロードを手動で再起動または再作成します。

ComputeClass を更新するには、YAML ファイルを編集して適用します。

kubectl apply -f custom-sysconfig.yaml

方法 2: 新しい ComputeClass を作成する

ワークロードが更新された構成で新しいノードに移行されるようにするには、次の操作を行います。

別の名前と更新された構成で新しい ComputeClass を作成します。
ワークロード仕様のノードセレクタを更新して、新しい ComputeClass を参照します。
更新されたワークロード仕様を適用します。クラスタオートスケーラーは、新しい構成で新しいノードをプロビジョニングし、最終的に古いノードをスケールダウンします。
古い ComputeClass オブジェクトを削除します。

構成ファイルの場合

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

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

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

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

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

既存のノードプールのノードシステム構成をインプレースで変更するには、既存のノードプールのノードシステム構成を更新するをご覧ください。

既存のノードシステム構成を取得する

ノードプールの既存のノードシステム構成を取得するには（たとえば、構成をすでにカスタマイズしていて、さらに追加する場合）、gcloud container node-pools describe コマンドを使用します。コマンドの出力には、kubeletConfig と linuxNodeConfig の既存の構成が一覧表示されます。

たとえば、次のスニペットは、describe コマンドの出力形式を示しています。

  kubeletConfig:
    allowedUnsafeSysctls:
    - kernel.shm*
    - kernel.msg*
    - kernel.sem
    - fs.mqueue.*
    - net.*
    cpuManagerPolicy: static
    insecureKubeletReadonlyPortEnabled: false
    maxParallelImagePulls: 2
  linuxNodeConfig: # IMPORTANT: Use linuxConfig when updating these settings
    sysctl:
      net.core.somaxconn: '2048'
      net.ipv4.tcp_rmem: 4096 87380 6291456

ノードシステム構成をまだ設定していない場合、出力に kubeletConfig または linuxNodeConfig は表示されません。

既存のノードシステム構成をリセットする

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

```yaml
kubeletConfig: {}
linuxConfig:
  sysctl: {}
```

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

ノードシステム構成を削除するには、ComputeClass または構成ファイルのどちらを使用しているかに応じて、次の手順を行います。

ComputeClass の場合

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

ワークロード仕様から cloud.google.com/compute-class ノードセレクタを削除します。
更新されたワークロード仕様を適用します。GKE はデフォルトのノードにワークロードを再作成します。クラスタオートスケーラーは、最終的に ComputeClass 用にプロビジョニングされたノードをスケールダウンして削除します。
クラスタから ComputeClass オブジェクトを削除します。
```
kubectl delete computeclass CUSTOM_COMPUTE_CLASS_NAME
```

構成ファイルの場合

構成ファイルを使用して適用されたノードシステム構成を削除するには、次の操作を行います。

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

`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 スロットルの動作を調整できます。

`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 スロットルの動作を調整できます。
`reservedSystemCPUs` （プレビュー）	予約する特定の CPU コアのリストを指定する必要があります（たとえば、コア 0 と 1 を予約する場合は `0-1` または `0,1`）。コアは 0 から始まるため、値はマシンタイプの vCPU 数より小さくする必要があります。	`none`	OS デーモンや `kubelet` サービスなどのホストシステムサービス用に特定の CPU コアを明示的に予約します。デフォルトでは、これらのサービスは任意の CPU コアで実行できます。これにより、CPU 負荷の高いワークロードでパフォーマンスの問題が発生する可能性があります。`cpuManagerPolicy: static` 設定では、整数 CPU リクエストを含む `Guaranteed` Pod に専用コアが割り当てられますが、ホストシステムサービスがそれらのコアを使用することを防ぐことはできません。`reservedSystemCPUs` 設定を追加すると、ホストシステムサービスが独自の予約済みコアに制限され、ワークロードの排他的コアが中断されるのを防ぐことができます。このタスクを実行するため、GKE はノードの起動時に `system.slice` cgroup を予約済みコアに自動的に固定します。システム CPU を予約すると、ノードの割り当て可能な容量全体が減少します。`Burstable` Pod と `BestEffort` Pod は、これらの予約済みコアで引き続き実行できますが、GKE DaemonSet からのフラクショナルリクエストを含む CPU リクエストは、ノードの割り当て可能な容量にカウントされます。排他的な `Guaranteed` ワークロードにはコア全体が必要なため、小さな小数リクエストでも、使用可能な排他的コアの数が減少します。 `reservedSystemCPUs` で十分な CPU コアを予約してください。予約するコア数が少なすぎると、高負荷時にホストシステムデーモンと OS プロセスが CPU の制約を受け、不安定になったり、ネットワークパケットがドロップしたりする可能性があります。

reservedSystemCPUs （プレビュー）

予約する特定の CPU コアのリストを指定する必要があります（たとえば、コア 0 と 1 を予約する場合は 0-1 または 0,1）。コアは 0 から始まるため、値はマシンタイプの vCPU 数より小さくする必要があります。

none

OS デーモンや kubelet サービスなどのホストシステムサービス用に特定の CPU コアを明示的に予約します。デフォルトでは、これらのサービスは任意の CPU コアで実行できます。これにより、CPU 負荷の高いワークロードでパフォーマンスの問題が発生する可能性があります。cpuManagerPolicy: static 設定では、整数 CPU リクエストを含む Guaranteed Pod に専用コアが割り当てられますが、ホストシステムサービスがそれらのコアを使用することを防ぐことはできません。reservedSystemCPUs 設定を追加すると、ホストシステムサービスが独自の予約済みコアに制限され、ワークロードの排他的コアが中断されるのを防ぐことができます。このタスクを実行するため、GKE はノードの起動時に system.slice cgroup を予約済みコアに自動的に固定します。

システム CPU を予約すると、ノードの割り当て可能な容量全体が減少します。Burstable Pod と BestEffort Pod は、これらの予約済みコアで引き続き実行できますが、GKE DaemonSet からのフラクショナルリクエストを含む CPU リクエストは、ノードの割り当て可能な容量にカウントされます。排他的な Guaranteed ワークロードにはコア全体が必要なため、小さな小数リクエストでも、使用可能な排他的コアの数が減少します。

reservedSystemCPUs で十分な CPU コアを予約してください。予約するコア数が少なすぎると、高負荷時にホストシステムデーモンと OS プロセスが 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 終了の最大猶予期間を秒単位で定義します。
`singleProcessOOMKill`	値は `true` または `false` にする必要があります。	cgroupv1 ノードの場合は `true`、cgroupv2 ノードの場合は `false`。	この設定では、コンテナ内のプロセスが個別に OOMkill されるか、グループとして OOMkill されるかを設定します。 GKE バージョン 1.32.4-gke.1132000、1.33.0-gke.1748000 以降で使用できます。

次の表に、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` シグナルの量を定義します。

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

allowedUnsafeSysctls

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

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

none

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

insecureKubeletReadonlyPortEnabled 値はブール値（true または false）にする必要があります。 false この設定により、クラスタ内の新しいノードプールごとに、安全でない 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、C4N、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、C4N、G2、G4、M3、N4

コンテナの再起動の遅延

この設定は、コンテナが CrashLoopBackOff 状態のときにコンテナの再起動を試行するまでの最大待機時間を制御します。この設定は、GKE バージョン 1.35 以降を実行している Standard ノードプールで構成できます。

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

`kubelet` 構成設定	制限事項	デフォルト設定	説明
`crashLoopBackOff.maxContainerRestartPeriod`	値は 5 分（`5m`）以下の正の期間にする必要があります。有効な時間単位は、`ns`、`us`（または `µs`）、`ms`、`s`、`m` のいずれかです。	`none`	コンテナの再起動でバックオフ遅延が発生する最大期間。再起動の間隔は、初期値からこの上限まで指数関数的に増加します。Kubernetes クラスタのデフォルトの最大上限は 5 分です。詳細については、構成可能なコンテナの再起動遅延をご覧ください。

GKE での Spot VM の正常な終了

次の表に、GKE の Spot VM の終了と正常なシャットダウン期間の変更可能なオプションを示します。これらのオプションを使用するには、クラスタのコントロールプレーンで GKE バージョン 1.35.0-gke.1171000 以降を実行する必要があります。詳細については、GKE での Spot VM の仕組みをご覧ください。

`kubelet` 構成設定	制限事項	デフォルト設定	説明
`shutdownGracePeriodSeconds`	値は、期間を秒単位で表す整数にする必要があります。指定できる値は `0`、`30`、`120` です。	`30`	Pod を正常に終了するためにノードがシャットダウンを遅らせる合計時間を秒単位で指定します。
`shutdownGracePeriodCriticalPodsSeconds`	値は `0`～`120` の整数（両端の値を含む）で、`shutdownGracePeriodSeconds` より小さくする必要があります。`shutdownGracePeriodSeconds` も設定されている場合にのみ有効です。	`15`	ノードのシャットダウン中にクリティカル Pod を終了するために使用される期間を秒単位で指定します。

システムリソースの予約

Linux と GKE 1.37 以降を実行する Standard ノードプールでは、システムコンポーネント用に予約されるメモリと CPU の量をカスタマイズできます。これにより、大量のイメージの pull の処理や、カスタマイズされたノード DaemonSet の実行など、特定のシナリオに合わせて割り当て可能な容量を微調整できます。デフォルトの予約の詳細については、GKE ノードのサイズ設定についてをご覧ください。

次の表に、システムリソース予約の変更可能なオプションを示します。

`kubelet` 構成設定	制限事項	デフォルト設定	説明
`reservedResourcesConfig.memoryReservedMib`	値は整数で指定してください。1.37 以降を実行して作成されたノードプールのデフォルトのメモリ予約以上で、ノードの合計メモリ容量の 50% 未満にする必要があります。	メモリの予約をご覧ください。	システムコンポーネント用に予約するメモリ量（メビバイト（MiB）単位）。
`reservedResourcesConfig.cpuReservedMillicore`	値は整数で指定してください。1.37 以降を実行して作成されたノードプールのデフォルトの CPU 予約以上で、ノードの合計 CPU 容量の 50% 未満にする必要があります。	CPU の予約をご覧ください。	システムコンポーネント用に予約する CPU の量（ミリコア単位）。

有効な予約を確認する

ノードプールに適用されているアクティブな予約を確認するには、effectiveMemoryReservedMib と effectiveCpuReservedMillicore の出力フィールドを調べます。

gcloud container node-pools describe POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --format="yaml(config.kubeletConfig.reservedResourcesConfig)"

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 をご覧ください。
`kernel.keys.maxbytes`	20,000 ～ 2,097,152 で指定してください。	この設定は、root 以外のユーザーがすべての鍵のペイロードセクションに保持できる最大バイト数を定義します。
`kernel.keys.maxkeys`	200 ～ 1,048,576 で指定してください。	この設定は、root 以外のユーザーが所有できる鍵の最大数を定義します。

ネットワークパラメータ（`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`	説明列から、サポートされている値のいずれかを指定する必要があります。	この設定は、クラスタで GKE Dataplane V2 が有効になっている場合はサポートされません。サポートされている次の値は、イメージのタイプによって異なります。 `Container-Optimized OS`: `reno`、`cubic`、`bbr`、`lp`、`htcp`（GKE バージョン 1.34.1-gke.3355001 以降で使用可能） `Ubuntu`: `reno`、`cubic`、`bbr`、`lp`、`htcp`、`vegas`、`dctcp`、`bic`、`cdg`、`highspeed`、`hybla`、`illinois`、`nv`、`scalable`、`veno`、`westwood`、`yeah`
`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 以降で使用できます。
`net.ipv4.neigh.default.gc_thresh1`	0 ～ 262, 144 で指定してください。	この設定は、ARP キャッシュに保持するエントリの最小数を定義します。エントリ数がこの設定を下回ると、ガベージコレクタは実行されません。この値を `0` に設定すると、キャッシュスラッシングが発生し、パフォーマンスが低下する可能性があります。
`net.ipv4.neigh.default.gc_thresh2`	512 ～ 524, 288 で指定してください。	この設定は、ARP キャッシュに保持するエントリのソフト最大数を定義します。ガベージコレクタは、エントリ数がこの値を超えてから 5 秒後にソフトガベージコレクションを開始します。
`net.ipv4.neigh.default.gc_thresh3`	1,024 ～ 1,048,576 で指定してください。	この設定は、ARP キャッシュに保持するエントリのハード最大数を定義します。ガベージコレクタは、エントリ数がこの設定を超えると常に実行されるように設計されています。

仮想メモリパラメータ（`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 を防止この設定は、メモリが 15 GB 未満のマシンではサポートされていません。
`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 の構成オプション

手動で事前に割り当てられた hugepage または自動的に割り当てられた透過的な hugepage を使用できます。

事前割り当てされた hugepage

ノードシステム構成ファイルを使用して、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、C4N、CT5E、CT5LP、CT6E、H3、M2、M3、M4、Z3、または Z4D のマシンタイプでのみ使用できます。

次の表に、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 は有効になりません。

Linux の正確な時刻同期オプション

正確な時刻同期や、その同期精度をモニタリングすることがワークロードにとって重要である場合、VM のクロックをホスト側のクロックと同期させるために、chrony と ptp_kvm を使用して「正確な時刻」を構成できます。正確な時刻同期は、GKE バージョン 1.36.0-gke.3241000 以降で使用できます。この構成は、サポートされている設定で 1 ミリ秒以内の精度を実現するように設計されています。サポートされているマシンタイプ、サポートされているオペレーティングシステム、サポートされているゾーンの詳細については、Compute Engine VM の正確な時刻を構成するをご覧ください。

次の表に、GKE で正確な時刻同期を構成するためのパラメータを示します。

Config パラメータ	サポートされる値	デフォルト値	説明
構成ファイル: `accurateTimeConfig.enablePtpKvmTimeSync` Terraform: `accurate_time_config.enable_ptp_kvm_time_sync`	`true` または `false`	`false`	この設定により、正確な時刻同期が可能になります。この機能は、特定のマシンタイプ、オペレーティングシステム、ゾーンでのみサポートされています。

正確な時刻同期を有効にすると、GKE は次の情報を収集してエクスポートします。

compute.googleapis.com/instance/clock_accuracy/ptp_kvm/nanosecond_accuracy 指標。VM ホストのクロックの UTC に対する精度を示します。
projects/PROJECT_ID/logs/chrony.tracking ログ。chrony のトラッキングログが含まれます。これらのログには、システムクロックのゲインや損失率などの情報が含まれます。

この情報を使用して、Cloud Monitoring でログベースの指標とダッシュボードを作成し、時刻同期のパフォーマンスと信頼性を分析できます。

たとえば、次の gke-clock-metric.json 構成では、ホストの最大クロックエラーのログベースの指標を定義しています。

{
  "name": "phc-clock-max-error",
  "description": "Maximum error of the VM clock from the host clock exposed by ptp_kvm",
  "filter": "resource.type=\"k8s_node\" AND log_id(\"chrony.tracking\")",
  "metricDescriptor": {
    "metricKind": "DELTA",
    "valueType": "DISTRIBUTION",
    "unit": "s",
    "labels": []
  },
  "valueExtractor": "REGEXP_EXTRACT(textPayload, \"^.*PHC0.* ([-\\\\d\\\\.eE]+)$\")",
  "bucketOptions": {
    "explicitBuckets": {
      "bounds": [
        0.0, 5.0E-7, 1.0E-6, 2.0E-6, 4.0E-6, 5.0E-6, 8.0E-6, 1.0E-5, 2.0E-5,
        1.0E-4, 0.001, 0.01, 0.1, 1.0
      ]
    }
  }
}

次の gke-metrics-dashboard.json 構成では、ログベースの指標と UTC 精度指標のエラーデータを集計する Monitoring ダッシュボードを定義します。

{
  "displayName": "Overall Clock Accuracy",
  "dashboardFilters": [],
  "labels": {},
  "mosaicLayout": {
    "columns": 48,
    "tiles": [
      {
        "width": 28,
        "height": 28,
        "widget": {
          "xyChart": {
            "dataSets": [
              {
                "plotType": "LINE",
                "targetAxis": "Y1",
                "timeSeriesQuery": {
                  "prometheusQuery": "(\n  histogram_quantile(1, sum by (le, node_name) (\n    increase(logging_googleapis_com:user_phc_clock_max_error_bucket{monitored_resource=\"k8s_node\"}[1m])\n  )) * 1000000000\n)\n+ on(node_name) group_left()\nlabel_replace(\n  compute_googleapis_com:instance_clock_accuracy_ptp_kvm_nanosecond_accuracy{monitored_resource=\"gce_instance\"},\n  \"node_name\", \"$1\", \"instance_name\", \"(.*)\"\n)\n",
                  "unitOverride": "ns"
                }
              }
            ],
            "chartOptions": {
              "displayHorizontal": false,
              "mode": "COLOR"
            },
            "thresholds": [],
            "yAxis": {
              "label": "Clock Accuracy",
              "scale": "LINEAR"
            }
          }
        }
      }
    ]
  }
}

Linux VFIO 構成オプション

次の表に、ノードで VFIO（仮想機能 I/O）を構成するパラメータを示します。VFIO を使用すると、安全で特権のないユーザー空間ドライバが I/O デバイスにアクセスできます。

Config パラメータ	制限事項	デフォルト値	説明
`nodeVfioConfig.dmaEntryLimit`	`65535`～`4194304` の整数を指定してください	`65535`	VFIO IOMMU タイプ 1 ドライバがコンテナにマッピングできる DMA エントリ（ページ）の最大数を指定します。この上限は、デバイスの直接アクセス用に固定できるホストメモリの合計量に影響します。これは、TPU や GPU などの高性能デバイスにとって重要です。この設定は、カーネルパラメータ `/sys/module/vfio_iommu_type1/parameters/dma_entry_limit` に対応します。大きなメモリ領域をマッピングするワークロードでは、より高い値が必要になる場合があります。 GKE バージョン 1.36.0-gke.3009000 以降で使用できます。

Linux ディスク I/O スケジューラの構成オプション

次の表に、ノードプールのディスク I/O スケジューラを構成するパラメータを示します。

Config パラメータ	サポートされる値	デフォルト値	説明
`diskIoScheduler.nodeSystemIoScheduler`	`mq-deadline`、`bfq`、`kyber`、`none`	Container-Optimized OS イメージの場合は `bfq`、Ubuntu イメージの場合は `none`	ノードシステムワークロードを実行するブートディスクまたはエフェメラルローカル SSD の I/O スケジューラを構成します。 GKE バージョン 1.36.0-gke.3009000 以降で使用できます。
`diskIoScheduler.nodeAttachedDiskIoScheduler`	`mq-deadline`、`bfq`、`kyber`、`none`	`none`	アタッチされたディスクの I/O スケジューラを構成します。 GKE バージョン 1.36.0-gke.3009000 以降で使用できます。

Linux カーネルのオーバーライドオプション

ノードシステム構成ファイルを使用して、カーネルコマンドラインや Multi-Gen LRU 設定など、特定の Linux カーネルパラメータをオーバーライドできます。これらの設定は、GKE バージョン 1.35.0-gke.1018000 以降を実行しているクラスタでサポートされています。

Linux カーネルのコマンドラインオプション

次の表に、変更可能なカーネルコマンドラインオプションを示します。

Config パラメータ	サポートされる値	説明
`specRstackOverflow`	`SPEC_RSTACK_OVERFLOW_OFF`	投機的リターンスタックオーバーフロー（SRSO）の緩和策を変更します。サポートされる値は `SPEC_RSTACK_OVERFLOW_OFF` のみです。
`initOnAlloc`	`INIT_ON_ALLOC_OFF`	カーネルコマンドラインの `init_on_alloc` パラメータを変更します。サポートされる値は `INIT_ON_ALLOC_OFF` のみです。

Multi-Gen LRU の構成オプション

次の表に、変更可能なマルチ世代 LRU オプションを示します。

Config パラメータ	サポートされる値	説明
`enabled`	`true`、`false`	マルチ世代 LRU を有効または無効にします。この設定は、キルスイッチを構成します。
`minTtlMs`	正の整数	省略可。マルチ世代 LRU の `min_ttl_ms` スラッシング防止値を構成します。

OS ファイルの構成オプション

ノードシステム構成ファイルを使用して、ノード上の特定の OS 構成ファイルにエントリを追加できます。これらの設定は、GKE バージョン 1.35.0-gke.1018000 以降を実行しているクラスタでサポートされています。

追加の /etc/hosts エントリ

このフィールドは、次の例のように /etc/hosts ファイルエントリを追加します。

linuxConfig:
  additionalEtcHosts:
    - ip: 1.2.3.4
      host: myownpersonaldomain.com
    - ip: 5.6.7.8
      host: otherpersonaldomain.com

追加の /etc/systemd/resolved.conf エントリ

このフィールドは /etc/systemd/resolved.conf ファイルエントリを追加します。このフィールドには、Key-Value ペアの配列を指定します。次のキーがサポートされています。

DNS
FallbackDNS
Domains
LLMNR
MulticastDNS
DNSSEC
DNSOverTLS
Cache
CacheFromLocalhost
DNSStubListener
DNSStubListenerExtra
ReadEtcHosts
ResolveUnicastSingleLabel
StaleRetentionSec

次の例では、2 つの DNS サーバー値（8.8.8.8 と 8.8.4.4）を DNS キーに追加し、ドメイン値（myownpersonaldomain.com）を Domains キーに追加しています。

linuxConfig:
  additionalEtcSystemdResolvedConf:
    - key: DNS
      value:
        - 8.8.8.8
        - 8.8.4.4
    - key: Domains
      value:
        - myownpersonaldomain.com

追加の /etc/resolv.conf エントリ

このフィールドには /etc/resolv.conf ファイルエントリが追加されます。このフィールドには、Key-Value ペアの配列を指定できます。次のキーがサポートされています。

nameserver
search
sortlist
options

次の例では、DNS サーバー値（1.1.1.1）を nameserver キーに、ドメイン値（myownpersonaldomain.com）を search キーに追加しています。

linuxConfig:
  additionalEtcResolvConf:
    - key: nameserver
      value:
        - 1.1.1.1
    - key: search
      value:
        - myownpersonaldomain.com

タイムゾーンの設定

timeZone フィールドは、ノードのタイムゾーンを設定します（例: America/Los_Angeles）。この設定は、GKE バージョン 1.35.0-gke.1018000 以降を実行しているクラスタでサポートされています。

次の例では、timeZone フィールドを America/Los_Angeles に設定しています。

linuxConfig:
  timeZone: America/Los_Angeles

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

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

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

始める前に

ノードシステム構成を追加する

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

ComputeClass を作成する

ComputeClass を選択するワークロードをデプロイする

ノードシステム構成に構成ファイルを使用する

構成ファイルを作成する

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

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

gcloud CLI

Terraform

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

gcloud CLI

Terraform

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

中断のないライブ アップデートを使用して更新する

ライブ情報の仕組み

ライブ情報の前提条件

ライブ アップデートを適用する

ライブ アップデートが失敗した場合の復元

完了したライブ アップデートを元に戻す

標準アップグレード戦略を使用して更新する

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

ComputeClass の場合

方法 1: 既存の ComputeClass を更新する

方法 2: 新しい ComputeClass を作成する

構成ファイルの場合

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

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

既存のノードシステム構成を取得する

既存のノードシステム構成をリセットする

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

ComputeClass の場合

構成ファイルの場合

kubelet の構成オプション

CPU 管理

メモリ管理と強制排除

PID の管理

ロギング

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

イメージの pull

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

リソース マネージャー

コンテナの再起動の遅延

GKE での Spot VM の正常な終了

システム リソースの予約

有効な予約を確認する

Sysctl 構成オプション

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

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

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

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

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

cgroup の構成を確認する

gcloud CLI

kubectl

Linux hugepages の構成オプション

事前割り当てされた hugepage

Transparent hugepages（THP）

Linux の正確な時刻同期オプション

Linux VFIO 構成オプション

Linux ディスク I/O スケジューラの構成オプション

Linux カーネルのオーバーライド オプション

Linux カーネルのコマンドライン オプション

Multi-Gen LRU の構成オプション

OS ファイルの構成オプション

追加の /etc/hosts エントリ

追加の /etc/systemd/resolved.conf エントリ

追加の /etc/resolv.conf エントリ

タイムゾーンの設定

次のステップ

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

中断のないライブアップデートを使用して更新する

ライブアップデートを適用する

ライブアップデートが失敗した場合の復元

完了したライブアップデートを元に戻す

`kubelet` の構成オプション

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

リソースマネージャー

システムリソースの予約

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

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

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

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

Linux カーネルのオーバーライドオプション

Linux カーネルのコマンドラインオプション