Kubernetes v1.30 が利用可能になりました!

これまでで最もかわいいバージョン、Kubernetes v1.30: Uwubernetes のリリースを発表できることを嬉しく思います。

以前のバージョンと同様に、Kubernetes v1.30 リリースでは、新しい安定版、ベータ版、アルファ版の機能が導入されています。一貫して高品質なリリースをリリースすることで、当社は強力な開発サイクル能力とコミュニティからの熱心なサポートを実証します。

このリリースには 45 の機能強化が含まれており、そのうち 17 は安定版リリースに、18 はベータ版リリースに、10 はプレビュー版リリースに昇格されています。

投稿テーマとロゴ

1.Kubernetes v1.30: Kubernetes のリリース

Kubernetes v1.30 でクラスターがさらに魅力的になります。

Kubernetes は、世界中のあらゆる業界の何千人もの人々によって構築され、リリースされています。ほとんどの貢献者はこれに対して報酬を受け取りません。私たちは楽しみ、問題解決、学習、そしてコミュニティへの愛のために構築します。私たちの多くはここで家や友人、そして仕事を見つけました。リリース チームは、Kubernetes の継続的な進化に貢献できることを光栄に思います。

これに貢献してくださった方々、これをリリースしてくださった方々、そしてすべてのクラスターをオンラインに保ってくれた方々に、これまでで最も素晴らしいリリースである Kubernetes v1.30: Uwubernetes をお届けします。名前は「kubernetes」と幸せや可愛さを表す絵文字「UwU」を組み合わせたものです。私たちはここで喜びを見つけ、外での生活の喜びをここに持ち込みます。それがこのコミュニティをとてもユニークで、素晴らしく、情熱的なものにしているのです。私たちの仕事を皆さんと共有できることをとても嬉しく思っています。

2. 安定バージョンにアップグレードされたKubernetes v1.30の改善点

ここでは、v1.30 リリース後に安定した改善点の一部を紹介します。

3. kubelet 再起動後の堅牢な VolumeManager 再構築 (SIG ストレージ)

これはボリューム マネージャーのリファクタリングであり、これにより kubelet は起動時に既存のボリュームがどのようにマウントされるかについての追加情報を入力できるようになります。全体として、これにより、kubelet の再起動またはマシンの再起動後のボリュームのクリーンアップがより堅牢になります。

ユーザーやクラスター管理者にとっては何も変わりません。問題が発生した場合に以前の動作にフォールバックできるように、機能フローおよび機能スイッチ NewVolumeManagerReconstruction を使用します。機能が安定しているため、機能スイッチはロックされており、無効にすることはできません。

4. ボリューム復元中に不正なボリュームモード変換を防止する（SIG Storage）

Kubernetes 1.30 では、コントロール プレーンは、スナップショットを永続ボリュームとして復元するときに、常に不正なボリューム モードの変更を防止します。クラスター管理者として、復元時にこれらの変更を許可する必要がある場合は、適切なプリンシパル (たとえば、ストレージ統合を表すサービス アカウント) に権限を付与する必要があります。

警告: アップグレードする前に、必要なアクションを実行してください。 external-provisioner v4.0.0 および external-snapshotter v7.0.0 では、prevent-volume-mode-conversion 機能フラグがデフォルトで有効になっています。 VolumeSnapshot 経由で PVC を作成中にボリューム モードの変更が行われた場合、変更は拒否されます。 ?external-provisioner 4.0.0 および ?external-snapshotter v7.0.0 の「緊急アップグレード ノート」セクションの手順に従わない限り。

この機能の詳細については、スナップショット ボリューム モードの変換手順をお読みください。

5. ポッド スケジューリングの可用性 (SIG スケジューリング)

Pod Scheduling Availability は Kubernetes v1.27 でベータ版に昇格され、このリリースで安定しました。

この安定した機能により、クラスターにポッドをノードにバインドするためのリソースがまだない場合、Kubernetes は定義されたポッドをスケジュールしようとすることを回避できます。これは単なる 1 つのユースケースではありません。また、カスタム コントロールを使用して、クォータ メカニズム、安全制御などを実装し、Pod のスケジュールを許可するかどうかを決定することもできます。

これらのポッドをスケジュールから除外としてマークすると、スケジューラのワークロードが軽減され、現在のクラスター ノードでスケジュールできないポッドがスケジュールされるのを防ぐことができます。クラスターで自動スケーリングが有効になっている場合、スケジューリング ゲートを使用すると、スケジューラの負担が軽減されるだけでなく、コストも節約できます。スケジューリング ゲートがないと、オートスケーラーは起動する必要のないノードを起動してしまう可能性があります。

