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

容量バッファを構成する

Standard Autopilot

容量バッファは、Kubernetes CapacityBuffer CustomResourceDefinition（CRD）を使用して、クラスタの予備容量と事前プロビジョニングされた事前構成済みの容量の保留状態を事前に管理することで、重要なワークロードの応答性と信頼性を向上させます。容量バッファを使用すると、クラスタ内で未使用のノードキャパシティを一定量、明示的に定義できます。この予約容量により、Pod のスケジューリング時間を短縮できます。

優先度の高いワークロードを迅速にスケールアップする必要がある場合、新しいワークロードはノードのプロビジョニングを待たずに空き容量をすぐに使用できます。このアプローチにより、レイテンシが最小限に抑えられ、需要の急増時にリソースの競合が回避されます。

このページでは、容量バッファ（固定レプリカバッファ、リソース上限バッファ、割合ベースのバッファ）を構成する方法について説明します。

始める前に

作業を始める前に、次のタスクが完了していることを確認してください。

Google Kubernetes Engine API を有効にする。

Google Kubernetes Engine API を有効化

このタスクに Google Cloud CLI を使用する場合は、gcloud CLI をインストールして初期化します。gcloud CLI をインストール済みの場合は、gcloud components update コマンドを実行して最新のバージョンを取得します。以前のバージョンの gcloud CLI では、このドキュメントのコマンドを実行できない場合があります。
注: gcloud CLI がすでにインストールされている場合には、必ず compute/region プロパティを設定してください。主にゾーンクラスタを使用する場合は、代わりに compute/zone を設定します。デフォルトのロケーションを設定することで、gcloud CLI のエラー（One of [--zone, --region] must be supplied: Please specify location など）を防止できます。クラスタのロケーションが設定したデフォルトと異なる場合は、特定のコマンドでロケーションの指定が必要になることがあります。

次のバージョン要件を満たす GKE クラスタを作成するか、該当するクラスタへのアクセス権を取得します。
- アクティブバッファの場合は、Standard クラスタと Autopilot クラスタでバージョン 1.35.2-gke.1842000 以降を使用します。
- スタンバイバッファの場合は、Standard クラスタでバージョン 1.36.0-gke.2253000 以降を使用するか、カスタム ComputeClass を使用する Autopilot クラスタでバージョン 1.36.0-gke.2853000 以降を使用します。
Standard クラスタでノード自動プロビジョニングを有効にします。Autopilot クラスタでは、ノード自動プロビジョニングがすでに有効になっています。ノード自動プロビジョニングは省略可能ですが、アクティブバッファでは推奨され、スタンバイバッファでは必須です。

前提条件となる Kubernetes オブジェクトを作成する

CapacityBuffer を構成するには、必要なすべてのオブジェクト（CapacityBuffer 自体、PodTemplate やワークロードなどの追加リソース）を保持する Namespace が必要です。PodTemplate と CapacityBuffer は同じ Namespace に存在する必要があります。名前空間を作成することも、default 名前空間などの既存の名前空間を使用することもできます。

構成する CapacityBuffer のタイプに応じて、次のいずれかも必要になります。

PodTemplate: バッファ容量の 1 ユニットのリソース要件を定義します。CapacityBuffer オブジェクトで指定された構成は、Pod テンプレートを参照します。
ワークロード: CapacityBuffer オブジェクトで参照する既存のワークロード。このガイドでは、ワークロードの例として Deployment オブジェクトを使用しますが、容量バッファは次のいずれかのリソースタイプをサポートしています。
- デプロイ
- ReplicaSet
- StatefulSet
- ReplicationController
- ジョブ
- scale サブリソースを実装する CustomResourceDefinition（CRD）。
  
  注: カスタム CRD と 1.36.0-gke.2459000 より前の GKE バージョンを使用している場合は、クラスタオートスケーラーにスケールサブリソースの読み取り権限を手動で付与する必要があります。カスタムスケーラブルリソースの権限エラーをご覧ください。

このセクションでは、これらのオブジェクトの例を示します。容量バッファで構成するワークロードがすでに存在する場合は、容量バッファを適用するに進みます。

