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内のコンテナが連携して動作する前提であっても、リソースの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%という許容値を使ってきました。しかし、すべてのワークロードに同じ10%が適切とは限りません。Podが500個あるワークロードにおける10%の変化と、5個のワークロードにおける10%の変化では、意味がまったく異なります。

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

5. Pod証明書

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サブセットです。マップには波括弧、リストには角括弧、文字列にはダブルクォートを使用します。コメントや末尾のカンマは引き続き許可されますが、noが暗黙的にブール値のfalseとして解析される「ノルウェー問題」のような、YAML特有の落とし穴を排除しています。

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

7. 再帰的なSELinuxラベル変更の高速化(SELinuxMount)

Feature Group: SIG Storage | KEP: KEP-1710

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

SELinuxMountはGAに昇格し、v1.37でデフォルトで有効になります。ファイルごとに再ラベル付けする代わりに、ボリュームは-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. ボリュームヘルスモニター

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. コンテナ単位のulimit

Feature Group: SIG Node | KEP: KEP-5758

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

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を配置したい場合、スケジューラーには一致する属性名と値が必要ですが、各ベンダーはトポロジーを独自の方法で記述しています。

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

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