容量バッファを構成する

Capacity Buffer は、Kubernetes CapacityBuffer カスタム リソース定義を使用してクラスタ内の予備キャパシティを先回りして管理することで、重要なワークロードの応答性と信頼性を向上させます。Capacity Buffer を使用すると、クラスタ内で未使用のノード キャパシティを一定量、明示的に定義できます。 この予約済みキャパシティにより、GKE は事前にノードをプロビジョニングできます。

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

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

始める前に

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

  • Google Kubernetes Engine API を有効にする。
  • Google Kubernetes Engine API の有効化
  • このタスクに Google Cloud CLI を使用する場合は、gcloud CLI をインストールして初期化する。gcloud CLI をインストール済みの場合は、gcloud components update コマンドを実行して最新のバージョンを取得します。以前のバージョンの gcloud CLI では、このドキュメントのコマンドを実行できない場合があります。
  • バージョン 1.35.2-gke.1842000 以降の GKE クラスタを作成するか、アクセスできるようにします。
  • (省略可、推奨)クラスタでノード自動プロビジョニングを有効にします。
  • スタンバイ バッファを使用するには、次の GKE バージョンでクラスタを作成する必要があります。

    gcloud container clusters create CLUSTER_NAME \
        --region=COMPUTE_REGION \
        --cluster-version=1.35.2-gke.1842002 \
        --release-channel=None
    

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

    • CLUSTER_NAME: 新しいクラスタの名前。
    • COMPUTE_REGION: 新しいクラスタの Compute Engine のリージョン(us-central1 など)。

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

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

構成する CapacityBuffer のタイプに応じて、次のいずれかが必要です。

  • PodTemplate: バッファ キャパシティの単一ユニットのリソース要件を定義します。CapacityBuffer オブジェクトで指定された構成は、Pod テンプレートを参照します。
  • ワークロード: CapacityBuffer オブジェクトで参照する既存のワークロード。このガイドでは、Deployment オブジェクトをワークロードの例として使用しますが、Capacity Buffer は次のリソースタイプをサポートしています。

    • デプロイ
    • ReplicaSet
    • StatefulSet
    • ReplicationController
    • ジョブ
    • scale サブリソースを実装する CustomResourceDefinitions(CRD)。

このセクションでは、これらのオブジェクトの例を示します。Capacity Buffer で構成するワークロード がすでにある場合は、 Capacity Buffer を適用するに進んでください。

Kubernetes ワークロードの例を作成する手順は次のとおりです。

  1. 次のマニフェストを namespace.yaml として保存します。

    apiVersion: v1
    kind: Namespace
    metadata:
      name: capacity-buffer-example
      labels:
        name: capacity-buffer-example
    

    このマニフェストは、capacity-buffer-example という Namespace を作成します。

  2. 次のマニフェストを 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"
    

    このマニフェストは、バッファ キャパシティの単一ユニット(1 CPU と 1Gi メモリ)のリソース要件 を定義する PodTemplate を作成します。この構成では、GKE がバッファ用にプロビジョニングするキャパシティ ユニットのサイズを指定します。たとえば、この PodTemplate を使用すると、クラスタがスケールアップした場合、GKE は 1 CPU と 1 GiB 未満の利用可能なリソースを持つノードをバッファの一部と見なしません。

  3. 次のマニフェストを 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
    

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

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

    kubectl apply -f namespace.yaml -f buffer-pod-template.yaml -f sample-workload-deployment.yaml
    
  5. 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
    

Capacity Buffer を適用する

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

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

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