Kubernetes ワークロードの例を作成するには、次の操作を行います。

次のマニフェストを namespace.yaml として保存します。
```
apiVersion: v1
kind: Namespace
metadata:
  name: capacity-buffer-example
  labels:
    name: capacity-buffer-example
```
このマニフェストは、capacity-buffer-example という名前の Namespace を作成します。
省略可: カスタム ComputeClass で容量バッファを使用するには、次のマニフェストを custom-compute-class.yaml として保存します。
```
apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: ccc-example
spec:
  # Buffers are also created according to these priorities
  priorities:
  - machineFamily: n4
  - machineFamily: n4d
  - machineFamily: c4
  - machineFamily: c4d
  nodePoolAutoCreation:
    enabled: true
```
このマニフェストは、GKE がプロビジョニングするノードのコンピューティング優先度を定義して制御するカスタム ComputeClass を作成します。詳細については、カスタム ComputeClass をご覧ください。

注意: スタンバイバッファでカスタム ComputeClass を使用し、優先度の高いノードへのアクティブな移行（activeMigration.optimizeRulePriority: true）と優先度の高い Spot VM ルールを組み合わせると、GKE はスタンバイノードを Spot VM に段階的に移行します。一時停止された Spot VM は再開時にオンデマンド VM に変換できないため、この構成により、容量制約時にスタンバイノードが再開されないようにできます。詳細については、スタンバイバッファノードが再開に失敗するをご覧ください。

次のマニフェストを buffer-pod-template.yaml として保存します。

apiVersion: v1
kind: PodTemplate
metadata:
  name: buffer-unit-template
  namespace: capacity-buffer-example # the namespace must be the same namespace as the CapacityBuffer
template:
  spec:
    terminationGracePeriodSeconds: 0
    containers:
    - name: buffer-container
      image: registry.k8s.io/pause:3.9
      resources:
        requests:
          cpu: "1"
          memory: "1Gi"
        limits:
          cpu: "1"
          memory: "1Gi"
    # Optional: Using buffers with a custom ComputeClass /
    # controls the properties of the provisioned nodes.
    nodeSelector:
      cloud.google.com/compute-class: ccc-example

このマニフェストは、バッファ容量の 1 ユニット（1 CPU と 1Gi メモリ）のリソース要件を定義する PodTemplate を作成します。この構成では、GKE がバッファにプロビジョニングする容量ユニットのサイズを指定します。たとえば、この PodTemplate を使用すると、クラスタがスケールアップしても、GKE は 1 つ未満の CPU と 1 Gi の使用可能なリソースを持つノードをバッファの一部として考慮しません。

次のマニフェストを sample-workload-deployment.yaml として保存します。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: critical-workload-ref
  namespace: capacity-buffer-example # the namespace must be the same namespace as the CapacityBuffer
spec:
  replicas: 10
  selector:
    matchLabels:
      app: critical-workload
  template:
    metadata:
      labels:
        app: critical-workload
    spec:
      containers:
      - name: busybox
        image: busybox
        command: ["sleep", "3600"]
        resources:
          requests:
            cpu: 100m
      # Optional: Using buffers with a custom ComputeClass /
      # controls the properties of the provisioned nodes.
      nodeSelector:
        cloud.google.com/compute-class: ccc-example

このマニフェストは、10 個のレプリカを含むサンプルの Deployment を作成します。これは、次のセクションの割合ベースのバッファの例の参照オブジェクトです。

マニフェストをクラスタに適用します。

kubectl apply -f namespace.yaml -f custom-compute-class.yaml -f buffer-pod-template.yaml -f sample-workload-deployment.yaml

GKE がオブジェクトを作成したことを確認します。

kubectl get podtemplate -n capacity-buffer-example
kubectl get deployment critical-workload-ref -n capacity-buffer-example

出力は次のようになります。

NAME                   AGE
buffer-unit-template   1m

NAME                    READY   UP-TO-DATE   AVAILABLE   AGE
critical-workload-ref   10/10   10           10          1m

容量バッファを適用する

このセクションでは、ワークロードに適用できるさまざまなタイプの容量バッファの例を示します。

固定レプリカバッファを構成する