Kubernetes v1.30 では、Pod の .spec.schedulingGates を指定 (または削除) することで、Pod がいつスケジュール対象として考慮されるかを制御できます。この安定した機能は、現在正式に Kubernetes API の一部となっています。

6. PodTopologySpread のドメインの最小数 (SIG スケジューリング)

このリリースでは、PodTopologySpread の minDomains パラメータが安定版に昇格され、ドメインの最小数を定義できるようになりました。この機能は、クラスター オートスケーラーで使用するように設計されています。

以前にこの機能を使用しようとしたときに十分なドメインが存在しなかった場合、Pod はスケジュール不可としてマークされます。その後、クラスター オートスケーラーは新しいドメインにノードをプロビジョニングし、最終的に十分な数のドメインにポッドを分散します。

7. k/k の Go ワークスペース (SIG Architecture)

Kubernetes リポジトリでは Go ワークスペースが使用されるようになりました。これはエンドユーザーには影響しませんが、下流プロジェクトの開発者にはいくらか影響します。ワークスペースに切り替えると、?k8s.io/code-generator ツールのフラグの一部が変更されます。ダウンストリームのコンシューマーは、?staging/src/k8s.io/code-generator/kube_codegen.sh ファイルをチェックして、これらの変更を理解できます。

8. Kubernetes v1.30 の改良点がベータ版にアップグレードされました

これらは、v1.30 のリリース後にベータ版に追加された改善点の一部です。

9. ノード ログ クエリ (Windows SIG スケジューリング)

ノード上の問題のデバッグを支援するために、Kubernetes v1.27 では、ノード上で実行されているサービスのログを取得できる機能が導入されました。この機能を使用するには、ノード上の NodeLogQuery 機能ゲートが有効になっており、kubelet 構成オプションの enableSystemLogHandler と enableSystemLogQuery の両方が true に設定されていることを確認してください。

バージョン 1.30 以降はベータ版です (ただし、この機能を使用するには有効にする必要があります)。

Linux では、サービス ログは journald 経由で利用できるものと想定されています。 Windows では、サービス ログがアプリケーション ログ プロバイダーで利用できることが前提となります。 /var/log/ (Linux) または C:\var\log\ (Windows) 内のファイルを読み取ることでログを取得することもできます。詳細については、ログ クエリのドキュメントを参照してください。

10.CRD検証ラチェット（SIG API Machinery）

この機能を使用するには、CRDValidationRatcheting 機能ゲートを有効にする必要があります。有効にすると、クラスター内のすべての CustomResourceDefinitions に動作が適用されます。

機能ゲートが有効になると、Kubernetes は CustomResourceDefinitions に対して検証ラチェットを適用します。 API サーバーは、更新操作によって検証に失敗したリソースのどの部分も変更されない限り、更新されたが有効ではなくなったリソースに対する更新を受け入れます。つまり、無効のままになっているリソースの無効な部分は、すでにエラーになっているはずです。このメカニズムを使用して、有効なリソースを無効なリソースに更新することはできません。

この機能により、CRD の作成者は、特定の条件下で OpenAPI V3 スキーマに新しい検証を自信を持って追加できるようになります。ユーザーは、オブジェクトのバージョンを増やしたり、ワークフローを中断したりすることなく、安全に新しいスキーマに更新できます。

11. コンテキスト ログ (SIG Instrumentation)

このリリースでは、コンテキスト ログがベータ版にアップグレードされ、開発者とオペレーターは WithValues メソッドと WithName メソッドを通じて、カスタマイズ可能なコンテキスト詳細 (サービス名やトランザクション ID など) をログに挿入できるようになりました。この改善により、分散システム間のログ データの相関と分析が簡素化され、トラブルシューティングの効率が大幅に向上します。コンテキスト ログにより、Kubernetes 環境の動作をより明確に理解できるため、運用上の課題をより管理しやすくなり、Kubernetes の可観測性にとって重要な前進となります。

12. Kubernetes に負荷分散動作を認識させる (SIG ネットワーク)

