Kubernetes v1.37（Garhwal）：新機能と改善点を総まとめ

TL;DR

Kubernetes v1.37（「Garhwal」）には67件の機能強化が含まれています。内訳はStableが16件、Betaが23件、Alphaが27件、削除が1件です。目玉となる変更は、initコンテナおよびサイドカーコンテナのインプレースリサイズ（GA）、HPA許容値の設定（GA）、node declared features（GA）、HorizontalPodAutoscalerのゼロスケール（Beta）、Memory QoS（Beta）、Pod単位のリソースマネージャー（Beta）、新しいWorkload APIによるギャングスケジューリング（Beta）、そしてKubeletのrootlessモード（Beta）です。Alphaには、協調的なEviction Request APIやPod単位のチェックポイント/リストアに加え、Dynamic Resource Allocation（DRA）の継続的な進展も含まれます。要対応事項：本リリースではSELinuxマウントのラベル付けがデフォルトで変更され、SELinuxが有効なクラスターでは既存のワークロードが動作しなくなる可能性があります。

Kubernetes v1.37（コードネーム「Garhwal」）は、リソース管理、オートスケーリング、スケジューリングを重視するチームにとって見どころの多いリリースです。今回のリリースには67件の機能強化が含まれており、16件がStable（GA）、23件がBeta、27件がAlphaになり、1件が削除されました。名前の由来はインド・ウッタラーカンド州のヒマラヤ地域「Garhwal（ガルワール）」です。段々畑から山あいの渓流まで、層が互いにつながり支え合うというテーマは、過去のバージョンの成果の上に積み重ねていく今回のリリースにぴったりです。

Kubernetes v1.37で私たちが特に注目している機能は、initコンテナおよびサイドカーコンテナのインプレースリサイズ、HorizontalPodAutoscalerのゼロスケール、Memory QoS、そしてWorkload APIによるネイティブなギャングスケジューリングです。これらの多くは、リソースの有効活用、実需要に基づくスケーリング、密結合なワークロードの配置において、Kubernetesをより優れたものにします。

Kubernetes v1.37の主な変更点は以下のとおりです。

Kubernetes v1.37のStable機能

1. Initコンテナとサイドカーコンテナのインプレースリサイズ

機能グループ: SIG Node | KEP: #1287

インプレースのPodリサイズはKubernetes v1.35でStable（GA）になりました。v1.37では、このサポートがinitコンテナとサイドカーコンテナに拡張され、この部分もGAとなっています。

この変更以前は、実行中のアプリコンテナのCPUとメモリは再起動なしでリサイズできましたが、initコンテナとサイドカーコンテナは対象外でした。サイドカーコンテナとはrestartPolicy: Alwaysを指定したinitコンテナのことで、Podのライフサイクル全体を通じて実行されます。サイドカーにより多くのCPUやメモリが必要になった場合、現実的な選択肢はPodの再作成しかありませんでした。つまり、変更が必要なのはサイドカーだけであっても、メインアプリにもダウンタイムが発生していました。

v1.37では、InPlacePodVerticalScalingInitContainersフィーチャーゲートがGAになりました。実行中のサイドカーコンテナのCPU・メモリのrequestsやlimitsを変更でき、kubeletがコンテナのcgroup設定をその場で更新します。Podは稼働し続けます。動作はリソースごとにresizePolicyで制御できます。NotRequiredは変更をライブで適用し、RestartContainerはそのコンテナだけを再起動して適用します。v1.37では、同じ機能に2つのAlpha要素も追加されました。メモリベースのemptyDirボリュームのインプレースリサイズ（InPlacePodVerticalScalingMemoryBackedVolumesゲート）と、保留されたリサイズのためにスケジューラーが低優先度のPodをプリエンプトして空きを作れるようにする機能（InPlacePodVerticalScalingSchedulerPreemptionゲート）です。

apiVersion: v1
kind: Pod
metadata:
  name: app-with-sidecar
spec:
  initContainers:
  - name: log-shipper        # sidecar
    image: log-shipper:1.0
    restartPolicy: Always
    resizePolicy:
    - resourceName: cpu
      restartPolicy: NotRequired
    - resourceName: memory
      restartPolicy: RestartContainer
    resources:
      requests:
        cpu: "100m"
        memory: "128Mi"
      limits:
        cpu: "200m"
        memory: "256Mi"
  containers:
  - name: app
    image: app:1.0
    # ...

この設定では、サイドカーのCPUは一切の再起動なしで引き上げられます。メモリを増やした場合はそのコンテナ1つだけが再起動され、Pod全体が再起動されることはありません。

2. HorizontalPodAutoscalerの許容値（tolerance）設定

機能グループ: SIG Autoscaling | KEP: #4951