固定レプリカで CapacityBuffer を構成すると、PodTemplate に基づいて必要なバッファユニットの正確な数を指定できます。

固定レプリカを含むバッファを作成するには、次の操作を行います。

次のマニフェストを cb-fixed-replicas.yaml として保存します。
```
apiVersion: autoscaling.x-k8s.io/v1beta1
kind: CapacityBuffer
metadata:
  name: fixed-replica-buffer
  namespace: NAMESPACE
spec:
  podTemplateRef:
    name: POD_TEMPLATE
  replicas: 3
  provisioningStrategy: "STRATEGY"
```
次のように置き換えます。
- NAMESPACE: Namespace の名前（例: capacity-buffer-example）。
- POD_TEMPLATE: リソース要件を定義する PodTemplate（例: buffer-unit-template）。
- STRATEGY: プロビジョニング戦略（"buffer.x-k8s.io/active-capacity"（デフォルト）または "buffer.gke.io/standby-capacity"）。
このマニフェストは、PodTemplate を参照する CapacityBuffer リソースを作成し、特定の数のバッファユニットをリクエストします。
次のようにマニフェストを適用します。
```
kubectl apply -f cb-fixed-replicas.yaml
```
GKE が容量バッファを適用したことを確認します。
```
kubectl get capacitybuffer fixed-replica-buffer -n NAMESPACE
```
ステータスの replicas フィールドには、マニフェストで定義したレプリカの数を反映した 3 が表示されます。STATUS フィールドに ReadyForProvisioning が表示されます。

リソース上限バッファを構成する

limits フィールドを使用して、PodTemplate のサイズに基づいて計算される、バッファが消費するリソースの最大量を定義できます。

リソース上限バッファを作成する手順は次のとおりです。

次のマニフェストを cb-resource-limits.yaml として保存します。
```
apiVersion: autoscaling.x-k8s.io/v1beta1
kind: CapacityBuffer
metadata:
  name: resource-limit-buffer
  namespace: NAMESPACE
spec:
  podTemplateRef:
    name: POD_TEMPLATE
  limits:
    cpu: "5"
    memory: "5Gi"
  provisioningStrategy: "STRATEGY"
```
次のように置き換えます。
- NAMESPACE: Namespace の名前（例: capacity-buffer-example）。
- POD_TEMPLATE: リソース要件を定義する PodTemplate（例: buffer-unit-template）。
- STRATEGY: プロビジョニング戦略（"buffer.x-k8s.io/active-capacity"（デフォルト）または "buffer.gke.io/standby-capacity"）。
このマニフェストは、合計上限が 5 個の CPU と 5 GiB のメモリである CapacityBuffer リソースを作成します。前の手順の PodTemplate の例を使用している場合は、各ユニットを 1 CPU と 1Gi メモリとして定義します。これにより、5 つのバッファユニットが作成されます。
次のようにマニフェストを適用します。
```
kubectl apply -f cb-resource-limits.yaml
```
GKE が容量バッファを適用したことを確認します。
```
kubectl get capacitybuffer resource-limit-buffer -n NAMESPACE
```
CapacityBuffer のステータスを確認します。replicas フィールドには、定義した上限から導出された値が表示されます。前のセクションの PodTemplate の例を使用している場合は、5 バッファ単位が表示されます。これは、定義された上限内に収まる最大単位数です。

割合ベースのバッファを構成する

割合ベースのバッファを構成すると、既存のスケーラブルワークロードの割合に基づいてバッファのサイズが動的に設定されます。容量バッファの割合は、Deployment、StatefulSet、ReplicaSet、Job など、スケールサブリソースを実装する Kubernetes スケーラブルオブジェクトでのみサポートされます。Pod テンプレートには replicas フィールドがないため、Pod テンプレートのバッファを割合ベースで定義することはできません。

ほとんどの場合、割合ベースのバッファではなく、固定レプリカまたはリソース上限戦略から始めます。決定する際は、次の点を考慮してください。