LoadBalancerIPMode 機能フラグがベータ版に昇格され、デフォルトで有効になりました。この機能を使用すると、LoadBalancer タイプのサービスに対して .status.loadBalancer.ingress.ipMode プロパティを設定して、ロード バランサ IP の動作を指定できます。 .ipMode は、.status.loadBalancer.ingress.ip フィールドも指定されている場合にのみ指定できます。ロード バランサーの状態を指定するための IPMode の詳細については、関連ドキュメントを参照してください。

新しいアルファ機能

再帰的な SELinux ラベル変更の高速化 (SIG Storage) v1.27 以降、Kubernetes には、ボリュームの内容に一定時間で SELinux ラベルを設定できる最適化が組み込まれています。 Kubernetes はマウント オプションを通じてこの高速化を実現します。以前の動作は遅く、コンテナ ランタイムがボリューム全体を再帰的に走査し、各ファイルとディレクトリに SELinux ラベルを個別に適用する必要がありました。これは、多数のファイルとディレクトリを含むボリュームで特に顕著でした。

Kubernetes 1.27 ではこの機能がベータ版に昇格されましたが、ReadWriteOncePod ボリュームのみが対象です。対応する関数ゲートは SELinuxMountReadWriteOncePod です。これはデフォルトで有効になっており、1.30 までベータ版のままになります。

Kubernetes 1.30 では、別の機能ゲート SELinuxMount を使用して、アルファ リリースとしてすべてのボリュームに SELinux マウント オプションのサポートを拡張します。この機能ゲートにより、異なる SELinux ラベルを持つ複数の Pod が同じボリュームを共有する場合の動作が変更されます。詳細については、「?KEP」を参照してください。

この機能をすべてのボリュームでテストするには、SELinuxMountReadWriteOncePod と SELinuxMount 機能ゲートの両方を有効にする必要があります。

この機能は、SELinux をサポートしていない Windows ノードまたは Linux ノードには影響しません。

1. 再帰読み取り専用 (RRO) マウント (SIG ノード)

このリリースでは、再帰読み取り専用 (RRO) マウントのアルファ バージョンを導入し、データのセキュリティに新たな層を提供します。この機能を使用すると、ボリュームとそのサブマウントを読み取り専用に設定して、誤って変更されるのを防ぐことができます。データの整合性が最も重要となる重要なアプリケーションを導入することを想像してみてください。RRO マウントは、データが損なわれないことを保証し、追加の保護手段でクラスターのセキュリティを強化します。これは、小さな変更でも大きな影響を与える可能性がある、厳密に管理された環境では特に重要です。

2. ジョブの成功/完了戦略（SIG アプリ）

Kubernetes v1.30 以降、インデックス作成ジョブは、成功した Pod に基づいてジョブの成功を宣言するタイミングを定義する .spec.successPolicy プロパティをサポートします。これにより、次の 2 種類の基準を定義できます。

• successfulIndexes は、これらのインデックスが成功すると、他のインデックスが失敗してもジョブが成功したと宣言できることを示します。
• successfulCount は、成功したインデックスの数がこの基準に達したときにジョブが成功したと宣言できることを示します。ジョブが成功ポリシーを満たすと、ジョブ コントローラーは一時停止された Pod を終了します。

3. サービストラフィックの割り当て（SIGネットワ​​ーク）

Kubernetes v1.30 では、サービスに対するトラフィック分散機能 (spec.trafficDistribution) が導入されましたが、現在はアルファ バージョンです。この新しい機能を使用すると、トラフィックをサービス エンドポイントにルーティングする方法の設定を定義できます。トラフィック ポリシーは主にセマンティック保証に重点を置いていますが、トラフィック分散を使用すると、クライアント トポロジに近いエンドポイントにトラフィックをルーティングするなどの設定を表現できます。これにより、パフォーマンス、コスト、信頼性を最適化できます。この機能を使用するには、クラスターとすべてのノードで ServiceTrafficDistribution 機能ゲートを有効にします。 Kubernetes v1.30 以降では、次のフィールド値がサポートされています。

PreferClose: トラフィックをクライアント トポロジに近いエンドポイントにルーティングすることを優先することを示します。 「トポロジ的に近い」の具体的な定義は実装によって異なり、同じノード、ラック、リージョン、さらには地理的な場所内のエンドポイントが含まれる場合もあります。この値を設定すると、実装では、負荷を均等に分散するのではなく、近接性を最適化するなど、さまざまなトレードオフを選択できるようになります。このトレードオフを受け入れない場合は、この値を設定しないでください。

このフィールドが設定されていない場合、実装 (kube-proxy など) はデフォルトのルーティング ポリシーを適用します。

