| layout | title | date |
|---|---|---|
blog |
Kubernetes v1.30をそっと覗く |
2024-03-12 |
著者: Amit Dsouza, Frederick Kautz, Kristin Martin, Abigail McCarthy, Natali Vlatko
Kubernetes v1.30のおもしろい変更点をざっと見る
It's a new year and a new Kubernetes release. 新しい年であり、新しいKubernetesのリリースです。
We're halfway through the release cycle and have quite a few interesting and exciting enhancements coming in v1.30. リリースサイクルの半分が終了し、v1.30ではかなりの数の興味深くおもしろい機能強化が行われます。 From brand new features in alpha, to established features graduating to stable, to long-awaited improvements, this release has something for everyone to pay attention to! アルファ版での真新しい機能から、安定版への進む既存の機能、そして待望の改良まで、このリリースには誰もが注目するものがある！
To tide you over until the official release, here's a sneak peek of the enhancements we're most excited about in this cycle! 正式リリースまでのつなぎとして、このリリースで我々がもっとも期待している機能強化をそっと覗いてみましょう！
Kubernetes v1.30の主な変更点
Structured parameters for dynamic resource allocation (KEP-4381)
動的なリソース割り当てのための構造化パラメーター
Dynamic resource allocation was added to Kubernetes as an alpha feature in v1.26. 動的なリソース割り当てはv1.26でアルファ機能としてKubernetesに追加された。
It defines an alternative to the traditional device-plugin API for requesting access to third-party resources. これは、サードパーティリソースへのアクセスを要求するための、従来のデバイスプラグインAPIに代わるものを定義しています。
By design, dynamic resource allocation uses parameters for resources that are completely opaque to core Kubernetes. 設計上、動的なリソース割り当てでは、コアKubernetesには完全に不透明なリソースのパラメーターが使用されます。 TODO
This approach poses a problem for the Cluster Autoscaler (CA) or any higher-level controller that needs to make decisions for a group of pods (e.g. a job scheduler). このアプローチは、クラスターオートスケーラー（CA）や、Podのグループ（Jobスケジューラーなど）に対して決定を下す必要がある上位コントローラーに問題をもたらします。
It cannot simulate the effect of allocating or deallocating claims over time. Only the third-party DRA drivers have the information available to do this.
時間経過に伴うクレームの割り当てや割り当て解除の効果をシミュレートできないのです。 サードパーティーのDRAドライバーだけが、そのための情報を持っています。
Structured Parameters for dynamic resource allocation is an extension to the original implementation that addresses this problem by building a framework to support making these claim parameters less opaque. 動的なリソース割り当てのための構造化パラメーターは、これらのクレームパラメーターの不透明さがより少ないフレームワークを構築することによって、この問題に対処するオリジナルの実装の拡張になります。
Instead of handling the semantics of all claim parameters themselves, drivers could manage resources and describe them using a specific "structured model" pre-defined by Kubernetes. すべてのクレームパラメーターのセマンティクスを自分で処理する代わりに、ドライバーはリソースを管理し、Kubernetesによって事前定義された特定の「構造化モデル」を使用してそれらを記述できます。
This would allow components aware of this "structured model" to make decisions about these resources without outsourcing them to some third-party controller. これにより、この「構造化モデル」を認識しているコンポーネントは、サードパーティのコントローラーにアウトソースすることなく、これらのリソースに関する意思決定を行うことができるようになります。
For example, the scheduler could allocate claims rapidly without back-and-forth communication with dynamic resource allocation drivers. たとえば、スケジューラーは動的リソース割り当てドライバーと行ったり来たりすることなく、クレームを迅速に割り当てることができます。
Work done for this release centers on defining the framework necessary to enable different "structured models" and to implement the "named resources" model. 今回のリリースでは、さまざまな「構造化モデル」を実現するために必要なフレームワークの定義と「名前付きリソース」モデルの実装を中心に作業を行った。
This model allows listing individual resource instances and, compared to the traditional device plugin API, adds the ability to select those instances individually via attributes. このモデルでは、個々のリソース・インスタンスをリストアップすることができ、従来のデバイス・プラグインAPIと比較して、属性によってそれらのインスタンスを個別に選択する機能が追加されています。
Node memory swap support (KEP-2400)
In Kubernetes v1.30, memory swap support on Linux nodes gets a big change to how it works - with a strong emphasis on improving system stability. Kubernetes v1.30では、Linuxノード上のメモリスワップ・サポートが、システムの安定性を向上させることに重点を置いて、その動作方法に大きな変更が加えられた。
In previous Kubernetes versions, the NodeSwap feature gate was disabled by default, and when enabled, it used UnlimitedSwap behavior as the default behavior.
以前のKubernetesバージョンでは、NodeSwap機能ゲートはデフォルトで無効化されており、有効化された場合、デフォルトの動作としてUnlimitedSwap動作が使用されていた。
To achieve better stability, UnlimitedSwap behavior (which might compromise node stability) will be removed in v1.30.
より良い安定性を達成するために、（ノードの安定性を損なう可能性のある）UnlimitedSwap動作はv1.30で削除されます。
The updated, still-beta support for swap on Linux nodes will be available by default. 更新された、まだベータ版のLinuxノードでのスワップ・サポートは、デフォルトで利用できるようになります。
However, the default behavior will be to run the node set to NoSwap (not UnlimitedSwap) mode.
ただし、デフォルトの動作は、NoSwap（UnlimitedSwapではない）モードに設定されたノードを実行することになります。
In NoSwap mode, the kubelet supports running on a node where swap space is active, but Pods don't use any of the page file.
NoSwapモードでは、kubeletはスワップ領域がアクティブなノードでの実行をサポートしますが、Podはページファイルを一切使用しません。
You'll still need to set --fail-swap-on=false for the kubelet to run on that node.
そのノードでkubeletを実行するには、--fail-swap-on=falseを設定する必要があります。
However, the big change is the other mode: LimitedSwap. In this mode, the kubelet actually uses the page file on that node and allows Pods to have some of their virtual memory paged out.
しかし、大きな変更はもう1つのモードのLimitedSwapです。
このモードでは、kubeletは実際にそのノードのページファイルを使用し、Podが仮想メモリの一部をページアウトできるようにします。
Containers (and their parent pods) do not have access to swap beyond their memory limit, but the system can still use the swap space if available. コンテナ（およびその親ポッド）はメモリ制限を超えてスワップにアクセスすることはできませんが、利用可能な場合はスワップ領域を使用できます。
Kubernetes' Node special interest group (SIG Node) will also update the documentation to help you understand how to use the revised implementation, based on feedback from end users, contributors, and the wider Kubernetes community.
KubernetesのNode Special Interest Group（SIG Node）は、エンドユーザー、貢献者、およびより広いKubernetesコミュニティからのフィードバックに基づいて、改訂された実装の使用方法を理解できるようにドキュメントも更新します。
Read the previous blog post or the node swap documentation for more details on Linux node swap support in Kubernetes. Read the previous blog post or the node swap documentation for more details on Linux node swap support in Kubernetes. KubernetesにおけるLinuxノードスワップ・サポートの詳細については、前回のブログ記事またはノードスワップ・ドキュメントをお読みください。
Support user namespaces in pods (KEP-127)
User namespaces is a Linux-only feature that better isolates pods to prevent or mitigate several CVEs rated high/critical, including CVE-2024-21626, published in January 2024. In Kubernetes 1.30, support for user namespaces is migrating to beta and now supports pods with and without volumes, custom UID/GID ranges, and more!
ユーザーネームスペースは、2024年1月に公開されたCVE-2024-21626を含むHigh/Criticalと評価された複数のCVEを防止、または緩和するために、ポッドをより適切に分離するLinux専用の機能です。 Kubernetes 1.30では、ユーザーネームスペースのサポートがベータ版に移行し、ボリュームのあるPodとないPod、カスタムUID/GID範囲などがサポートされるようになりました！
Structured authorization configuration (KEP-3221)
Support for structured authorization configuration is moving to beta and will be enabled by default. 構造化された認可コンフィギュレーションのサポートはベータ版に移行し、デフォルトで有効になります。
This feature enables the creation of authorization chains with multiple webhooks with well-defined parameters that validate requests in a particular order and allows fine-grained control この機能は、失敗時に明示的に拒否するなどのきめ細かな制御を可能にしたり、特定の順序でリクエストを検証する明確に定義されたパラメーターを持つ複数のWebhookによる認可チェーンの作成を可能にします。
configuration file approach even allows you to specify CEL rules to pre-filter requests before they are dispatched to webhooks, helping you to prevent unnecessary invocations. 設定ファイルのアプローチでは、リクエストがWebhookへ渡される前にCELルールを指定して事前にフィルタリングすることも可能で、不要なリクエストを防ぐのに役立ちます。
The API server also automatically reloads the authorizer chain when the configuration file is modified. また、設定ファイルが変更されると、APIサーバーは自動的に認可チェーンを再読み込みします。
You must specify the path to that authorization configuration using the --authorization-config command line argument.
--authorization-configコマンドライン引数を使用して、その認可コンフィギュレーションへのパスを指定しなければならない。
If you want to keep using command line flags instead of a configuration file, those will continue to work as-is. 設定ファイルの代わりにコマンドラインフラグを使い続けたい場合、それらはそのまま機能し続けます。
To gain access to new authorization webhook capabilities like multiple webhooks, failure policy, and pre-filter rules, switch to putting options in an --authorization-config file.
複数のWebhook、失敗ポリシー、プレフィルタルールなどの新しい認可Webhook機能にアクセスするには、--authorization-configファイルにオプションを入れるように切り替えます。
From Kubernetes 1.30, the configuration file format is beta-level, and only requires specifying --authorization-config since the feature gate is enabled by default.
Kubernetes 1.30からは、設定ファイルのフォーマットがベータレベルであり、feature gateがデフォルトで有効になっているため、--authorization-configを指定する必要があるだけです。
An example configuration with all possible values is provided in the Authorization docs. すべての可能な値を含む設定例は、Authorizationドキュメントで提供されています。
For more details, read the Authorization docs. 詳細については、Authorization docsをお読みください。
Container resource based pod autoscaling (KEP-1610)
Horizontal pod autoscaling based on ContainerResource metrics will graduate to stable in v1.30.
ContainerResourceメトリクスに基づく水平Pod自動スケーリングは、v1.30で安定版に移行します。
This new behavior for HorizontalPodAutoscaler allows you to configure automatic scaling based on the resource usage for individual containers, rather than the aggregate resource use over a Pod. HorizontalPodAutoscalerのこの新しい動作により、Pod全体のリソース使用量ではなく、個々のコンテナのリソース使用量に基づいて自動スケーリングを設定できるようになります。
See our previous article for further details, or read container resource metrics. 詳細については以前の記事を参照するか、コンテナリソースメトリクスをお読みください。
CEL for admission control (KEP-3488)
Integrating Common Expression Language (CEL) for admission control in Kubernetes introduces a more dynamic and expressive way of evaluating admission requests. Kubernetesのアドミッション・コントロールにCommon Expression Language (CEL)を統合することで、アドミッション・リクエストを評価するよりダイナミックで表現力豊かな方法が導入されます。
This feature allows complex, fine-grained policies to be defined and enforced directly through the Kubernetes API, enhancing security and governance capabilities without compromising performance or flexibility. この機能により、複雑できめ細かなポリシーがKubernetes APIを通じて直接定義・適用できるようになり、パフォーマンスや柔軟性を損なうことなく、セキュリティとガバナンスの機能が強化されます。
CEL's addition to Kubernetes admission control empowers cluster administrators to craft intricate rules that can evaluate the content of API requests against the desired state and policies of the cluster without resorting to Webhook-based access controllers. CELがKubernetesのアドミッション・コントロールに追加されたことで、クラスター管理者はWebhookベースのアクセス・コントローラーに頼ることなく、クラスターの望ましい状態やポリシーに対してAPIリクエストの内容を評価できる複雑なルールを作成できるようになった。
This level of control is crucial for maintaining the integrity, security, and efficiency of cluster operations, making Kubernetes environments more robust and adaptable to various use cases and requirements. このレベルの制御は、クラスター運用の整合性、セキュリティ、整合性を維持するために極めて重要であり、Kubernetes環境をより堅牢にし、さまざまなユースケースや要件へ適応できるようにします。
For more information on using CEL for admission control, see the API documentation for ValidatingAdmissionPolicy. アドミッション・コントロールにCELを使用する詳細については、ValidatingAdmissionPolicyのAPIドキュメントを参照してください。
We hope you're as excited for this release as we are. Keep an eye out for the official release blog in a few weeks for more highlights! 私たちと同じようにこのリリースを楽しみにしていただければ幸いです。数週間後の公式リリース・ブログで、さらなるハイライトをお見逃しなく！