固定レプリカでバッファを作成する手順は次のとおりです。

  1. 次のマニフェストを 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 リソースを作成します。

  2. 次のようにマニフェストを適用します。

    kubectl apply -f cb-fixed-replicas.yaml
    
  3. GKE が Capacity Buffer を適用したことを確認します。

    kubectl get capacitybuffer fixed-replica-buffer -n NAMESPACE
    

    ステータスの replicas フィールドに 3 が表示されます。これは、マニフェストで定義したレプリカの数を反映しています。STATUS フィールドに ReadyForProvisioning が表示されます。

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

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

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

  1. 次のマニフェストを 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: Namespace の名前。
    • SCALABLE_RESOURCE_NAME: スケーラブル リソースの名前(critical-workload-ref など)。
    • STRATEGY:プロビジョニング戦略("buffer.x-k8s.io/active-capacity"(デフォルト)または "buffer.gke.io/standby-capacity")。

    このマニフェストは、参照リソースのレプリカの 20% に相当するバッファサイズをリクエストする CapacityBuffer リソースを作成します。前のセクションの Deployment の例を使用している場合、レプリカの値は 10 に設定されます。

  2. 次のようにマニフェストを適用します。

    kubectl apply -f cb-percentage-based.yaml
    
  3. GKE が Capacity Buffer を適用したことを確認します。

    kubectl get capacitybuffer percentage-buffer -n NAMESPACE
    

    CapacityBuffer のステータスを確認します。replicas フィールドに、割合の計算値が表示されます。前のセクションの Deployment の例を使用している場合は、2 バッファ ユニットが表示されます。これは、Deployment で定義された 10 個のレプリカの 20% です。

  4. Deployment を 20 個のレプリカに手動でスケーリングして、動的スケーリングをテストします。

    kubectl scale deployment critical-workload-ref -n NAMESPACE --replicas=20
    

    CapacityBuffer コントローラが反応し、バッファが 4 個のレプリカに自動的にスケーリングされます。

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

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

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

  1. 次のマニフェストを 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 個のバッファ ユニットが作成されます。

  2. 次のようにマニフェストを適用します。

    kubectl apply -f cb-resource-limits.yaml
    
  3. GKE が Capacity Buffer を適用したことを確認します。

    kubectl get capacitybuffer resource-limit-buffer -n NAMESPACE
    

    CapacityBuffer のステータスを確認します。replicas フィールドに、定義した上限から派生した値が表示されます。前のセクションの PodTemplate の例を使用している場合は、5 バッファ ユニットが表示されます。これは、定義された上限内に収まるユニットの最大数です。

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

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

  • buffer.gke.io/standby-capacity-init-time: 作成後にノードが一時停止するまでアクティブな状態を維持する時間。形式は期間文字列(5m1h など)です。デフォルトは 5m です。
  • buffer.gke.io/standby-capacity-refresh-frequency: 一時停止したノードが更新される頻度。デフォルトは 1d です。

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

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 を使用してイメージをプリロードする手順は次のとおりです。

  1. 次のマニフェストを 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-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 など)。
  2. DaemonSet マニフェストをクラスタに適用します。

    kubectl apply -f image-puller-daemonset.yaml
    
  3. DaemonSet が作成されたことを確認します。

    kubectl get daemonset image-prefetch-daemonset -n NAMESPACE
    
  4. Capacity Buffer が作成され、プロビジョニングの準備ができていることを確認します。

    kubectl get capacitybuffer CAPACITY_BUFFER_NAME -n NAMESPACE
    

    ステータスを確認し、STATUS フィールドに ReadyForProvisioning が表示されます。

Capacity Buffer を削除する

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

kubectl delete capacitybuffer CAPACITY_BUFFER_NAME -n NAMESPACE

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

トラブルシューティング

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

課金モデルが原因で Capacity Buffer の準備ができていない

Pod ベースの課金モデル (Pod ごとの料金)を使用するワークロードの CapacityBuffer を作成した場合、Capacity Buffer はプロビジョニングの準備ができていません。

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

kubectl describe capacitybuffer BUFFER_NAME -n NAMESPACE

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

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

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

カスタム スケーラブル オブジェクト(scalableRef フィールドを使用)と連携するように CapacityBuffer を構成すると、必要な権限がない場合、クラスタ オートスケーラーがバッファをスケーリングできないことがあります。

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

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 のドキュメントをご覧ください。

次のステップ