多くのGKEクラスタでまだ使われていない機能、カスタムComputeClasses

私が実施するGKEクラスタレビューでは、ほぼ毎回同じパターンを目にします。単一のマシンタイプに紐づいた静的ノードプールが延々と並んでいるのです。汎用ワークロード用の n2-standard-8 プール、メモリを大量に消費するサービス用の n2-highmem-16 プール、昨年のコスト削減施策で誰かが作成したSpotプール、そして場合によってはGPUプール。ワークロードは、長年にわたって積み上げられてきた nodeSelector、taint、toleration、ノードアフィニティルールを通じてノードにスケジュールされています。

何かが変化するまでは、この構成でも回ります。そして崩れるきっかけは、たいてい次の3つのいずれかです。

• ゾーンの在庫切れ: 選択したマシンシリーズがゾーン内で不足します。Cluster Autoscalerは指定された特定のプールしかスケールできないため、同じゾーンで別のマシンファミリーに空きがあっても、Podは Pending のまま止まります。

• Spotプリエンプションの罠: 大規模なSpotプリエンプションが発生すると、ワークロードはオンデマンドのフォールバックプールに溢れます。容量が回復しても、ワークロードを能動的に戻す仕組みはないため、見込んでいたコスト削減は請求書に一向に現れません。

• マシン世代のアップグレード: N2からN4やC4への移行は、数週間がかりの運用作業になります。新しいプールのプロビジョニング、数十のリポジトリにまたがるHelmの値の更新、古いノードのドレイン、そして古いラベルをハードコードしたマニフェストがないことを祈る——という具合です。

GKEには、この3つすべてに対する答えがすでに用意されています。カスタムComputeClassesです。私が話をするお客様は、この機能を知らないか、Autopilot専用だと思い込んでいるかのどちらかです。実際にはそうではありません。カスタムComputeClassesはGKE 1.30.3-gke.1451000以降、AutopilotとStandardの両モードで利用でき、対象となるすべてのクラスタでデフォルトで有効になっています。

注目すべき最近の追加機能

この機能は直近数回のGKEマイナーバージョンで急速に進化しています。1年前にComputeClassesを検討して見送った方のために、特に取り上げたい変更点を挙げます。

重み付き優先度スコア (1.35.2-gke.1842000+)

リストの順序だけに頼るのではなく、ルールに1から1000までの明示的な priorityScore を定義できます。オールオアナッシングの仕組みで、クラス内のすべてのルールにスコアを付けるか、まったく付けないかのどちらかです。最大3つのルールが同じスコアを共有でき、GKEは同点のルールをまとめて評価し、Cluster Autoscalerがその中から選択します。

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: priority-rule-score-class
spec:
  nodePoolAutoCreation:
    enabled: true
  priorities:
  - machineFamily: e2
    spot: true
    priorityScore: 30
  - machineFamily: n2
    spot: true
    priorityScore: 20
  - machineFamily: t2d
    spot: true
    priorityScore: 20
  - machineFamily: n1
    spot: true
    priorityScore: 10
  whenUnsatisfiable: ScaleUpAnyway

この例では、N2とT2DのSpotは同等に優れた第2候補として扱われます。グループ化されたルールは自動スケーリングのレイテンシを増やす可能性があります。GKEが実行すべきシミュレーションが増えるため、範囲の狭い machineType ルールよりも範囲の広い machineFamily ルールのほうが影響は大きくなります。

ストレージの自動選択 (1.35.3-gke.1290000+)

マシン世代の混在には、以前はストレージのリスクが伴いました。各シリーズがサポートするディスクタイプが異なるためです(例えばN4はHyperdiskをサポートし、N2は標準PDに依存します)。現在ではディスクタイプを自動選択する StorageClass を使用でき、Podがどのマシンタイプに配置されても動作するディスクタイプをGKEが作成します。これにより、動的プロビジョニングを使うワークロードにとって、複数世代にまたがるフォールバックチェーンがはるかに安全になります。既存のディスクについては、クラス内のすべてのマシンシリーズがサポートするディスクタイプが引き続き必要です。

カスタムマシンシェイプ (1.33.2-gke.1111000+)

CPUとメモリの比率が定義済みシェイプに合わないワークロード向けに、n4-custom-8-20480 のようなカスタムシェイプを machineType に直接定義できます。

machineFamilyルールでのブートディスク設定 (1.34.1-gke.1431000+)

特定の machineType ルールだけでなく、柔軟な machineFamily ルールにも storage.bootDiskType と storage.bootDiskSize を定義できます:

priorities:
- machineFamily: n4
  spot: true
  minCores: 16
  minMemoryGb: 64
  storage:
    bootDiskType: hyperdisk-balanced
    bootDiskSize: 100

クラス内でのラベルとtaint (1.33.2〜1.34.1)

優先度ルールごとに nodeLabels と taints を宣言するか(ラベルは1.33.2-gke.1111000から、taintは1.33.4-gke.1350000から)、nodePoolConfig の下でグローバルに宣言できます(1.34.1-gke.3084002から)。ルールレベルとグローバルの値を重複させることはできません。これにより、ラベリングと分離の設定を、ハードウェアの選択と同じオブジェクトで管理できます。

システムワークロード向けのデフォルトクラス (1.33.1-gke.1788000+)

