Kubernetes 1.37リリース：新機能とベータ・安定版の変更点

Kubernetes 1.37：安定版（GA）機能

1. Metrics APIがGAに昇格

Feature Group: SIG Instrumentation | KEP: KEP-5207

metrics.k8s.io APIは長年ベータのままでした。kubectl topやHorizontal Pod AutoscalerのCPU・メモリメトリクスを支えているAPIです。v1.37で、ついに安定版へ昇格します。

機能面での変更はありません。v1とv1beta1の両方が引き続き動作するため、今すぐ何かを変更する必要はありません。ただし、このAPIを利用するツールを開発している場合は、安定版となり予期せぬ変更がなくなったv1を、安心して使えるようになります。

2. Pod単位のリソース設定（Pod-Level Resources）

これまでは、コンテナ同士が連携して動作する場合でも、Pod内の各コンテナごとにリソースのrequestsとlimitsを設定する必要がありました。

Pod-level resourcesを使うと、CPU、メモリ、hugepagesのrequests/limitsを、コンテナレベルの代わりに（あるいは併用して）Podレベルで設定できます。

spec:
  resources:
    requests:
      cpu: "1"
      memory: "512Mi"
    limits:
      cpu: "2"
      memory: "1Gi"
  containers:
  - name: app
    image: my-app
  - name: sidecar
    image: my-sidecar

これにより、Pod内のすべてのコンテナが、それぞれ固定の割り当てを持つ代わりに同じリソースプールを共有できます。リソースの無駄が減り、リソース使用量が急増しやすいマルチコンテナのワークロードにより適しています。

3. DRA：デバイスのTaintとToleration

Feature Group: SIG Scheduling | KEP: KEP-5055

ノードのtaintモデルをDynamic Resource Allocation（DRA）に持ち込む機能です。DRAドライバー、または自分で作成したDeviceTaintRuleによって、特定のデバイス（たとえば過熱中のGPUや、メンテナンスのためにドレイン中のGPU）にtaintを付与できます。

NoScheduleのtaintは新しいPodがそのデバイスを使用するのを防ぎ、NoExecuteのtaintはすでに使用中のPodを排除します。それでもデバイスを使用する必要があるワークロードは、ResourceClaimに対応するtolerationを追加できます。

これにより、ノード全体をcordonする代わりに、単一のGPUやNICだけを隔離できます。

4. HPAのTolerance設定

Feature Group: SIG Autoscaling | KEP: KEP-4951

Horizontal Pod Autoscaler（HPA）は、メトリクスの小さな変動でスケーリングが発生しないよう、これまでクラスタ全体で固定の10%のtoleranceを使用してきました。しかし、同じ10%がすべてのワークロードに適しているわけではありません。Podが500個あるワークロードでの10%と、5個しかないワークロードでの10%とでは、意味がまったく異なります。

この機能が安定版になったことで、HPAごとにカスタムのtoleranceを設定できるようになりました。spec.behavior.scaleUpとspec.behavior.scaleDownの下で、スケールアップとスケールダウンに別々の値を指定できます。クラスタ全体のデフォルトを変更することなく、各ワークロードをより適切にスケールさせられます。

5. Pod証明書（Pod Certificates）

Feature Group: SIG Auth | KEP: KEP-4317

Podがベアラートークンを経由せずに、有効期間の短いX.509証明書をネイティブに取得できるようになります。新しいPodCertificateRequest APIが発行を処理し、PodCertificate projectedボリュームによって、kubeletが鍵と証明書を自動ローテーション付きでPodに直接渡せます。

これにより、mTLSの構成（HashiCorp Vaultのようなサードパーティツールを含む）を、多くのサービスメッシュが現在使用している追加のサイドカーやWebhookの仕組みなしに、ネイティブに組み込みやすくなります。

6. kubectlのKYAML出力

Feature Group: SIG CLI | KEP: KEP-5295

KYAMLは、より厳格なKubernetes流のYAMLサブセットです。マップには波かっこ、リストには角かっこ、文字列にはダブルクォートを使用します。コメントや末尾のカンマは引き続き許容されますが、暗黙的にブール値のfalseとして解釈されてしまう問題（いわゆる「ノルウェー問題」）のような、YAML特有の落とし穴を排除しています。

kubectlの安定版出力オプションとして利用できるようになったため、意図しない型変換で設定が壊れる心配なく、この形式でマニフェストを生成できます。

7. SELinuxラベルの再帰的変更の高速化（SELinuxMount）

Feature Group: SIG Storage | KEP: KEP-1710

SELinuxが有効なノードでは、これまでKubernetesはPodを起動する前に、ボリューム上のすべてのファイルを1つずつ再ラベル付けしていました。数百万のファイルを持つボリュームでは、それだけで数分かかることもありました。

SELinuxMountはv1.37でGAに昇格し、デフォルトで有効になります。ファイルごとの再ラベル付けの代わりに、ボリュームは-o context=<label>付きでマウントされ、1回のマウント操作でボリューム全体に正しいラベルが適用されます。この動作は、ボリュームのCSIドライバーがCSIDriver.spec.seLinuxMount: trueでオプトインした場合にのみ有効になります。

重要な注意点：1つのマウントが持てるSELinuxコンテキストは1つだけです。現在、同じノード上で異なるSELinuxラベルを持つPod同士が同じボリュームを共有している場合（従来の再帰的な再ラベル付けでは問題なく動作していました）、それらのPodは起動に失敗する可能性があります。特定のワークロードで従来の動作が必要な場合は、Pod specにseLinuxChangePolicy: Recursiveを設定してください。SELinuxを有効にしていないクラスタには一切影響はありません。

