【ITニュース解説】New Features We Find Exciting in the Kubernetes 1.34 Release

Kubernetes 1.34「Of Wind & Will (O’ WaW)」のリリースは、画期的な新機能よりも、日々のクラスター運用を改善し、管理者の体験を向上させるための着実な改良に焦点を当てたものだ。このリリースは、まるで船の帆に安定した風が吹き込むように、わずかながらも強力な改善が積み重なり、クラスター管理者や開発者がよりスムーズに航海できるよう支援する。膨大なリリースノートを全て読み解くのは大変であるため、このリリースで特に有用なハイライトを抜粋して解説する。

まず、安定版（Stable）に移行した機能から見ていこう。安定版とは、機能が十分にテストされ、本番環境での利用が推奨されるレベルに達したことを意味する。

最も注目すべきは「動的リソース割り当てと構造化パラメータ（Dynamic Resource Allocation with Structured Parameters）」だ。今日多くの企業がAIワークロードをKubernetes上で実行しようとしているが、これまでのKubernetesはGPUのような特殊なハードウェアデバイスを直接管理できなかった。各ノード上で動作するデバイスドライバがハードウェアの利用可能性を追跡し、Podに割り当てる役割を担っていたため、Kubernetes自体はどのデバイスが存在し、どれだけ利用可能か、どこにあるかを知らなかった。このため、2つのPodが同じノードでGPUを要求した場合、スケジューラが状況を知らないままドライバが単独で競合を解決する必要があった。また、GPUリソースを複数のPodで共有することも困難だった。しかし、Kubernetes 1.34で導入された新しい動的リソース割り当て（DRA）フレームワークと構造化パラメータにより、Kubernetesは特殊なハードウェアデバイスを直接管理できるようになる。構造化パラメータは、ハードウェアドライバがデバイスの正確な能力と制約を、Kubernetesが理解できる標準化された形式で記述することを可能にする。例えば、単に「このノードにはGPUが1つある」と伝えるだけでなく、GPUのメモリ容量、サポートされる機能、複数Podで共有可能かどうかといった詳細を指定できるようになった。ドライバは利用可能なデバイスを「ResourceSlice」というKubernetesオブジェクトとして公開し、Kubernetesはこれを参照してより適切なスケジューリング決定を行う。これにより、KubernetesはGPUのようなハードウェアに対して「盲目」ではなくなり、何が利用可能かを確認し、公平に割り当て、さらに信頼性の高い共有をサポートできるようになる。例として、あるノード上のGPUが8GBのメモリを持つことがResourceSliceとして公開されれば、Kubernetesスケジューラはその情報を利用してPodを配置できるようになるため、ドライバが裏で管理することに頼る必要がなくなる。

次に、「設定されたエンドポイントへの匿名認証のみを許可（Allowing Only Anonymous Authentication for Configured Endpoints）」も安定版になった。これまでのKubernetesでは、認証されていないリクエストは匿名として扱われ、「system:anonymous」というIDと「system:unauthenticated」というグループが割り当てられていた。これはヘルスチェックのような特定のユースケースには有用だったが、誤ってRoleBindingやClusterRoleBindingが「system:anonymous」に適用されると、認証されていないPod内のコードがAPIサーバーに広範なアクセス権限を得るリスクがあった。この更新により、管理者はAuthenticationConfigurationオブジェクトを使って、/healthz、/readyz、/livezのような特定のAPIサーバーエンドポイントのみに匿名アクセスを許可するよう、きめ細かく制御できるようになった。これにより、匿名アクセスを完全に無効にして重要な機能を停止させることなく、セキュリティリスクを軽減できる。設定例では、匿名リクエストはヘルスチェックエンドポイントのみに許可され、他のすべての匿名リクエストは、たとえ誤ったRoleBindingsが存在しても拒否されるようになる。

また、「DNS検索文字列の検証の緩和（Relaxed DNS Search String Validation）」も安定版に移行した。PodマニフェストのdnsConfig.searchesフィールドは、短いホスト名の解決方法を制御する。例えば、myserverというホスト名をPodが検索すると、KubernetesはdnsConfig.searchesにリストされた各ドメインを自動的に付加して順に試行する。しかしこれまで、KubernetesはdnsConfig.searchesにおいてアンダースコア（_）や先頭のドット（.）を含むドメイン名を許可していなかった。これにより、カスタムDNS検索ドメインに依存する古いサービスなど、レガシーアプリケーションをKubernetesに移行する際に、DNS設定を変更する必要があり、リスクや時間がかかっていた。Kubernetes 1.34ではこれらの制限が解除され、アンダースコアやドットを含むDNS検索ドメインを指定できるようになったため、設定を書き換えたりサービス名を変更したりすることなく、レガシーワークロードをKubernetesに容易に持ち込めるようになった。例えば、abc_d.staging.comのようなドメインや、現在のディレクトリを意味する.といった特殊な検索エントリも有効になる。これにより、古いワークロードを移行する場合や、特殊なDNS命名規則に依存するサービスを扱う場合に、KubernetesがDNS設定の変更を強制することがなくなった。

次に、ベータ版（Beta）に移行した機能を紹介する。ベータ版の機能は、アルファ版よりも成熟しているが、まだ変更される可能性があり、本番環境での利用には注意が必要な場合がある。