Kubernetes v1.30 のアップグレード、廃止、削除

安定バージョン (公式リリースとも呼ばれます) にアップグレードするときに利用できるすべての機能のリストを以下に示します。新機能やアルファ版からベータ版へのアップグレードを含む更新の完全なリストについては、リリース ノートを参照してください。

このバージョンには、安定バージョンにアップグレードされた 17 の機能が含まれています。

• コンテナリソースに基づくポッドの自動スケーリング: https://kep.k8s.io/1610
• クラウド コントローラー マネージャー (KCCM) で一時ノード述語を削除します: https://kep.k8s.io/3458
• k/k は Go のワークスペース アーキテクチャを使用します: https://kep.k8s.io/4402
• シークレットベースの ServiceAccount トークンを削減: https://kep.k8s.io/2799
• アドミッションコントロール用の CEL: https://kep.k8s.io/3488
• CEL に基づくアドミッション制御の一致条件: https://kep.k8s.io/3716
• ポッドのスケジューリングが準備完了です: https://kep.k8s.io/3521
• PodTopologySpread の最小ドメイン: https://kep.k8s.io/3022
• ボリューム回復中に不正なボリューム モード変換を防止する: https://kep.k8s.io/3141
• API サーバー リンク トラッキング: https://kep.k8s.io/647
• クラウド上のデュアルスタック - ノード - IP 処理: https://kep.k8s.io/3705
• AppArmor サポート: https://kep.k8s.io/24
• kubelet 再起動後の VolumeManager の安定した再構築: https://kep.k8s.io/3756
• kubectl インタラクティブ削除: https://kep.k8s.io/3895
• メトリクスベンチマーク構成: https://kep.k8s.io/2305
• Pod に status.hostIPs フィールドを追加します: https://kep.k8s.io/2681
• 集約リソース API 検出: https://kep.k8s.io/3352

廃止および削除:

• バージョン v1.27 以降、SecurityContextDeny アドミッション プラグインのサポートは削除され、非推奨としてマークされています。 (SIG 認証、SIG セキュリティ、SIG テスト)
• SecurityContextDeny アドミッション プラグインが削除されたため、v1.25 以降で利用可能な Pod Security Admission プラグインを使用することをお勧めします。

リリースノート

Kubernetes 1.30 リリースの詳細については、リリース ノートを参照してください。

可用性

Kubernetes 1.30 は GitHub からダウンロードできます。 Kubernetes を使い始めるには、インタラクティブなチュートリアルに従うか、minikube を使用して Kubernetes クラスターをローカルで実行します。 kubeadm を使用してバージョン 1.30 を簡単にインストールすることもできます。

リリースチーム

Kubernetes は、コミュニティのサポート、コミットメント、そして懸命な努力のおかげで存在しています。各リリース チームは、皆さんが依存する Kubernetes バージョンのさまざまな部分を共同で構築する熱心なコミュニティ ボランティアで構成されています。これには、コード自体からドキュメントやプロジェクト管理まで、コミュニティのあらゆる分野の人々の専門知識が必要です。

Kubernetes v1.30 をコミュニティに提供するために尽力してくれたリリース チーム全員に感謝したいと思います。リリース チームのメンバーは、初めての参加者から、複数のリリース サイクルを経験した経験豊富なチーム リーダーまで多岐にわたります。特に、リリース サイクルの成功を通して私たちをサポートし、私たちに代わって提唱し、私たちが最善の方法で貢献できるようにし、リリース プロセスの改善を推進してくれたリリース リーダーの Kat Cosgrove に感謝したいと思います。

プロジェクトのスピード

CNCF K8s DevStats プロジェクトは、Kubernetes とそのサブプロジェクトの開発速度に関する多くの興味深いデータをまとめています。これには、個人の貢献や貢献している企業の数などの情報が含まれており、このエコシステムを前進させるために行われている取り組みの幅広さと深さを示しています。

14 週間の v1.30 リリース サイクル (2024 年 1 月 8 日～4 月 17 日) 中に、863 社と 1,391 人の個人から寄付をいただきました。

参考文献

• Kubernetes 拡張機能: https://kep.k8s.io/
• Kubernetes 1.30 リリース チーム: https://github.com/kubernetes/sig-release/blob/master/releases/release-1.30
• Kubernetes 1.30 の変更ログ: https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.30.md
• Kubernetes 1.30 トピックディスカッション: kubernetes/sig-release#2424