Kubernetes v1.37では、HorizontalPodAutoscaler（HPA）の許容値設定がGeneral Availability（GA）に昇格しました。

HPAは、CPUやメモリなどのメトリクスに基づいてPodのレプリカ数を変更します。この機能が導入される前は、HPAはクラスター全体で固定の10%の許容値を使用しており、使用量がターゲットから10%以上乖離するまで動作しませんでした。この単一の値がすべてのワークロードに適しているわけではありません。要件の厳しいサービスでは反応が遅すぎることがあり、値を変更するにはクラスター内のすべてのHPAに影響するグローバルなコントローラーフラグを編集する必要がありました。

v1.37では、HPAConfigurableToleranceフィーチャーゲートがGAになりました。許容値はHPAごと、かつスケーリング方向ごとにbehaviorフィールドで設定できます。スケールアップ時の許容値を厳しくすれば、重要なサービスがわずかな負荷増加にも反応できます。それ以外は緩めの許容値にすることで、負荷の少ないワークロードを安定させられます。この機能はv1.35でBetaとなり、今回標準の動作になりました。

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 60
  behavior:
    scaleUp:
      tolerance: 0.05

許容値はパーセントポイントではなく比率です。0.05でターゲットが60%の場合、CPU使用率が約63%（60%×1.05）を超えた時点でHPAがスケールアップします。従来の固定10%の許容値よりも早く反応できます。

3. Node Declared Features

機能グループ: SIG Node | KEP: #5328

Kubernetes v1.37では、node declared featuresがGeneral Availability（GA）に昇格しました。

この機能が導入される前、Kubernetesは、バージョンがサポートされるスキューの範囲内にある限り、コントロールプレーンがサポートするあらゆる機能をノードが扱えるものと想定していました。しかし、これは常に正しいわけではありません。コントロールプレーンで新機能を有効にしても、スケジューラーはその機能を使うPodを、まだ対応していない古いノードに配置してしまう可能性がありました。配置自体は問題なく見えても、Podは実行時に失敗したり、スケジューリング後に停止したままになったりしていました。

v1.37では、NodeDeclaredFeaturesフィーチャーゲートがGAになりました。各ノードは、自身が理解できる機能のセットをNodeオブジェクトのstatus.declaredFeaturesフィールドで公開するようになりました。スケジューラーとアドミッションチェックはこれを利用して、機能を使うPodをその機能をサポートするノードにのみ配置します。これにより、実行時の失敗が明確なスケジューリング判断に変わります。ノードのバージョンが混在するアップグレード時に特に重要です。node declared featuresはv1.35でAlphaでした。

Kubernetes v1.37のBeta機能

4. HorizontalPodAutoscalerのゼロスケール

機能グループ: SIG Autoscaling | KEP: #2021

Kubernetes v1.37では、HorizontalPodAutoscalerのゼロスケール（scale to zero）がBetaに昇格し、デフォルトで有効になりました。

この機能が導入される前、HPAはワークロードのレプリカ数をゼロまで減らすことができず、最小でも1でした。キューコンシューマーやバッチワーカーのように処理が発生する時間が限られるサービスでは、何もすることがない間も、少なくとも1つのPodを稼働させ続けるコストがかかっていました。

v1.37では、HPAにspec.minReplicas: 0を設定して、アイドル時にワークロードをゼロまでスケールダウンさせ、需要が戻ったら復帰させることができます。これはキューの長さなど、ObjectメトリクスまたはExternalメトリクスで駆動されるワークロードで機能します。CPUやメモリのメトリクスでは機能しません。これらのメトリクスは稼働中のPodから取得されるものであり、ゼロの状態ではPodが存在しないためです。キューコンシューマー、バッチジョブ、実行の合間にアイドル状態になるGPUワークロードのコスト削減につながります。HPAがワークロードをゼロに保っている間は、ScaledToZeroコンディションがTrueとして記録されるため、HPAがゼロにスケールしたワークロードと手動で停止されたワークロードを区別できます。再びスケールアップすると、このコンディションは理由NotScaledToZeroとともにFalseになります。

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: worker-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: queue-worker
  minReplicas: 0
  maxReplicas: 20
  metrics:
  - type: External
    external:
      metric:
        name: queue_messages
      target:
        type: AverageValue
        averageValue: "30"

この構成では、キューが空になるとワークロードはPod数ゼロまで縮小し、メッセージが届くとHPAが再びスケールアップします。

5. Memory QoS

機能グループ: SIG Node | KEP: #2570

Kubernetes v1.37では、Memory QoSがBetaに昇格しました。

