GKE で Pod バースト機能を構成する

Autopilot Standard

---

このページでは、Google Kubernetes Engine（GKE）ノードで利用可能な容量のうち、未使用の容量にバーストするように Pod を構成する方法を説明します。

バースト機能とは

「バースト機能」とは、ノード上で当初のリクエストよりも多くのコンピューティング容量を一時的に使用する Pod の動作のことです。

Kubernetes では、Pod に対して特定の容量のリソース（CPU、メモリなど）をリクエストできます。これらのリクエストは Pod マニフェストで設定します。Kubernetes スケジューラは、これらのリソース リクエストに対応するのに十分な容量があるノードに Pod を配置します。

ワークロードによっては、リクエストされたリソースの 100% を実行時間全体にわたって使用するわけではありません。たとえば、起動中に大量の CPU を消費するワークロードの場合、そのワークロードの通常のオペレーションでは、それだけの量のリソースが必要にならないことが考えられます。このような場合は、ワークロードのリソース「上限」をリソース リクエストで指定した容量よりも大きい値に設定するか、上限を未設定にすることができます。GKE では、利用できる容量がある場合、ワークロードがリクエストで指定された容量よりも多くのリソースを一時的に使用できるようになっています。

このプロセスが GKE でどのように機能するかについて詳しくは、このページの GKE のバースト可能な容量をご覧ください。

Pod バースト機能のメリット

バースト機能は、リソース使用量の急増に対応するために、Pod が短時間だけ追加リソースを必要とする場合に役立ちます。シナリオの例としては、次のようなものがあります。

• 頻繁にアイドル状態になるワークロードのグループがあり、これらのワークロードが 1 秒あたりに送信するリクエスト数は少ないものの、トラフィックが急増することがあるため、リクエストを処理するために追加のリソースを利用できると役立つ場合。
• ワークロードの起動時に、そのワークロードの通常のオペレーションよりも多くのリソースが必要になる場合。
• プロビジョニングするコンピューティング容量の使用率を最大化する必要がある場合。

バースト機能を使用すると、Pod の通常の実行時に必要となるリソースのみをリクエストする一方で、必要に応じて Pod がそれよりも多くのリソースを消費できるようになります。バースト機能には次の利点があります。

• 運用コストの削減: ワークロードに想定されるピーク時のリソース消費に対処できるだけの容量をリクエストする必要はありません。それよりも少ない、定常時の容量をリクエストできます。Autopilot では Pod リソース リクエストの合計に対して料金が発生するため、運用コストが低くなります。
• リソース使用の効率化: Pod が未使用の容量にバーストするため、コンピューティングのアイドル容量を回避できます。支払った分のリソースのすべてがワークロードで使用される可能性が高くなります。
• パフォーマンスの向上: Pod が必要に応じて追加のリソースを使用できるため、Pod による受信リクエストの処理時間が短縮されたり、スケールアップ イベントでの Pod の起動時間が加速されたりします。

バースト機能を使用すべきでない状況

Kubernetes は、リクエストの容量を上回るリソース上限を指定する Pod に、Burstable サービス品質（QoS）クラスを割り当てます。Kubernetes がノード上のリソースを回収する必要がある場合、Burstable QoS が割り当てられた Pod は強制排除される可能性が高くなります。詳細については、Kubernetes ドキュメントの バースト可能な QoS クラスをご覧ください。

始める前に

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

• Google Kubernetes Engine API を有効にする。
Google Kubernetes Engine API の有効化
• このタスクに Google Cloud CLI を使用する場合は、gcloud CLI をインストールして初期化する。すでに gcloud CLI をインストールしている場合は、gcloud components update を実行して最新のバージョンを取得する。
  注: gcloud CLI がすでにインストールされている場合には、必ず compute/region と compute/zone のプロパティを設定してください。デフォルトのロケーションを設定することで、gcloud CLI のエラー（One of [--zone, --region] must be supplied: Please specify location など）を防止できます。

• バージョン 1.30.2-gke.1394000 以降で稼働している GKE Autopilot クラスタ、または任意のバージョンの GKE Standard クラスタがあることを確認します。新しいクラスタを作成するには、Autopilot クラスタの作成をご覧ください。