cloud.google.com/default-compute-class-non-daemonset ラベルを使うと、DaemonSet以外のPodにのみ適用されるデフォルトクラスをネームスペースに設定できます。GKEはこれを利用して、kube-systemやgmp-systemなどのネームスペースのシステムPodをユーザーのワークロードとは分離して実行します。このときDaemonSet Podにはクラスセレクタは付与されません。

カスタムデフォルトとAutopilotコンピューティングの併用 (1.34.1-gke.1829001+)

Autopilotクラスタでカスタムクラスをクラスタのデフォルトに設定すると、PodはデフォルトではAutopilotのコンテナ最適化プラットフォーム上で実行されなくなります。現在では、特定のPodに cloud.google.com/compute-class: autopilot ノードセレクタを追加することで、そのPodだけをAutopilotコンピューティングプラットフォームで実行できます。

その他の小さな追加機能

priorityDefaults(1.32.1-gke.1729000)を使えば、共通の値をルールごとに繰り返す代わりに一度だけ設定できます。nodeSystemConfig はkubeletとsysctlのチューニングをクラス内に取り込みます。コンパクトプレースメントとワークロードポリシーは、1.33.2-gke.1335000 以降のAutopilotで利用できます。

本番運用での注意点とエッジケース

ComputeClassesには制約があります。それは本番環境ではなく、設計レビューの段階で見つけておくべきものです。

• kube-schedulerは優先度ルールを認識しない: ComputeClassesが影響するのは自動スケーリングであり、kube-schedulerはこれを考慮しません。フォールバックノードにすでに空きがある場合、新しいPodは優先ノードよりも先にそこへ配置されることがあります。activeMigration.optimizeRulePriority を有効にすればフォールバックノードは徐々に置き換えられ、consolidationThreshold を厳しめにすれば低使用率のフォールバックノードはより早くドレインされます。

• 変更は将来の動作にのみ反映される: ComputeClassを編集しても、稼働中のノードは変わりません。メンテナンスウィンドウ中に既存ノードをcordonおよびdrainして、新しいルールの下で置き換えられるようにしてください。

• ステートフルワークロードにはアクティブマイグレーションを使わない: アクティブマイグレーションはPodを退避させますが、データは移動しません。ベストプラクティスガイドは、ステートフルワークロードが使用するクラスでは無効にするよう述べています。こうしたワークロードは専用のクラスに入れ、ディスクタイプの自動選択を使うか、使用するディスクタイプをすべてのマシンシリーズがサポートするようクラスを限定してください。

• ネームスペースのデフォルトは既存Podを移行しない: GKEがクラスセレクタを注入するのは、ネームスペースにラベルを付けた後に作成されたPodのみで、すでに稼働中のPodはそのまま残ります。デフォルトを設定した後はネームスペース内のワークロードを再起動し、再作成されたPodにセレクタが付与され、アクティブマイグレーションの対象になるようにしてください。クラスタレベルのデフォルトであれば、既存Podを直接移行できます。

• Podのチャーンが激しい場合は注意: Podの作成・削除レートが非常に高いクラスタでは、上位ルールのバックオフが切れる前にCluster Autoscalerが下位ルールを評価できず、Podが Pending のままになることがあります。このエッジケースに遭遇した場合は、統合の頻度を下げるか、アクティブマイグレーションを無効にしてください。

• 予約のフォールバック動作: AnyBestEffort の場合、一致する予約に空きがないと、GKEは次のルールに進む前に同じルールでオンデマンドノードを試みます。予約容量が満杯のときにすぐ次のルールへ移りたい場合は、affinity: Specific(名前付き予約の場合)または affinity: AnyThenFail を使用してください。

そのほかの細かな制約

1つのワークロードが選択できるComputeClassは1つだけで、手動作成した各ノードプールが所属できるクラスも1つだけです。Autopilotでは bootDiskType は pd-balanced のみをサポートします。クラス名を gke や autopilot で始めることはできません。前述の機能の多くは比較的新しいパッチバージョンを必要とするため、設計に組み込む前にリリースチャンネルを確認してください。

まとめ

クラスタがまだマシンタイプに固定されたノードプールで動いているなら、まずはステートレスなネームスペースを1つ選んで始めましょう。Spot優先のフォールバックチェーンを設定し、Podがフォールバックルールに配置される頻度と、アクティブマイグレーションがPodを戻しているかどうかを観察してください。

留意点として、ComputeClassが決めるのは作成するノードの種類であり、ノードのサイズはPodのリソースリクエストに依存します。machineFamily ルールの場合、Cluster Autoscalerは保留中Podのリクエスト合計に基づいてマシンサイズを選びます。リクエストが過大だと、マシンは大きくなり、ビンパッキングは悪化し、フォールバックのフットプリントも膨らみます。

ここでライトサイジングが効果を発揮します。PerfectScaleはワークロードのリクエストを継続的にライトサイジングするため、ComputeClassesが作成するノードはPodの実際の使用量に合ったものになります。Node Recommendations機能を使えば、優先度ルールに組み込むべき最もコスト効率の高いマシンファミリーを選べます。クラスタの支出を監査していて、こうしたフォールバック構成が実際にどう機能するか知りたい方は、ぜひデモを予約してください。

参考資料

• GKE ComputeClassesについて
• カスタムComputeClassesについて
• 組み込みComputeClassesについて
• ComputeClassesをPodにデフォルトで適用する
• ComputeClassesのベストプラクティス
• PerfectScaleドキュメント