この機能が導入される前、kubeletはコンテナにハードなメモリ制限（cgroupのmemory.max）を設定していましたが、カーネルに対してそれより緩やかなシグナルは一切与えていませんでした。コンテナは制限ぎりぎりまでメモリを使用し、その後ほとんど前触れなくOOM killされる可能性がありました。また、コンテナのrequestに紐づいたメモリ保護もなかったため、メモリ圧迫時には、requestの範囲内に収まっているコンテナからでもカーネルがページを回収してしまうことがありました。

v1.37では、MemoryQoSフィーチャーゲートがBetaになりました。cgroup v2のメモリ制御を利用して、カーネルにより適切なシグナルを与えます。kubeletはコンテナのメモリrequestからmemory.minを設定し、その分のメモリを回収から保護します。kubelet設定でmemoryThrottlingFactorを指定すると、kubeletはlimitより低いスロットリングポイントとしてmemory.highも設定します。これにより、コンテナがハードリミットに達してOOM killされる前に、カーネルがコンテナを減速させてページを回収します。デフォルトではmemoryThrottlingFactorは設定されておらず、設定しない限りmemory.highは無効のままです。cgroup v2が必須ですが、v1.35以降はcgroup v2が唯一サポートされるモードとなっています。

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
memoryThrottlingFactor: 0.9

この設定では、kubeletは0.9の係数を用いて、コンテナのメモリlimitより低い位置にmemory.highを設定します。カーネルはハードリミットに達する前にメモリを回収してコンテナをスロットリングするため、メモリ圧迫時のOOM killが起こりにくくなります。

6. Pod単位のリソースマネージャー

機能グループ: SIG Node | KEP: #5526

Kubernetes v1.37では、Pod単位のリソースマネージャーがBetaに昇格しました。

Kubernetes v1.34ではPodレベルのリソース（KEP #2837）が追加され、コンテナ単位だけでなくPod全体に対してCPUとメモリのrequests・limitsを設定できるようになりました。しかし、kubeletのリソースマネージャーはこれらのPodレベルの値をまだ理解していませんでした。この機能が導入される前、CPU Manager、Memory Manager、Topology Managerはコンテナ単位のrequestsしか参照していませんでした。そのため、Podレベルでリソースを設定したPodは、専用CPUのピン留めやNUMAアライメントの恩恵を受けられない可能性がありました。

v1.37では、PodLevelResourceManagersフィーチャーゲートがBetaになりました。v1.37ではデフォルト無効です。一度有効化されたものの、リリースサイクル終盤にチームが重大な問題を発見したため無効に戻されました。利用したい場合は自分で有効化する必要があります。有効にすると、CPU Manager（staticポリシー）、Memory Manager、Topology Managerが、CPU・メモリ・ハードウェアの局所性を割り当てる際にPodレベルのリソースを考慮します。これにより、Podレベルでリソースを設定するレイテンシー重視の高性能なワークロードでも、専有コアとNUMAアラインされたメモリを確保できます。

apiVersion: v1
kind: Pod
metadata:
  name: guaranteed-pod
spec:
  resources:              # pod-level resources
    requests:
      cpu: "2"
      memory: "4Gi"
    limits:
      cpu: "2"
      memory: "4Gi"
  containers:
  - name: app
    image: app:1.0
    # containers can set their own resources, or use the pod-level ones

この構成では、PodはPodレベルでGuaranteedとなり、コンテナが自身のrequestsを設定していなくても、kubeletのマネージャーがCPUコアを丸ごとピン留めし、メモリをアラインできます。

7. Workload APIによるギャングスケジューリング

機能グループ: SIG Scheduling | KEP: #4671

Kubernetes v1.37では、Workload APIによるネイティブなギャングスケジューリングがBetaに昇格しました。

この機能が導入される前、KubernetesはPodを1つずつスケジュールしていました。すべてのワーカーが同時に起動しなければならない分散学習の実行のような密結合ジョブでは、これが部分的なスケジューリングを引き起こしていました。一部のPodは起動する一方で他はpendingのまま残り、リソースを占有しながら何の成果も出さない状態になります。オール・オア・ナッシング（ギャング）の動作を実現するには、外部スケジューラーを追加する必要がありました。Kubernetes v1.35では、新しいWorkload APIを通じたネイティブなギャングスケジューリングがAlphaとして導入されました。

v1.37では、APIはscheduling.k8s.io/v1beta1になりました。有効化にはGenericWorkloadフィーチャーゲートを使用します。v1.37では、従来のGangSchedulingとWorkloadAwarePreemptionのゲートがGenericWorkloadに統合され、1つのゲートでギャングスケジューリングとワークロードを考慮したプリエンプションの両方をカバーするようになりました。モデルは3つの要素で構成されます。Workloadは1つ以上のpodGroupTemplatesを保持し、それぞれがgangなどのスケジューリングポリシーとminCountを持ちます。PodGroupはテンプレートから作成され、実行中の1つのグループを追跡します。各PodはschedulingGroup.podGroupNameで自身のグループを指定します。スケジューラーは、少なくともminCount個のPodがまとめて実行可能になるまでPodを保留し、可能になった時点で配置します。minCountを満たせない場合はどのPodもバインドされず、空きが出るまで待機します。minCountフィールドは作成後も変更可能なため、エラスティックなジョブのスケールアップ・ダウンにも対応できます。