GKE でのバースト機能の可用性

ワークロードは次の状況でバーストする可能性があります。

バースト機能の可用性
GKE Autopilot モード	Performance コンピューティング クラスまたは Accelerator コンピューティング クラスを使用する Pod は、そのコンピューティング クラスをサポートする任意の GKE バージョンでバースト可能です。 他のコンピューティング クラスを使用する Pod やコンピューティング クラスを指定していない Pod では、クラスタが次の条件を両方とも満たしている場合にのみバースト機能を使用できます。 クラスタが GKE バージョン 1.26 以降で作成されている クラスタが GKE バージョン 1.30.2-gke.1394000 以降で稼働している この制限は、Autopilot クラスタではバースト機能に cgroup v2 が必要であることに起因します。cgroup v2 は、バージョン 1.26 以降で作成されたクラスタでのみ使用可能であるためです。
GKE Standard モード	Pod は任意の GKE バージョンでバースト可能です。

1.26 より前のバージョンで作成された後、1.29.2-gke.1060000 以降にアップグレードされた Autopilot クラスタでは、バースト機能はサポートされません。元のクラスタ バージョンを確認するには、次のコマンドを実行します。

gcloud container clusters describe CLUSTER_NAME \
    --location=LOCATION \
    --format="value(initialClusterVersion)"

出力に示されている GKE バージョンが 1.26 以降であることを確認します。

制限事項

• Autopilot ワークロードでは、CPU とメモリのリクエストに対してのみバースト機能を使用できます。

• Autopilot クラスタをサポート対象のバージョンにアップグレードすると、GKE はワーカーノードをアップグレードして、コントロール プレーンのバージョンに合わせます。バーストを有効にするには、コントロール プレーンを再起動する必要があります。これは、すべてのノードがサポート対象のバージョンを実行するようになった後に行う必要があります。コントロール プレーンは、スケーリング、アップグレード、メンテナンスなどのオペレーション中に、約 1 週間に 1 回、自動的に再起動されます。

  コントロール プレーンの再起動を手動でトリガーする場合は、次の操作を行います。

  1. すべてのノードでバージョン 1.30.2-gke.1394000 以降が実行されているかどうか確認します。

     kubectl get nodes
     

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

     NAME                                          STATUS   ROLES    AGE     VERSION
     gk3-ap-cluster-1-default-pool-18092e49-mllk   Ready    <none>   4m26s   v1.30.2-gke.1349000
     

     出力内のすべてのノードで、必須バージョンまたはそれ以降が表示されている必要があります。

  2. クラスタがすでに使用しているバージョンにコントロール プレーンを手動でアップグレードします。手順については、コントロール プレーンの手動アップグレードをご覧ください。

クラスタに接続する

次のコマンドを実行します。

gcloud container clusters get-credentials CLUSTER_NAME \
    --location=LOCATION

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

• CLUSTER_NAME: 既存のクラスタの名前。
• LOCATION: クラスタのロケーション。

バースト可能なワークロードをデプロイする

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

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: helloweb
     labels:
       app: hello
   spec:
     selector:
       matchLabels:
         app: hello
         tier: web
     template:
       metadata:
         labels:
           app: hello
           tier: web
       spec:
         containers:
         - name: hello-app
           image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0
           ports:
           - containerPort: 8080
           resources:
             requests:
               cpu: 250m
             limits:
               cpu: 350m
   

   このマニフェストには、バースト機能を有効にする次のフィールドがあります。

   • resources.requests: コンテナが機能するために必要となるリソース。この値は、定常時のコンテナに必要となる容量に設定します。
   • resources.limits: コンテナで使用できるリソースの最大容量。リクエストで指定した容量よりも高い上限を設定すると、ノードでその容量が利用可能な場合、Pod はこのフィールドで指定された上限までバーストできます。このフィールドを省略すると、Pod がバーストできる容量は、ノード上で利用可能な容量までとなります。この容量は次のように計算されます。
     • Autopilot モード: Pod のリソース リクエストで指定された容量の合計のうち、ノード上で未使用の容量。
     • Standard モード: ノード上のリソースのうち、未使用の容量。
   • spec.nodeSelector、spec.tolerations: 省略可。これらのフィールドに pod-type: "non-critical" などのカスタムラベルを追加して、バースト可能な Pod を実行する新しいノードを作成するように GKE に指示します。GKE は、新しく作成されたノードに taint を適用して、これらのノードで重要なワークロードといった他の Pod が実行されないようにします。Autopilot は、ワークロードの分離を使用する Pod に対して、より高い最小リソース リクエストを適用します。詳細については、GKE でワークロードの分離を構成すると Autopilot のリソース リクエストをご覧ください。