「PreferSameNodeトラフィック分散（PreferSameNode Traffic Distribution）」は、ルーティング効率の課題を解決する。これまでのKubernetesは、デフォルトですべての健全なサービスエンドポイントにトラフィックを均等に分散していたため、サービスが複数のノードやゾーンにまたがっている場合、不必要なクロスノードまたはクロスゾーンのホップが発生し、レイテンシの増加や帯域幅の浪費につながっていた。リアルタイム推論やゲームバックエンドなどのレイテンシに敏感なアプリケーションにとって、これらの余分なホップはパフォーマンスに悪影響を及ぼすことがあった。Kubernetes 1.34では新しいトラフィック分散ポリシーが導入され、PreferSameNodeポリシーにより、トラフィックの発信元が同じノードにあるPodを優先してルーティングする。これにより、レイテンシが削減され、クロスノードトラフィックによるネットワークオーバーヘッドが回避される。また、既存のPreferCloseポリシーはPreferSameZoneに名称変更され、同じゾーン内のPodを優先することで、レイテンシを低減し、クロスゾーンコストを削減する。Service定義にtrafficDistributionフィールドを設定することで、これらのポリシーを適用できる。例えば、あるサービスがPreferSameNodeを設定していれば、同じノード上のPodが利用可能であればそこへトラフィックがルーティングされ、利用不可の場合のみ別のノードへフォールバックする。

「ボリュームソース：OCIアーティファクトと/またはイメージ（VolumeSource: OCI Artifact and/or Image）」もベータ版に移行した。複数のPodが同じ設定ファイルやデータファイルにアクセスする必要がある場合、従来はConfigMapにファイルを組み込むか、各Podにコピーするなどの方法が取られていたが、ファイルが大きく複雑になると管理が煩雑になることがあった。この新機能により、OCIイメージを読み取り専用ボリュームとしてマウントし、複数のPod間で共有できるようになった。ファイルを複製したり手動で同期したりする代わりに、ファイルを一度イメージにパッケージ化し、必要な場所でマウントできる。これにより、ファイルの共有がよりクリーンで効率的な方法で行えるようになる。Podのvolumes定義でimage.referenceを指定することで、OCIイメージをボリュームとして利用できる。開発ツールであるmirrordを利用する開発者にとっては、クラスター内のイメージボリュームをマウントするPodに対してローカルコードを実行できるようになり、テスト環境のセットアップが簡素化されるメリットもある。

最後に、アルファ版（Alpha）に移行した機能について触れる。アルファ版は、開発の初期段階にある機能であり、将来変更される可能性が高い。試験的な利用やフィードバック収集を目的としている。

「Podのホスト名として任意のFQDNを設定可能に（Allows Setting any FQDN as the Pod's Hostname）」がアルファ版になった。これまでのKubernetesでは、Podの完全修飾ドメイン名（FQDN）を設定する際、hostname、subdomain、setHostnameAsFQDN: trueという複数のフィールドを組み合わせて設定する必要があった。結果として得られるFQDNは常に<hostname>.<subdomain>.<namespace>.svc.<cluster-domain>というKubernetesの強制するパターンに従う必要があり、厳密なホスト名マッチングに依存するKerberosのようなシステムでは、ホスト名が正確に一致しないと認証が機能しないなどの問題が発生することがあった。この課題は、新しいhostnameOverrideフィールドによって解決される。このフィールドを使用すると、Podの内部カーネルホスト名を必要な任意の値に明示的に設定できるようになり、Kubernetesの強制するDNS命名規則をバイパスできる。これにより、複数のフィールドを組み合わせたり、Kubernetesの厳密なルールに従ったりすることなく、Podのホスト名を直接制御できるようになった。PodのスペックにhostnameOverrideを指定するだけで、そのPodの内部ホスト名を完全に制御できるようになる。

Kubernetes 1.34「Of Wind & Will」リリースは、劇的な変化をもたらすものではなく、むしろKubernetesが長期的な運用においてより堅牢な基盤となるための、着実な進歩を意味する。特に、動的リソース割り当て（DRA）の安定版への移行は、AIワークロードを実行するチームにとって大きな一歩だ。DRAにより、KubernetesはGPUなどの特殊なハードウェアに対して適切な可視性を獲得し、これらのリソースのスケジューリングと共有が格段に信頼性の高いものになる。機械学習や高性能コンピューティングに取り組む開発者や管理者にとって、これは非常に重要な改善だ。セキュリティ面では、きめ細かな匿名アクセス制御によって、適切なエンドポイントのみが公開され、クラスターの安全性が強化される。また、レガシーシステムを移行する際には、hostnameOverrideや拡張されたDNS検索サポートなどの機能が、長年の課題を解決し、Kubernetesが元々Kubernetes向けに設計されていなかったアプリケーションもより容易に受け入れられるようになる。これらの更新は、船を再構築するのではなく、むしろ索具を調整するようなものだが、それこそが強力な点だ。これらは摩擦を減らし、ギャップを埋め、Kubernetesを私たちが航海する現実世界の海により適応できるものにする。Kubernetes 1.34は、クラスター管理者と開発者に、単なる新機能だけでなく、前進し続けるためのより強い風と安定した意志を提供する。