Workloadがテンプレートを定義します。

apiVersion: scheduling.k8s.io/v1beta1
kind: Workload
metadata:
  name: training-job
spec:
  podGroupTemplates:
  - name: workers
    schedulingPolicy:
      gang:
        minCount: 4

そのテンプレートからPodGroupが作成されます。

apiVersion: scheduling.k8s.io/v1beta1
kind: PodGroup
metadata:
  name: training-job-workers-0
spec:
  workloadRef:
    workloadName: training-job
    templateName: workers
  schedulingPolicy:
    gang:
      minCount: 4

各Podは名前でグループに参加します。

apiVersion: v1
kind: Pod
metadata:
  name: worker-0
spec:
  schedulingGroup:
    podGroupName: training-job-workers-0
  containers:
  - name: trainer
    image: trainer:1.0
    # ...

この構成では、Kubernetesは少なくとも4つのワーカーがまとめて実行可能になったときにのみワーカーをスケジュールします。クラスターに4つ分の空きがなければ、1つも起動しません。

8. ユーザー名前空間でのKubelet実行（Rootlessモード）

機能グループ: SIG Node | KEP: #2033

Kubernetes v1.37では、kubeletをユーザー名前空間内で実行するRootlessモードがBetaに昇格しました。

この機能が導入される前、kubeletなどのノードコンポーネントはホスト上でrootとして動作していました。kubeletが侵害されると、攻撃者はノード全体のroot権限を取得できてしまう可能性がありました。

v1.37では、KubeletInUserNamespaceフィーチャーゲートがBetaになりました。kubeletとその他のノードコンポーネントをLinuxのユーザー名前空間内で実行します。名前空間の内側ではrootに見えますが、ホスト上では非特権ユーザーにマッピングされます。kubeletの日常的な使い方を変えることなく、隔離のレイヤーが1つ追加されます。この機能はv1.22から開発が続けられてきたもので、Beta到達は大きな前進です。

Kubernetes v1.37のAlpha機能

9. Eviction Request API

機能グループ: SIG Node | KEP: #4563

この機能が導入される前、メンテナンスのためのノードのドレインはクライアント側の操作でした。kubectl drainのようなツールがPodを1つずつ退避させ、PodDisruptionBudgetを尊重していましたが、その意図はクラスター内ではなくクライアント側にありました。コントローラーやアプリケーションは、ノードがドレイン中であることを把握したり、安全な引き継ぎを調整したり、判断に関与したりできませんでした。ステートフルなアプリは、メンテナンスが迫っていることを知らされないまま、都合の悪いタイミングで退避させられる可能性がありました。

v1.37では、Alpha機能としてEvictionRequest APIが追加され、強制的な削除ではなく協調的な退避が可能になります。リクエスターがPodに対してEvictionRequestを作成し、新しいspec.evictionResponders Podフィールドを通じて登録されたコンポーネントが、グレースフルな引き継ぎを処理します。v1.37では、新しいNodeライフサイクルコンディション（MaintenancePlanned、MaintenanceInProgress、GracefulNodeShutdownInProgress、DrainInProgress、Drained）も追加され、コントローラーはこれらを監視してノードがメンテナンスフローのどの段階にあるかを把握できます。これらを組み合わせることで、アプリケーションやオペレーターは、たとえばPodが消える前にリーダーを移動したり状態をフラッシュしたりするなど、自分たちの都合に合わせてドレインを進められます。

10. Pod単位のチェックポイントとリストア

機能グループ: SIG Node | KEP: #5823

この機能が導入される前、Kubernetesは単一コンテナのチェックポイント（KEP #2008）が可能で、主にフォレンジック分析向けでした。1つのコンテナの状態はスナップショットできましたが、Pod全体を一度に取得することはできず、マルチコンテナのPodを1つの単位としてキャプチャすることはできませんでした。

v1.37では、Alpha機能としてPod単位のチェックポイントとリストアが追加されます。Container Runtime Interface（CRI）をCheckpointPodとRestorePodの呼び出しで拡張し、kubeletと対応ランタイムがPod内のすべてのコンテナをまとめてスナップショットし、後でリストアできるようにします。現時点ではフォレンジック用途に有用であり、実行中のPodをノード間で移動させるといった将来の用途への土台にもなります。この機能には、新しいCRI呼び出しをサポートするコンテナランタイムが必要です。