2. ワークロードをデプロイします。

   kubectl apply -f burstable-deployment.yaml
   

   ワークロードが起動するまでに数分かかることがあります。

3. Pod の QoS クラスを確認します。

   kubectl describe pod helloweb | grep -m 1 "QoS"
   

   次のような出力が表示されます。

   QoS Class: Burstable
   

成功: バースト可能な一連の Pod を作成して、クラスタ内の別々のノードに配置しました。

GKE でバースト可能な容量

Pod バースト機能を容易にするために、GKE はクラスタ内の各ノードのバースト可能な容量を計算します。これは各ノードで次のように計算されます。

• Autopilot クラスタ:

  • アクセラレータをリクエストする Pod、または特定のマシンシリーズをリクエストする Pod: ノードに割り当て可能なリソース容量。これは、ワークロードに使用できる容量です。詳細については、ノードの割り当て可能なリソースをご覧ください。
  • 他のすべての Pod: ノードの実際のリソース容量に関係なく、そのノード上のすべての Pod のリソース リクエストの合計。Pod が終了されると、バースト可能な容量はその Pod のリクエストで指定された容量にまで下がります。実行中の Pod で使用されていないバースト可能な容量の一部は、Pod のいずれかがバーストする必要がある場合にその Pod に割り当てることができます。

  Autopilot は、バースト可能な容量に事前定義されたバッファも追加します。これにより、ノード上でリクエストされた容量を超えてバーストするシステム Pod によって独自のバースト可能な Pod が影響されることはありません。

• Standard クラスタ: ノードで割り当て可能なリソース容量。これは、ワークロードに使用できる容量です。詳細については、ノードの割り当て可能なリソースをご覧ください。

バースト機能に関するベスト プラクティス

Pod バースト機能には次のベスト プラクティスを適用してください。

• 環境内で重要な機能を提供する Pod のリソース リクエストでは、上限と等しい値の容量を設定します。これにより、これらの Pod に Guaranteed Kubernetes サービス品質（QoS）クラスが割り当てられます。
• Kubernetes がノード上のメモリを回収する必要がある場合の強制終了に対処できる Pod でのみ、メモリのバースト機能を構成してください。
• 必ず、Pod が起動できるだけの十分なメモリ容量をリクエストします。起動要件への対処としてメモリのバースト機能に依存することはしないでください。
• バースト可能な Pod が CPU リクエストの倍数単位でバーストして重要なワークロードが中断されないようにするために、ワークロードの分離を使用して、バースト可能な Pod が重要な Pod と一緒に配置されないようにします。

Autopilot ノードのバースト可能な容量を最適化する

Autopilot は、バースト可能な容量を、特定のノード上のシステム Pod と DaemonSet Pod を含むすべての Pod のリソース リクエストの合計として計算します。ノードのバースト可能な容量を最適化するには、次の方法があります。ただし、バースト機能は追従型であり、保証されるものではありません。

• ノード上で特定のワークロードのバースト可能な容量を増やすには、Pod アフィニティを使用して、特定の Pod が同じノードに配置されるようにします。
• 常にすべてのノード上で特定のバースト可能な容量が利用可能になるようにするには、クラスタ内のすべてのノード上で実行される DaemonSet を作成します。

バースト機能の動作例

このセクションでは、次のバースト可能な Pod を含む Deployment の例を使用して、GKE Autopilot クラスタで Pod バースト機能がどのように動作するかを説明します。

• Pod 1 では 250m CPU をリクエストします。CPU の上限は設定していません。Pod 1 は 100m CPU を使用して稼働します。
• Pod 2 では 200m CPU をリクエストし、250m CPU の上限を設定しています。Pod 2 は 100m CPU を使用して稼働します。