ワークロードが少ない数またはゼロにスケーリングされると、アクティブな Pod に比例して安全マージンが減少するため、割合ベースのバッファは突然のスケールアップに対応しにくくなります。
スタンバイノードは、一時停止前の初期化期間中にコンピューティング料金が発生します。ワークロードの変動に合わせてスタンバイバッファを動的にスケーリングすると、コンピューティングリソースが無駄になります。代わりに、スタンバイバッファに固定レプリカまたはリソース上限を使用してください。
割合ベースのバッファは、レプリカ数が少なくならない大規模なデプロイのアクティブバッファに主に役立ちます。

GKE バージョン 1.36.3-gke.1244000 以降では、参照されるワークロードがスケールダウンしたときに最小バッファサイズを維持するには、replicas フィールドと percentage フィールドを設定します。GKE は、より多くのバッファユニットを生成するフィールドを使用します。バッファサイズを上限設定するには、limits フィールドも設定します。

たとえば、10 個のレプリカを持つ Deployment を参照する percentage: 20 と replicas: 3 を含むバッファについて考えてみましょう。10 個のレプリカの 20% は 2 で、replicas の値 3 よりも小さいため、GKE は 3 個のバッファユニットをプロビジョニングします。Deployment が 20 個のレプリカにスケールされると、バッファは 4 ユニットに増加します。詳細については、CapacityBuffer リファレンスドキュメントをご覧ください。

割合ベースのバッファを作成する手順は次のとおりです。

次のマニフェストを cb-percentage-based.yaml として保存します。
```
apiVersion: autoscaling.x-k8s.io/v1beta1
kind: CapacityBuffer
metadata:
  name: percentage-buffer
  namespace: NAMESPACE
spec:
  scalableRef:
    apiGroup: apps
    kind: Deployment
    name: SCALABLE_RESOURCE_NAME
  percentage: 20
  provisioningStrategy: "STRATEGY"
```
次のように置き換えます。
- NAMESPACE: 名前空間の名前。
- SCALABLE_RESOURCE_NAME: スケーラブルなリソースの名前（例: critical-workload-ref）。
- STRATEGY: プロビジョニング戦略（"buffer.x-k8s.io/active-capacity"（デフォルト）または "buffer.gke.io/standby-capacity"）。
このマニフェストは、参照先リソースのレプリカの 20% に相当するバッファサイズをリクエストする CapacityBuffer リソースを作成します。前のセクションの Deployment の例を使用している場合、レプリカの値は 10 に設定されます。

注: percentage フィールドを 100 より大きい値に設定すると、参照されるワークロードよりも大きいバッファを作成できます。GKE は、計算されたバッファレプリカ数を最も近い整数に切り上げます。参照されるワークロードに 0 個のレプリカがある場合、または percentage が 0 の場合は、最小値は 0 です。
次のようにマニフェストを適用します。
```
kubectl apply -f cb-percentage-based.yaml
```
GKE が容量バッファを適用したことを確認します。
```
kubectl get capacitybuffer percentage-buffer -n NAMESPACE
```
CapacityBuffer のステータスを確認します。replicas フィールドには、割合の計算値が表示されます。前のセクションの Deployment の例を使用している場合は、2 バッファユニットが表示されます。これは、Deployment で定義された 10 個のレプリカの 20% です。
Deployment を最大 20 個のレプリカに手動でスケーリングして、動的スケーリングをテストします。
```
kubectl scale deployment critical-workload-ref -n NAMESPACE --replicas=20
```
CapacityBuffer コントローラが反応し、バッファを 4 つのレプリカに自動的にスケーリングします。

スタンバイバッファの動作をカスタマイズする

アノテーションを使用すると、スタンバイバッファの開始と更新の方法をカスタマイズできます。これらのアノテーションを CapacityBuffer リソースの metadata.annotations フィールドに追加します。

buffer.gke.io/standby-capacity-init-time: GKE がノードを一時停止する前に、ノードが作成後にアクティブな状態を維持する時間。5m や 1h などの期間文字列を指定します。デフォルトは 5m です。
buffer.gke.io/standby-capacity-refresh-frequency: GKE が一時停止中のノードを更新する頻度。12h や 24h などの期間文字列を指定します。デフォルトは 24h です。

