いいとこ取り:GKE StandardクラスタでAutopilotモードのワークロードを実行する

Standardのみ、あるいはAutopilotのみで運用する組織がぶつかりがちな課題と、なぜどちらか一方では不十分なのかを整理します。

• Standardクラスタの運用負荷: 完全な制御権を握れる一方で、スケーリング、メンテナンス、セキュリティの責任もすべて自分たちで担うことになります。小規模なチームには重荷になりがちです。
• Autopilotクラスタの柔軟性の制約: マネージド運用の恩恵が得られる反面、最小リソースリクエスト、特定のOSイメージ、ノード構成の制限など、さまざまな制約も伴います。
• コストと請求の問題: Standardクラスタでは、ワークロードが利用可能なリソースを使い切っているかどうかにかかわらず、ノードプールを構成する仮想マシン(VM)の料金が発生します。管理を怠ると、過剰プロビジョニングによるムダなコストにつながりかねません。

こうした事情から、多くの組織はStandardモード(柔軟だがメンテナンス負荷が大きい)とAutopilotモード(運用は楽だが制御性に欠け制約が多い)のいずれかを選ばざるを得ませんでした。ワークロードが混在する現場では、どちらも決め手に欠けるケースが少なくありません。

GKEの「Autopilot ComputeClasses in Standard Clusters」は、ComputeClasses(マシンタイプや機能設定など、ノード構成のリストを定義するKubernetesのカスタムリソース)を活用してハイブリッドモデルを実現する仕組みです。柔軟性が一段引き上がり、いくつもの大きなメリットが得られます。

StandardでのAutopilotモードは、低レイテンシと高パフォーマンスを追求して設計された、新しいコンテナ最適化コンピュートプラットフォームを基盤としています。これにより、Podのスケジューリングが最大7倍高速化され、Autopilot ComputeClassesを利用するワークロードのアプリケーション応答時間が大きく改善されます。

主なメリットは次のとおりです。

• 特定のワークロードを、Googleが完全管理するAutopilotモードで実行できます。
• 手動で作成したノードプールなど、Autopilotモードを使わないワークロードやインフラについては、これまでどおり手動で制御できます。
• Autopilot ComputeClassをクラスタや名前空間のデフォルトに設定すれば、明示的な指定がない限り、ワークロードが自動的にAutopilotの恩恵を受けられます。

要件と制限事項

魅力を感じたら、StandardクラスタでAutopilotワークロードを有効化する前に要件と制限事項を必ず確認してください。

• Autopilotノードには厳格な機能・セキュリティ要件が課されます。Standardのワークロードがこれらの要件を満たさない場合は拒否されることがあるため、ノード設定を確認して互換性を担保してください。
• クラスタはRapidリリースチャンネルに登録されており、バージョン1.33.1-gke.1107000以降である必要があります。
• Rapidリリースは新機能や新しいKubernetesバージョンをいち早く取り込めますが、破壊的変更が含まれることもあります。クラスタをアップグレードする前に、APIなどの変更点を確認して必要に応じて対応してください。
• 標準のシステムPodを実行できるよう、クラスタ内にnode taintのないノードプールが少なくとも1つ必要です。
• クラスタはVPCネイティブで、Shielded GKE Nodesがデフォルトで有効になっている必要があります。

ビルトインのAutopilot ComputeClasses

クラスタを対応バージョンにアップグレードすると、GKEがautopilotとautopilot-spotのComputeClassesカスタムリソースを自動的に構成します。

Autopilot ComputeClassesのサンプル

ワークロードでAutopilot ComputeClassを指定するには、cloud.google.com/compute-classラベルを対象としたノードセレクタを使います。

#Sample workload that uses built-in autopilot ComputeClass
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: helloweb
  labels:
    app: hello
spec:
  selector:
    matchLabels:
      app: hello
  template:
    metadata:
      labels:
        app: hello
    spec:
      nodeSelector:
        # Replace COMPUTE_CLASS with the name of the compute class to use.
        cloud.google.com/compute-class: COMPUTE_CLASS
      containers:
      - name: hello-app
        image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0
        ports:
        - containerPort: 8080
        resources:
          requests:
            cpu: "250m"
            memory: "4Gi"

コンテナのリソースはAutopilotの要件に合わせて自動的に調整され、コンテナ最適化コンピュートプラットフォームのノード上にスケジュールされます。

カスタムComputeClasses

ビルトインのComputeClassesで要件を満たせない場合は、特定のワークロード向けにカスタムAutopilot ComputeClassesを作成できます。GPUや特定のマシンファミリーを必要とするワークロードでは特に有効です。

すでにカスタムComputeClassを使用している場合、既存のComputeClassリソースをAutopilotモードに切り替えるには、更新後の仕様で再作成する必要があります。詳細は既存のカスタムComputeClassでAutopilotを有効にするを参照してください。

#sample custom ComputeClass with autopilot mode enabled
---
apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: autopilot-n2-class
spec:
  autopilot:
    enabled: true
  priorities:
  - machineFamily: n2
    spot: true
    minCores: 64
  - machineFamily: n2
    spot: true
  - machineFamily: n2
    spot: false
  activeMigration:
    optimizeRulePriority: true
  whenUnsatisfiable: DoNotScaleUp

独自のComputeClassesではpodFamily優先度ルールは利用できません。このルールはビルトインのAutopilot ComputeClassesでのみ使用可能です。

Autopilotモードを有効化したカスタムComputeClassesは、GKEクラスタ単位または名前空間単位でデフォルトのコンピュートクラスとして設定できます。設定したデフォルトクラスは、そのクラスタまたは名前空間内で別のコンピュートクラスを指定していないすべてのPodに適用されます。コンピュートクラスを指定せずにPodをデプロイすると、GKEは次の順序でデフォルトのコンピュートクラスを適用します。

1. 名前空間にデフォルトのコンピュートクラスが設定されていれば、GKEはそのコンピュートクラスを選択するようPodの仕様を書き換えます。
2. 設定されていない場合、クラスタのデフォルト設定があればそれが適用され、GKEはPodを変更しません。

詳細はこちらのリンクを参照してください。