両方の Pod は同じノード上で実行されます。ノード上のバースト可能な合計容量は 450m CPU（リソース リクエストの合計）です。それぞれの Pod は 100m CPU のみを使用して稼働します。つまり、ノードには 250m のバースト可能な容量が残っています。

トラフィックの急増が発生した次のシナリオを考えてみましょう。

• Pod 1 に 300m CPU が追加で必要なります。Pod 1 がバーストして使用できるのは、ノードに残っているバースト可能な容量である 250ｍ CPU です。これで、ノードにバースト可能な容量がなくなります。
• Pod 2 に 150m CPU が追加で必要になります。Pod 2 はバーストして 150m CPU を追加で使用できます。ノードに残っているバースト可能な容量が 100m CPU になります。
• Pod 2 に 200m CPU が追加で必要になります。Pod 2 がバーストして使用できるのは、150m CPU です。これにより、Pod 2 に使用されている CPU の合計は 250m になります。Pod 2 には 250m CPU の上限が設定されているため、この上限を超えてバーストすることはできません。

バースト可能な容量を超えるリソースを使用しようとする Pod に GKE が対処する方法

バースト可能な Pod がノード上のバースト可能な容量を超えるリソースを使用しようとすると、GKE は次のように対処します。

• CPU: CPU の使用がバースト可能な容量を超えると、GKE は一部のコンテナの CPU 使用率をスロットリングして、ノード上のすべてのコンテナがリクエストした CPU を取得できるようにします。
• メモリ: メモリ使用量がバースト可能な容量を超えると、GKE はコンテナを終了してノード上のメモリを回収します。GKE はまず、より低い QoS クラスが割り当てられた Pod 内でリソースを大量に消費するコンテナを終了します。

常に、通常の Pod のオペレーションに十分なメモリ容量をリクエストすることをおすすめします。メモリのバースト機能に依存してコンテナを正常に機能させようとすると、メモリが使用できない場合、コンテナが繰り返しクラッシュする可能性があります。

予備容量のプロビジョニングで Pod のバースト機能を使用する

オンライン ショップでの期間限定セールなど、将来のトラフィック量の多いイベントで Pod のスケーリングを高速化するための追加コンピューティング容量を予約するために、GKE ではアイドル状態の Pod をデプロイできます。同じノード上の他の Pod は、この予約された未使用の容量にバーストできるため、トラフィック量の多いイベントが行われる前でも容量がアイドル状態になることはありません。この容量は、さまざまな Kubernetes メカニズムを使用して予約できます。たとえば、PriorityClass の低い Pod をデプロイすることで予約できます。詳細については、迅速な Pod スケーリングのために追加のコンピューティング容量をプロビジョニングするをご覧ください。

GKE Standard クラスタでの Pod バースト機能

リクエストで指定した容量よりも高い上限を設定するか、上限を省略することで、GKE Standard クラスタでも Pod バースト機能がサポートされます。ただし、Standard クラスタでは、バースト機能をサポートできるだけのリソース容量を持つノードプールを作成して構成する必要があります。基盤となる Compute Engine VM の料金が発生することから、Standard クラスタでバースト可能な Pod の潜在的なコスト削減を実現するには、ノード計画と Pod の「ビンパッキング」をより慎重に行う必要があります。

Standard クラスタでは、次の点に注意してください。

• Kubernetes の強制終了または CPU スロットリングをトリガーする最大リソース消費量の上限は、ノード上の割り当て可能なリソース容量です。この値を決定するには、GKE Standard ノードサイズを計画するをご覧ください。

• GKE はリソース消費量を自動的に制限しないため、上限を指定しなければ、Standard クラスタのノードリソース使用量が Kubernetes のエビクションしきい値に達する可能性が高くなります。したがって、メモリにバーストする Pod は、Kubernetes のノードの必要性の排除によって終了される可能性が高くなります。

次のステップ

• 迅速な Pod スケーリングのために追加のコンピューティング容量をプロビジョニングする
• GKE Standard ワークロードのサイズ適正化を大規模に行う