警告: buffer.gke.io/standby-capacity-refresh-frequency を 120h より長い期間に設定することはサポートされていません。現在、これはアドミッション警告の原因となりますが、今後の GKE リリースでは検証エラーが発生します。互換性を確保するには、120h 以下を使用するように構成を更新してください。

次の例は、スタンバイバッファの動作をカスタマイズするためのオプションフィールドを含むマニフェストを示しています。

apiVersion: autoscaling.x-k8s.io/v1beta1
kind: CapacityBuffer
metadata:
  name: customized-standby-buffer
  namespace: my-namespace
  annotations:
    buffer.gke.io/standby-capacity-init-time: "15m"
    buffer.gke.io/standby-capacity-refresh-frequency: "12h"
spec:
  podTemplateRef:
    name: buffer-unit-template
  replicas: 3
  provisioningStrategy: "buffer.gke.io/standby-capacity"

スタンバイバッファに画像をプリロードする

スタンバイノードが再開したときにワークロードの起動時間を短縮するには、DaemonSet を使用してコンテナイメージをプリロードします。DaemonSet は、ノードが一時停止される前の起動期間中に実行されます。

DaemonSet を使用してイメージをプリロードする手順は次のとおりです。

次のマニフェストを image-puller-daemonset.yaml として保存します。

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: image-prefetch-daemonset
  namespace: NAMESPACE
spec:
  selector:
    matchLabels:
      name: image-prefetch
  template:
    metadata:
      labels:
        name: image-prefetch
    spec:
      tolerations:
      - key: "buffer.gke.io/standby-capacity-node-suspended"
        operator: "Exists"
      initContainers:
      - name: image-puller
        image: IMAGE_NAME
        command: ["sh", "-c", "true"]
      containers:
      - name: pause
        image: registry.k8s.io/pause:3.9

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

NAMESPACE: DaemonSet の Namespace（例: capacity-buffer-example）。
IMAGE_NAME: プリロードするイメージの名前（例: your-app-image:latest）。

このマニフェストには buffer.gke.io/standby-capacity-node-suspended toleration が含まれているため、GKE がスタンバイノードを一時停止した後も、DaemonSet はスタンバイノードにスケジュールされたままになります。

DaemonSet マニフェストをクラスタに適用します。
```
kubectl apply -f image-puller-daemonset.yaml
```

DaemonSet が作成されていることを確認します。

kubectl get daemonset image-prefetch-daemonset -n NAMESPACE

容量バッファが作成され、プロビジョニングの準備ができていることを確認します。
```
kubectl get capacitybuffer CAPACITY_BUFFER_NAME -n NAMESPACE
```
ステータスを確認します。STATUS フィールドに ReadyForProvisioning が表示されます。

容量バッファのステータスとパフォーマンスをモニタリングする

容量バッファのステータスと健全性は、kubectl コマンドと Cloud Monitoring の指標を使用してモニタリングできます。

CapacityBuffer リソースのステータスを確認する

容量バッファの状態を確認し、ワークロードを受信する準備ができていることを確認するには、次の手順を完了します。

クラスタ全体のすべての容量バッファのステータスを取得します。
```
kubectl get capacitybuffer -A
```
特定のバッファの詳細なステータス、条件、イベントログを検査します。
```
kubectl describe capacitybuffer CAPACITY_BUFFER_NAME -n NAMESPACE
```

一時停止中のスタンバイバッファノードを特定する

スタンバイバッファ VM は事前プロビジョニングされますが、費用を削減するために一時停止状態に保たれます。これらの停止中のノードは、カスタム条件があるため識別できます。一時停止されたノードインスタンスを監査するには、次のコマンドを実行します。

kubectl get nodes -o custom-columns='NAME:.metadata.name,SUSPENDED:.status.conditions[?(@.type=="Suspended")].status'

True のステータスは、スタンバイ VM が一時停止していることを示します。ステータスが False または <none> の場合は、アクティブで実行中のノードを示します。

Cloud Monitoring を使用したパフォーマンスのモニタリング

