Autopilot Pod の実行時間を延長する

このページでは、Google Kubernetes Engine（GKE）でエビクションされる前に Pod の実行時間の延長をリクエストする方法について説明します。

GKE が開始した Pod の強制排除について

Pod の強制排除は、Kubernetes でワークロードを実行するうえで通常行われることです。GKE は、ノードの自動アップグレードや自動スケーリングなどのスケジュール設定されたイベント中にワークロードの強制排除を行うことで、ノードが最新の状態に保たれ、効率的なリソース使用のために最適化されます。デフォルトでは、イベントが発生するとすぐに GKE からコンテナに終了シグナルが送信されます。Kubernetes が Pod をエビクションするまでには猶予期間があります。ノードの自動アップグレードの場合、猶予期間は最大 1 時間です。スケールダウン イベントの場合、猶予期間は最大 10 分です。

Kubernetes には、PodDisruptionBudgets や停止の猶予期間など、コンテナがエビクションを適切に処理するために使用できる機能が組み込まれています。ただし、バッチキューやマルチプレーヤー ゲームサーバーなどの一部のワークロードは、エビクションを行う前により長い猶予期間が必要になります。GKE が開始したエビクションに対して GKE が設定しているデフォルトの猶予期間は、これらのワークロードに対して十分でない場合があります。このような場合、特定のワークロードのエビクションを最大 7 日間回避するように Autopilot に指示できます。

ユースケース

ワークロードの強制排除を回避するように GKE に指示する必要がある状況には、次のようなものがあります。

  • マルチプレーヤー ゲームサーバーを実行しており、サーバーが早期に終了した場合、プレーヤーがセッションから退出されてしまう。
  • 音声またはビデオ会議のソフトウェアを実行しており、サーバーが停止した場合、進行中の会議が中断されてしまう。
  • 完了までに時間を要するタスクを実行しており、早期のサーバー停止によって進行中の作業が失われてしまう。
  • 中断への耐性が低いステートフル サービスを実行しており、中断が発生する頻度を最小限に抑えたい。

料金

Pod の実行時間の延長は追加料金なしにリクエストできます。ただし、次の動作変更によって料金に影響が生じる可能性があります。

  • Autopilot クラスタは、期間が延長された Pod のリソース リクエストに対してより高い最小値を適用します。Autopilot クラスタでは、実行中の Pod のリソース リクエストに対して料金が請求されます。システムのオーバーヘッドや未使用のノード容量には料金は発生しません。
  • 期間が延長された Pod を使用すると、クラスタ内のノード数が増え、IP アドレスの使用量とスケーラビリティに影響する可能性があります。すべてのノードで実行される DaemonSet がある場合、クラスタ内の DaemonSet が増加します。

料金の詳細については、Autopilot の料金をご覧ください。

準備

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

  • Google Kubernetes Engine API を有効にする。
    • Google Kubernetes Engine API の有効化
  • このタスクに Google Cloud CLI を使用する場合は、gcloud CLI をインストールして初期化する。すでに gcloud CLI をインストールしている場合は、gcloud components update を実行して最新のバージョンを取得する。

制限事項

  • Spot Pod の実行時間の延長をリクエストすることはできません。
  • 延長時間を計算するときに、イメージの pull 時間がカウントされます。
  • 各クラスタには、最大 50 個の期間延長ワークロード（異なる CPU リクエスト）を設定できます。つまり、Autopilot リソースの最小値、比率、増分サイズチェックに合格すると、最大 50 種類の CPU リクエスト値が各クラスタで延長できます。
  • 期間が延長された Pod で Kubernetes の Pod 間アフィニティを使用することはできません。
  • 可能な限り、GKE は実行時間の長い Pod を独自のノードに配置します。これにより、使用率が低いノードでもスケールダウンが可能になります。

実行時間の延長をリクエストする

Pod の実行時間の延長をリクエストするには、Pod 仕様で Kubernetes の cluster-autoscaler.kubernetes.io/safe-to-evict アノテーションを false に設定します。

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

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: extended-pods
  labels:
    duration: extended
spec:
  selector:
    matchLabels:
      duration: extended
  template:
    metadata:
      annotations:
        cluster-autoscaler.kubernetes.io/safe-to-evict: "false"
      labels:
        duration: extended
    spec:
      containers:
      - name: example-container
        image: registry.k8s.io/pause
        resources:
          requests:
            cpu: 200m

  2. Deployment を作成します。

    kubectl create -f extended-deployment.yaml

Pod は、スケールダウンまたはノードの自動アップグレードが行われる前に少なくとも 7 日間実行され続けます。

考慮事項と推奨事項

この機能を使用する場合は、次の点を考慮してください。

  • 期間が延長された Pod は、優先度ベースの強制排除から保護されません。Kubernetes PriorityClasses を使用する場合は、次の方法を使用して優先度ベースの強制排除の可能性を最小限に抑えます。
    • 期間が延長された Pod で最も高い優先度の PriorityClass が使用されるようにして、他のユーザー Pod で延長期間中の Pod が強制排除されないようにします。
    • ワークロードの分離を使用して、長時間の Pod を他の Pod とは別に実行します。
  • システム Pod は最も高い優先度で実行され、延長期間中の Pod もエビクションできます。この可能性を最小限に抑えるため、GKE は期間が延長された Pod をスケジュールする前にノード上のシステム Pod をスケジュールします。
  • 期間が延長された Pod は、次の状況で早期に強制排除されることがあります。
    • 優先度の高いユーザー Pod 用のスペースを作成するための強制排除（優先度の高い PriorityClass を使用します）
    • Kubernetes システム コンポーネント用のスペースを作成するための強制排除
    • Pod が要求したよりも多くのメモリを使用する場合、kubelet メモリ不足による強制排除（OOMKill）
    • Compute Engine VM メンテナンス イベント。アクセラレータ最適化マシンタイプはライブ マイグレーションをサポートしていないため、これらのイベントの影響を受ける可能性が高くなります。
    • ノードの自動修復
    • ユーザーが開始したイベント（ノードのドレインなど）
  • Standard クラスタで cluster-autoscaler.kubernetes.io/safe-to-evict アノテーションを使用できますが、結果は同じではありません。Pod は、スケールダウン イベントが発生しても無期限に実行され、使用率の低いノードが削除され、ノードへの支払いは継続します。また、Pod は、ノードの自動アップグレードによる強制排除から保護されません。

次のステップ