Kubernetes 1.37のベータ機能

8. ユーザー名前空間内のKubelet（ルートレスモード）

Feature Group: SIG Node | KEP: KEP-2033

kubeletのようなノードコンポーネントは、通常ホスト上でrootとして動作します。kubeletが侵害されると、攻撃者がノードのroot権限を取得する恐れがあります。

Kubelet in UserNSは、kubeletをLinuxのユーザー名前空間内で実行します。名前空間内ではrootとして動作しているように見えますが、実際のホスト上では非特権ユーザーにマッピングされます。この機能はKubernetes v1.37でベータに移行し、日々のkubeletの使い方を変えることなく、隔離のレイヤーをもう一段追加できます。

9. Object・ExternalメトリクスによるHPAのゼロへの／ゼロからのスケール

Feature Group: SIG Autoscaling | KEP: KEP-2021

Horizontal Pod Autoscaler（HPA）は、以前からobjectメトリクスやexternalメトリクスを使ってレプリカ数をゼロまでスケールできました。しかし、HPAがワークロードをゼロにスケールしたのか、それとも誰かが別の方法でゼロに設定したのかを簡単に判別する手段がありませんでした。

Kubernetes v1.37では、HPAオブジェクトにScaledToZeroステータスコンディションが追加され、この違いが明確になります。キューの深さやKEDAスタイルのトリガーを使用するイベント駆動型のワークロードなど、アイドル時にゼロまでスケールダウンし、新しい処理が来たら再びスケールアップするケースで特に役立ちます。

10. CBORシリアライザー

Feature Group: SIG API Machinery | KEP: KEP-4222

Kubernetesの組み込みリソースはAPI呼び出しを高速に保つためにProtobufを使用していますが、Protobufはコンパイル時のコード生成が必要なため、CRDでは簡単に利用できません。CBORはその要件がないバイナリ形式で、初期のベンチマークでは、カスタムリソースにおいてJSONと比較して最大8倍高速なエンコードと2倍高速なデコードが確認されています。クライアントが自動的にネゴシエートし、古いAPIサーバーに対してはJSONにフォールバックするため、安全に展開できます。

Kubernetes 1.37のアルファ機能

以下はアルファ機能です。本番環境で使える段階ではありませんが、ステージングクラスタで試してみる価値はあります。

11. Volume Health Monitor

Feature Group: SIG Storage | KEP: KEP-1432

現状では、CSIボリュームにストレージレベルの問題が発生した場合、マウントの失敗やI/Oのハングでしか気づけないことがほとんどで、対応の起点となる構造化されたシグナルがありません。この機能では、ドライバーがコントローラーの処理可能な形でボリュームの健全性を報告できるよう、4つの新しいCSI RPCが導入されます。コントローラー側では、ControllerListVolumeHealthが異常なボリュームを一覧表示し、ControllerGetVolumeHealthが特定のボリュームを確認します。コントローラー側のヘルスモニターがこれらをポーリングし、結果をPersistentVolumeClaim.status.healthStatusに書き込みます。ノード側では、kubeletが個々のボリュームに対してNodeGetVolumeHealthを呼び出し（Pod.status.volumeHealthに記録）、そのノード上のドライバーの健全性についてはNodeGetStorageHealthを呼び出します。これにより、修復用のコントローラーは、ベンダーのダッシュボードを手作業で突き合わせる代わりに、機械可読な情報に基づいて対応できるようになります。

12. コンテナ単位のulimits

Feature Group: SIG Node | KEP: KEP-5758

データベースや高い並行性を扱うアプリケーションなど、一部のアプリケーションは、オープンできるファイル数やプロセス数の上限といったPOSIXリミットを、コンテナランタイムのデフォルトより高く設定する必要があります。これまでの一般的な選択肢は、カスタムのエントリーポイントスクリプトを使うか、ホストの設定を変更することでした。

Kubernetes v1.37では、Container.SecurityContextにulimitsフィールドが追加されます。kubeletがこれらの制限をコンテナランタイムに渡します。この機能は現時点ではPod Security StandardsのPrivilegedプロファイルでのみ動作します。また、KubernetesはPodをスケジュールする前にノードのサポート状況を確認するため、必要な制限を適用できないノードで実行されることはありません。

13. DRA：派生属性（Derived Attributes）

Feature Group: SIG Scheduling | KEP: KEP-6080

DRAはすでに共通の属性によるデバイスのマッチングが可能ですが、それは異なるハードウェアベンダーが同じ属性名を使っている場合に限られ、実際にはそうでないことがほとんどです。たとえば、同じNUMAノード上にGPUと高速なNICを配置したい場合、スケジューラーには一致する属性名と値が必要ですが、各ベンダーはそれぞれ独自の方法でトポロジーを記述しています。

派生属性を使うと、デバイスリクエスト内にCEL式を記述して、ドライバーがすでに公開している情報から仮想的な属性を構築できます。これにより、NUMAノードIDのような共通のキーが1つ得られ、スケジューラーはそれを基にマッチングできます。すべてのベンダーが1つの命名規則に合意するのを待たずに、同じNUMAノード上のGPUとNICをペアリングできるのです。

これはアルファ機能でAPIはまだ固まっていないため、ステージングクラスタで試し、利用前にKEPで正確なフィールドを確認してください。