容量バッファがスケールアップ時間に及ぼすエンドツーエンドの影響をモニタリングするには、 Google Cloud コンソールの [起動レイテンシ] ダッシュボードを使用します。[Pod の起動レイテンシの分布] グラフと [Pod の最初の準備完了までのレイテンシ] グラフを使用して、Pod の作成から準備完了までの kubernetes.io/pod/latencies/pod_first_ready 指標を追跡します。Cloud Logging で Scheduled イベントをクエリして、Pod のスケジューリングレイテンシを測定することもできます。手順については、起動レイテンシ指標をモニタリングするをご覧ください。

容量バッファを削除する

ワークロードの容量バッファが不要になった場合は、CapacityBuffer オブジェクトを削除します。これにより、プレースホルダ Pod が削除され、クラスタオートスケーラーがノードをスケールダウンできるようになります。

kubectl delete capacitybuffer CAPACITY_BUFFER_NAME -n NAMESPACE

CAPACITY_BUFFER_NAME は、削除する CapacityBuffer の名前に置き換えます。

トラブルシューティング

次のセクションでは、容量バッファに関する一般的な問題の解決方法について説明します。

課金モデルが原因で容量バッファの準備ができていません

Pod ベースの課金モデル（Pod ごとの課金）を使用するワークロードの CapacityBuffer を作成すると、容量バッファはプロビジョニングの準備が整いません。

この問題を特定するには、CapacityBuffer のステータスを確認します。

kubectl describe capacitybuffer BUFFER_NAME -n NAMESPACE

ステータスが False の ReadyForProvisioning タイプの条件を探します。

この問題を解決するには、CapacityBuffer がノードベースの課金に対応しているワークロードまたは PodTemplate を参照していることを確認します。

カスタムスケーラブルリソースの権限エラー

カスタムスケーラブルオブジェクトと連携するように CapacityBuffer を構成する場合（scalableRef フィールドを使用）、必要な権限がないと、クラスタオートスケーラーがバッファをスケーリングできないことがあります。この問題は、1.36.0-gke.2459000 より前の GKE バージョンでのみ発生します。

