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 は、ノードの自動アップグレードによるエビクションから保護されません。

次のステップ