この問題を解決するには、次の例のように ClusterRole と ClusterRoleBinding を作成して、必要な権限を手動で付与します。

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: custom-scale-getter
rules:
- apiGroups: ["api.example.com"]
  resources: ["customreplicatedresources/scale"]
  verbs: ["get"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: ca-custom-scale-getter
subjects:
- kind: User
  name: "system:cluster-autoscaler"
  namespace: kube-system
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: custom-scale-getter

RBAC の構成の詳細については、Kubernetes RBAC のドキュメントをご覧ください。

バッファ Pod は、カスタム ComputeClass によってプロビジョニングされたノードでスケジュールされません

CapacityBuffer 構成の依存関係（PodTemplate など）でカスタム ComputeClass を選択すると、バッファ Pod が新しくプロビジョニングされたノードでスケジュールされないという問題が発生する可能性があります。この問題により、クラスタオートスケーラーは、アイドル状態のノードが削除されている間に、冗長なノードプールとノードを繰り返し作成します。

この問題は、カスタム ComputeClass が taint または特定のランタイム要件を持つノードをプロビジョニングし、バッファ Pod（または依存する PodTemplate）に一致する toleration または設定がない場合に発生します。

この問題を解決するには、必要な toleration、ノードセレクタ、またはランタイムクラスを指定するように CapacityBuffer 構成を更新します。たとえば、依存関係が GKE Sandbox で構成されたカスタム ComputeClass を選択する場合は、依存関係を更新して次のいずれかを行います。

spec.runtimeClassName: gvisor フィールドを指定します。
sandbox.gke.io/runtime=gvisor:NoSchedule taint の明示的な許容値を含めます。

詳細については、カスタム ComputeClass のドキュメントをご覧ください。

スタンバイバッファノードを再開できない

一時停止中のスタンバイバッファノードが再開されない理由としては、次のいずれかが考えられます。

一時停止したスタンバイノードを再開するには、ノードのマシンタイプと特定の CPU プラットフォーム世代（E2 マシンシリーズや N2 マシンシリーズなど）の Compute Engine 容量がゾーンで使用可能である必要があります。ゾーンにその構成に十分なコンピューティング容量がない場合、ノードは再開できません。詳細については、Compute Engine の一時停止と再開の制限事項をご覧ください。
カスタム ComputeClass で優先度の高いノードへのアクティブな移行（activeMigration.optimizeRulePriority: true）が有効になっており、Spot VM がオンデマンド VM よりも高い優先度に設定されている場合、GKE はオンデマンドスタンバイノードを Spot VM に移行します。Spot VM は容量の制約を受けやすく、一時停止された Spot VM は再開時にオンデマンド VM に変換できないため、これらの制約により、スタンバイノードが再開できなくなる可能性があります。
ノードを再開すると、プロジェクトの Compute Engine の割り当てを超過します。詳細については、割り当て上限により容量バッファをプロビジョニングできないをご覧ください。

スタンバイノードが再開できなかった理由を特定するには、ログエクスプローラで Compute Engine 監査ログをクエリして、compute.instances.resume オペレーションの ZONE_RESOURCE_POOL_EXHAUSTED エラーまたは QUOTA_EXCEEDED エラーを確認します。

この問題を解決または軽減するには、次のいずれかを行います。

リージョンクラスタを使用して、クラスタオートスケーラーが複数のゾーンにノードをプロビジョニングまたは再開できるようにします。
カスタム ComputeClass の spec.priorities リストで複数のマシンファミリーを構成します。一時停止したノードを再開できない場合、クラスタオートスケーラーは、別の優先度ルールに基づいて新しいノードの作成にフォールバックできます。これらの新しいノードは、再開されたスタンバイノードよりも準備に時間がかかります。この構成では、一時停止したノードは元のマシンタイプでのみ再開できるため、一時停止したノードの再開はできません。
オンデマンド VM で専用のカスタム ComputeClass を使用するか、スタンバイバッファで使用する ComputeClass の activeMigration.optimizeRulePriority フィールドを false に設定します。
スタンバイバッファを小さなアクティブバッファと組み合わせて、トラフィックの急増を吸収します。

割り当て上限に達したため、容量バッファをプロビジョニングできない

容量バッファが Kubernetes ResourceQuotas または Compute Engine の割り当てを超えると、リクエストされたレプリカ数よりも少ないレプリカがプロビジョニングされるか、スケールアップに失敗する可能性があります。

バッファを制限している割り当てを特定するには、次の割り当てを 1 つ以上確認します。

Namespace の Kubernetes ResourceQuota がバッファを制限しているかどうかを確認します。
```
kubectl describe capacitybuffer \
    CAPACITY_BUFFER_NAME \
    -n NAMESPACE
```
status.conditions の出力で、ステータスが True の LimitedByQuotas 条件を探します。アクティブバッファユニットとスタンバイバッファユニットの両方（一時停止中のスタンバイノードをバックアップするユニットを含む）は、バッファ Pod が実行されているかのように、Namespace の ResourceQuota の上限にカウントされます。バッファが Namespace の割り当てを超えると、GKE は status.replicas フィールドを上限値に設定して、使用可能な割り当て内に収めます。
Compute Engine プロジェクトの割り当てがノードのプロビジョニングをブロックしているかどうかを確認します。ログエクスプローラで、container.googleapis.com/cluster-autoscaler-visibility ログで no.scale.up.nap.quota.exceeded イベントを検索するか、Compute Engine 監査ログで QUOTA_EXCEEDED エラーを検索します。

スタンバイバッファの Compute Engine 割り当てを確認するときは、vCPU とメモリの割り当てに加えて、次の両方の割り当てを確認します。
- 一時停止したスタンバイノードは内部 IP アドレスと外部 IP アドレスを保持するため、使用中の IP アドレスの割り当てが消費されます。
- スタンバイ VM を一時停止すると、Compute Engine はノードのメモリをディスクに書き込みます。これにより、ノードのメモリサイズに比例して Persistent disk standard (GB) ディスク割り当てが消費されます。

割り当て上限を解決するには、次のいずれかを行います。

バッファの Namespace で Kubernetes ResourceQuota を増やします。
Compute Engine の割り当ての調整をリクエストする。
CapacityBuffer マニフェストの replicas、limits、または percentage の値を減らします。

次のステップ

容量バッファの詳細を確認する。
CapacityBuffer CRD のドキュメントをご覧ください。