Kubernetes v1.33: Octarine

By Kubernetes v1.33 Release Team | 翻訳: Taisuke Okamoto (IDC Frontier Inc.), Junya Okabe (筑波大学), Takuto Nagami (千葉工業大学), Tim Bannister (ControlPlane), Toshiaki Inukai |

編集者: Agustina Barbetta, Aakanksha Bhende, Udi Hofesh, Ryota Sawada, Sneha Yadav

前回のリリースと同様に、Kubernetes v1.33リリースでは新しいGA、ベータ、アルファの機能が導入されています。 高品質なリリースの継続的な提供は、私たちの開発サイクルの強さとコミュニティからの活発なサポートを示しています。

このリリースには64個の機能改善が含まれています。 それらのうち、GAへの昇格が18個、ベータへの移行が20個、アルファとしての導入が24個、機能の非推奨化及び撤回が2個となっています。

また、このリリースにはいくつかの注目すべき非推奨化と削除があります。 まだ古いバージョンのKubernetesを実行している場合は、これらに必ず目を通してください。

リリースのテーマとロゴ

Kubernetes v1.33のテーマはOctarine: 魔法の色1で、テリー・プラチェットの ディスクワールド シリーズに着想を得ています。

このリリースは、Kubernetesがエコシステム全体で可能にするオープンソースの魔法2を強調しています。

ディスクワールドの世界に詳しい方なら、"見えざる大学"の塔の上に止まった小さな沼ドラゴンが、アンク・モルポークの街の上に64の星3と共に浮かぶKubernetesの月を見上げる様子を思い浮かべていることでしょう。

Kubernetesが10年の節目を迎え新たな10年へ踏み出すにあたり、私たちはメンテナーの魔術、新しいコントリビューターの好奇心、そしてプロジェクトを推進する協力的な精神を祝福します。 v1.33リリースは、プラチェットが書いたように、「やり方を知っていても、それはまだ魔法だ」 ということを思い出させてくれます。 Kubernetesのコードベースの詳細をすべて知っていたとしても、リリースサイクルの終わりに立ち止まってみると、Kubernetesはまだ魔法のままであることがわかるでしょう。

Kubernetes v1.33は、真に卓越したものを生み出すために世界中の何百人ものコントリビューター4が協力する、オープンソースイノベーションの持続的な力の証です。 あらゆる新機能の背後には、プロジェクトを維持・改善したり、安全性や信頼性を担保したり、計画通りにリリースしたりといったKubernetesコミュニティの働きがあります。

1. Octarineはディスクワールド世界の神話上の8番目の色で、「蛍光の緑がかった黄紫色」と表現される架空の色です。 秘術に調律された人々—魔法使い、魔女、そしてもちろん猫にのみ見えます。 一般人は目を閉じた時のみこの色を感じることができるとされています。 そして時々、IPテーブルのルールを長時間見つめてきた人にも見えるようになります。
2. 「十分に発達した技術は魔法と区別がつかない」ですよね…？
3. v1.33にも64のKEP(Kubernetes Enhancement Proposals)が含まれていますが、これは偶然ではありません。
4. v1.33のプロジェクト活動状況セクションをご覧ください 🚀

主なアップデート情報

Kubernetes v1.33は新機能と改善点が満載です。 このセクションでは、リリースチームが特に注目して欲しい、選りすぐりのアップデート内容をご紹介します！

GA: サイドカーコンテナ

サイドカーパターンでは、ネットワーキング、ロギング、メトリクス収集などの分野における追加機能を処理するために、別途補助的なコンテナをデプロイする必要があります。 サイドカーコンテナはv1.33でGAに昇格しました。

Kubernetesでは、restartPolicy: Alwaysが設定された、特別な種類のinitコンテナとしてサイドカーを実装しています。 サイドカーは、アプリケーションコンテナより先に起動し、Podのライフサイクル全体を通じて実行され続け、アプリケーションコンテナの終了を待ってから自動的に終了することが保証されます。

さらに、サイドカーはprobe(startup、readiness、liveness)を使用して動作状態を通知できる他、メモリ不足時の早期終了を防ぐため、Out-Of-Memory(OOM)スコア調整がプライマリコンテナと揃えられています。

詳細については、サイドカーコンテナをお読みください。

この作業はSIG Nodeが主導したKEP-753: Sidecar Containersの一環として行われました。

ベータ: Podの垂直スケーリングのためのインプレースなリソースリサイズ

ワークロードはDeployment、StatefulSetなどのAPIを使用して定義できます。 これらはメモリやCPUリソース、また実行すべきPodの数(レプリカ数)を含む、実行されるべきPodのテンプレートを示しています。 ワークロードはPodのレプリカ数を更新することで水平方向にスケールしたり、Podのコンテナに必要なリソースを更新することで垂直方向にスケールしたりできます。 この機能改善が入る前、Podのspecで定義されたコンテナリソースは不変であり、これらの詳細をPodテンプレート内で更新するにはPodの置き換えが必要でした。

しかし、再起動無しで既存のPodのリソース設定を動的に更新できるとしたらどうでしょうか？

KEP-1287は、まさにそのようなインプレースPod更新を可能にするためのものです。 これはv1.27でアルファとしてリリースされ、v1.33でベータに昇格しました。 これにより、ステートフルなプロセスをダウンタイムなしで垂直方向にスケールアップしたり、トラフィックが少ない時シームレスにスケールダウンすることができます。 さらには起動時に大きなリソースを割り当てて、初期設定が完了したら削減したりするなど、さまざまな可能性が開かれます。

この作業はSIG NodeとSIG Autoscalingが主導したKEP-1287: In-Place Update of Pod Resourcesの一環として行われました。

アルファ: .kubercによるkubectl向けユーザー設定の新しい記述オプション

v1.33にて、kubectlは新しいアルファ機能として、ユーザー設定をクラスター設定と分けて明示的に記述するファイル、.kubercを導入します。 このファイルにはkubectlのエイリアスや上書き設定(例えばServer-Side Applyをデフォルトで使用するなど)を含めることができますが、クラスター認証情報やホスト情報はkubeconfigに残しておく必要があります。

この分離によって、対象クラスターや使用するkubeconfigに関わらず、kubectlの操作に関わるユーザー設定は同じ物を使い回せるようになります。

このアルファ機能を有効にするためには、環境変数KUBECTL_KUBERC=trueを設定し、.kuberc設定ファイルを作成して下さい。 デフォルトの状態では、kubectlは~/.kube/kubercにこのファイルが無いか探します。 --kubercフラグを使用すると、代わりの場所を指定することもできます。

例: kubectl --kuberc /var/kube/rc

この作業はSIG CLIが主導したKEP-3104: Separate kubectl user preferences from cluster configsの一環として行われました。

GAに昇格した機能

これはv1.33リリース後にGAとなった改善点の一部です。

インデックス付きJobのインデックスごとのバックオフ制限

このリリースでは、インデックス付きJobのインデックスごとにバックオフ制限を設定できる機能がGAに昇格しました。 従来、Kubernetes JobのbackoffLimitパラメーターは、Job全体が失敗とみなされる前の再試行回数を指定していました。 この機能強化により、インデックス付きJob内の各インデックスが独自のバックオフ制限を持つことができるようになり、個々のタスクの再試行動作をより細かく制御できるようになりました。 これにより、特定のインデックスの失敗がJob全体を早期に終了させることなく、他のインデックスが独立して処理を継続できるようになります。

この作業はSIG Appsが主導したKEP-3850: Backoff Limit Per Index For Indexed Jobsの一環として行われました。

Job成功ポリシー

.spec.successPolicyを使用してユーザーはどのPodインデックスが成功する必要があるか(succeededIndexes)、何個のPodが成功する必要があるか(succeededCount)、またはその両方の組み合わせを指定できます。 この機能は、部分的な完了で十分なシミュレーションやリーダーの成功だけがJobの全体的な結果を決定するリーダー・ワーカーパターンなど、さまざまなワークロードに利点をもたらします。

この作業はSIG Appsが主導したKEP-3998: Job success/completion policyの一環として行われました。

バインドされたServiceAccountトークンのセキュリティ改善

この機能強化では一意のトークン識別子(すなわちJWT IDクレーム、JTIとも呼ばれる)やノード情報をトークン内に含めることで、より正確な検証と監査を可能にする機能などが導入されました。 さらに、ノード固有の制限をサポートし、トークンが指定されたノードでのみ使用可能であることを保証することで、トークンの不正使用や潜在的なセキュリティ侵害のリスクを低減します。 これらの改善は現在一般提供され、Kubernetesクラスター内のサービスアカウントトークンの全体的なセキュリティ態勢を強化することを目的としています。

この作業はSIG Authが主導したKEP-4193: Bound service account token improvementsの一環として行われました。

kubectlでのサブリソースサポート

--subresource引数が現在kubectlのサブコマンド(get、patch、edit、apply、replaceなど)で一般提供されるようになり、ユーザーはそれらをサポートするすべてのリソースのサブリソースを取得および更新できるようになりました。 サポートされているサブリソースの詳細については、Subresourcesをご覧ください。

この作業はSIG CLIが主導したKEP-2590: Add subresource support to kubectlの一環として行われました。

複数のサービスCIDR

この機能強化では、サービスIPの割り当てロジックの新しい実装が導入されました。 クラスター全体で、type: ClusterIPの各サービスには一意のIPアドレスが割り当てられる必要があります。 既に割り当てられている特定のClusterIPでサービスを作成しようとすると、エラーが返されます。 更新されたIPアドレス割り当てロジックは、ServiceCIDRとIPAddressという2つの新しく安定化したAPIオブジェクトを使用します。 現在一般提供されているこれらのAPIにより、クラスター管理者は(新しいServiceCIDRオブジェクトを作成することで)type: ClusterIPサービスに利用可能なIPアドレスの数を動的に増やすことができます。

この作業はSIG Networkが主導したKEP-1880: Multiple Service CIDRsの一環として行われました。

kube-proxyのnftablesバックエンド

kube-proxyのnftablesバックエンドがGAになり、Kubernetesクラスター内のサービス実装のパフォーマンスとスケーラビリティを大幅に向上させる新しい実装が追加されました。 互換性の理由から、Linuxノードではデフォルトでiptablesのままです。 試してみたい場合はMigrating from iptables mode to nftablesをご確認ください。

この作業はSIG Networkが主導したKEP-3866: nftables kube-proxy backendの一環として行われました。

trafficDistribution: PreferCloseによるTopology Aware Routing

このリリースでは、Topology Aware Routingとトラフィック分散がGAに昇格し、マルチゾーンクラスターでのサービストラフィックを最適化できるようになりました。 EndpointSliceのTopology Aware Hintによりkube-proxyなどのコンポーネントは同じゾーン内のエンドポイントへのトラフィックルーティングを優先できるようになり、レイテンシーとクロスゾーンデータ転送コストが削減されます。 これを基に、Serviceの仕様にtrafficDistributionフィールドが追加され、PreferCloseオプションによりネットワークトポロジーに基づいて最も近い利用可能なエンドポイントにトラフィックが誘導されます。 この構成はゾーン間通信を最小限に抑えることでパフォーマンスとコスト効率を向上させます。

この作業はSIG Networkが主導したKEP-4444: Traffic Distribution for ServicesとKEP-2433: Topology Aware Routingの一環として行われました。

SMT非対応ワークロードを拒否するオプション

この機能はCPUマネージャーにポリシーオプションを追加し、Simultaneous Multithreading(SMT)構成に適合しないワークロードを拒否できるようにしました。 現在一般提供されているこの機能強化により、PodがCPUコアの排他的使用を要求する場合、CPUマネージャーはSMT対応システムで完全なコアペア(プライマリスレッドと兄弟スレッド両方を含む)の割り当てを強制できるようになり、ワークロードが意図しない方法でCPUリソースを共有するシナリオを防止します。

この作業はSIG Nodeが主導したKEP-2625: node: cpumanager: add options to reject non SMT-aligned workloadの一環として行われました。

matchLabelKeysとmismatchLabelKeysを使用したPodアフィニティまたはアンチアフィニティの定義

matchLabelKeysとmismatchLabelKeysフィールドがPodアフィニティ条件で利用可能になり、ユーザーはPodが共存する(アフィニティ)または共存しない(アンチアフィニティ)べき範囲を細かく制御できるようになりました。 これらの新しく安定化したオプションは、既存のlabelSelectorメカニズムを補完します。 affinityフィールドは、多用途なローリングアップデートの強化されたスケジューリングや、グローバル構成に基づいてツールやコントローラーによって管理されるサービスの分離を容易にします。

この作業はSIG Schedulingが主導したKEP-3633: Introduce MatchLabelKeys to Pod Affinity and Pod Anti Affinityの一環として行われました。

Podトポロジー分散制約スキューの計算時にtaintとtolerationを考慮する

この機能強化はPodTopologySpreadにnodeAffinityPolicyとnodeTaintsPolicyという2つのフィールドを導入しました。 これらのフィールドにより、ユーザーはノード間のPod分散のスキュー(偏り)を計算する際にノードアフィニティルールとノードテイントを考慮すべきかどうかを指定できます。 デフォルトでは、nodeAffinityPolicyはHonorに設定されており、Podのノードアフィニティまたはセレクターに一致するノードのみが分散計算に含まれることを意味します。 nodeTaintsPolicyはデフォルトでIgnoreに設定されており、指定されない限りノードテイントは考慮されないことを示します。 この機能強化によりPod配置のより細かい制御が可能になり、Podがアフィニティとテイント許容の両方の要件を満たすノードにスケジュールされることを保証し、制約を満たさないためにPodが保留状態のままになるシナリオを防止します。

この作業はSIG Schedulingが主導したKEP-3094: Take taints/tolerations into consideration when calculating PodTopologySpread skewの一環として行われました。

Volume Populators

v1.24でベータとしてリリースされた後、Volume Populators はv1.33でGAに昇格しました。 この新しく安定化した機能は、ユーザーがPersistentVolumeClaim(PVC)クローンやボリュームスナップショットだけでなく、様々なソースからのデータでボリュームを事前に準備する方法を提供します。 このメカニズムはPersistentVolumeClaim内のdataSourceRefフィールドに依存しています。 このフィールドは既存のdataSourceフィールドよりも柔軟性が高く、カスタムリソースをデータソースとして使用することができます。

特別なコントローラーであるvolume-data-source-validatorは、VolumePopulatorという名前のAPI種別のための新しく安定化したCustomResourceDefinition(CRD)と共に、これらのデータソース参照を検証します。 VolumePopulator APIにより、ボリュームポピュレーターコントローラーはサポートするデータソースのタイプを登録できます。 ボリュームポピュレーターを使用するには、適切なCRDでクラスターをセットアップする必要があります。

この作業はSIG Storageが主導したKEP-1495: Generic data populatorsの一環として行われました。

PersistentVolumeの再利用ポリシーを常に尊重する

この機能強化はPersistent Volume(PV)の再利用ポリシーが一貫して尊重されない問題に対処したもので、ストレージリソースのリークを防ぎます。 具体的にはPVがその関連するPersistent Volume Claim(PVC)より先に削除された場合、再利用ポリシー(Delete)が実行されず、基盤となるストレージアセットがそのまま残ってしまう可能性がありました。 これを緩和するために、Kubernetesは関連するPVにファイナライザーを設定し、削除順序に関係なく再利用ポリシーが適用されるようになりました。 この機能強化により、ストレージリソースの意図しない保持を防ぎ、PVライフサイクル管理の一貫性を維持します。

この作業はSIG Storageが主導したKEP-2644: Always Honor PersistentVolume Reclaim Policyの一環として行われました。

ベータの新機能

これはv1.33リリース後にベータとなった改善点の一部です。

Windowsのkube-proxyにおけるDirect Service Return (DSR)のサポート

DSRは、ロードバランサーを経由するリターントラフィックがロードバランサーをバイパスしてクライアントに直接応答できるようにすることでパフォーマンスを最適化します。 これによりロードバランサーの負荷が軽減され、全体的なレイテンシーも低減されます。 Windows上のDSRに関する情報は、Direct Server Return (DSR) in a nutshellをお読みください。

v1.14で最初に導入されたDSRのサポートは、KEP-5100: Support for Direct Service Return (DSR) and overlay networking in Windows kube-proxyの一環としてSIG Windowsによりベータに昇格しました。

構造化パラメーターのサポート

構造化パラメーターのサポートはKubernetes v1.33でベータ機能として継続される中、Dynamic Resource Allocation(DRA)のこの中核部分に大幅な改善が見られました。 新しいv1beta2バージョンはresource.k8s.io APIを簡素化し、名前空間クラスターのeditロールを持つ一般ユーザーが現在DRAを使用できるようになりました。

kubeletは現在シームレスなアップグレードサポートを含み、DaemonSetとしてデプロイされたドライバーがローリングアップデートメカニズムを使用できるようになっています。 DRA実装では、これによりResourceSliceの削除と再作成が防止され、アップグレード中も変更されないままにすることができます。 さらに、ドライバーの登録解除後にkubeletがクリーンアップを行う前に30秒の猶予期間が導入され、ローリングアップデートを使用しないドライバーのサポートが向上しました。

この作業はSIG Node、SIG Scheduling、SIG Autoscalingを含む機能横断チームであるWG Device ManagementによるKEP-4381: DRA: structured parametersの一環として行われました。

ネットワークインターフェース向けDynamic Resource Allocation(DRA)

v1.32で導入されたDRAによるネットワークインターフェースデータの標準化された報告がv1.33でベータに昇格しました。 これにより、よりネイティブなKubernetesネットワークの統合が可能になり、ネットワークデバイスの開発と管理が簡素化されます。 これについては以前にv1.32リリース発表ブログで説明されています。

この作業はSIG Network、SIG Node、およびWG Device Managementが主導したKEP-4817: DRA: Resource Claim Status with possible standardized network interface dataの一環として行われました。

スケジューラーがactiveQにPodを持たない場合に、スケジュールされていないPodを早期に処理

この機能はキュースケジューリングの動作を改善します。 裏側では、スケジューラーはactiveQが空の場合に、エラーによってバックオフされていないPodをbackoffQからポップすることでこれを実現しています。 以前は、activeQが空の場合でもスケジューラーはアイドル状態になってしまいましたが、この機能強化はそれを防止することでスケジューリング効率を向上させます。

この作業はSIG Schedulingが主導したKEP-5142: Pop pod from backoffQ when activeQ is emptyの一環として行われました。

Kubernetesスケジューラーにおける非同期プリエンプション

プリエンプションは、優先度の低いPodを退避させることで、優先度の高いPodが必要なリソースを確保できるようにします。 v1.32でアルファとして導入された非同期プリエンプションがv1.33でベータに昇格しました。 この機能強化により、Podを削除するためのAPIコールなどの重い操作が並行して処理されるようになり、スケジューラーは遅延なく他のPodのスケジューリングを継続できます。 この改善は特にPodの入れ替わりが激しいクラスターやスケジューリングの失敗が頻繁に発生するクラスターで有益であり、より効率的で回復力のあるスケジューリングプロセスを確保します。

この作業はSIG Schedulingが主導したKEP-4832: Asynchronous preemption in the schedulerの一環として行われました。

ClusterTrustBundle

X.509トラストアンカー(ルート証明書)を保持するために設計されたクラスタースコープリソースであるClusterTrustBundleがv1.33でベータに昇格しました。 このAPIにより、クラスター内の証明書署名者がX.509トラストアンカーをクラスターワークロードに公開および通信することが容易になります。

この作業はSIG Authが主導したKEP-3257: ClusterTrustBundles (previously Trust Anchor Sets)の一環として行われました。

きめ細かいSupplementalGroupsの制御

v1.31で導入されたこの機能はv1.33でベータに昇格し、現在はデフォルトで有効になっています。 クラスターでフィーチャーゲートのSupplementalGroupsPolicyが有効になっている場合、PodのsecurityContext内のsupplementalGroupsPolicyフィールドは2つのポリシーをサポートします: デフォルトのMergeポリシーはコンテナイメージの/etc/groupファイルからのグループと指定されたグループを結合することで後方互換性を維持し、新しいStrictポリシーは明示的に定義されたグループのみを適用します。

この機能強化は、コンテナイメージからの暗黙的なグループメンバーシップが意図しないファイルアクセス権限につながり、ポリシー制御をバイパスする可能性があるセキュリティ上の懸念に対処するのに役立ちます。

この作業はSIG Nodeが主導したKEP-3619: Fine-grained SupplementalGroups controlの一環として行われました。

イメージをボリュームとしてマウントする機能をサポート

v1.31で導入されたPodでOpen Container Initiative(OCI)イメージをボリュームとして使用する機能のサポートがベータに昇格しました。 この機能により、ユーザーはPod内でイメージ参照をボリュームとして指定し、コンテナ内でボリュームマウントとして再利用できるようになります。 これにより、ボリュームデータを別々にパッケージ化し、メインイメージに含めることなくPod内のコンテナ間で共有する可能性が開かれ、脆弱性を減らしイメージ作成を簡素化します。

この作業はSIG NodeとSIG Storageが主導したKEP-4639: VolumeSource: OCI Artifact and/or Imageの一環として行われました。

Linux Podにおけるユーザー名前空間のサポート

執筆時点で最も古いオープンなKEPの1つであるKEP-127は、Pod用のLinuxユーザー名前空間を使用したPodセキュリティの改善です。 このKEPは2016年後半に最初に提案され、複数の改訂を経て、v1.25でアルファリリース、v1.30で初期ベータ(デフォルトでは無効)となり、v1.33の一部としてデフォルトで有効なベータに移行しました。

このサポートは、手動でpod.spec.hostUsersを指定してオプトインしない限り、既存のPodに影響を与えません。 v1.30の先行紹介ブログで強調されているように、これは脆弱性を軽減するための重要なマイルストーンです。

この作業はSIG Nodeが主導したKEP-127: Support User Namespaces in podsの一環として行われました。

PodのprocMountオプション

v1.12でアルファとして導入され、v1.31でデフォルト無効のベータだったprocMountオプションが、v1.33でデフォルト有効のベータに移行しました。 この機能強化はユーザーが/procファイルシステムへのアクセスを細かく調整できるようにすることでPod分離を改善します。 具体的には、PodのsecurityContextにフィールドを追加し、特定の/procパスをマスクしたり読み取り専用としてマークするデフォルトの動作をオーバーライドできるようにします。 これは特に、ユーザーがユーザー名前空間を使用してKubernetes Pod内で非特権コンテナを実行したい場合に便利です。 通常、コンテナランタイム(CRI実装を介して)は厳格な/procマウント設定で外部コンテナを起動します。 しかし、非特権Pod内でネストされたコンテナを正常に実行するには、ユーザーはそれらのデフォルト設定を緩和するメカニズムが必要であり、この機能はまさにそれを提供します。

この作業はSIG Nodeが主導したKEP-4265: add ProcMount optionの一環として行われました。

NUMAノード間でCPUを分散させるCPUManagerポリシー

この機能はCPUManagerに、単一ノードに集中させるのではなく非一様メモリアクセス(NUMA)ノード間でCPUを分散させる新しいポリシーオプションを追加します。 これにより複数のNUMAノード間でワークロードのバランスを取ることでCPUリソースの割り当てを最適化し、マルチNUMAシステムにおけるパフォーマンスとリソース使用率を向上させます。

この作業はSIG Nodeが主導したKEP-2902: Add CPUManager policy option to distribute CPUs across NUMA nodes instead of packing themの一環として行われました。

コンテナのPreStopフックのゼロ秒スリープ

Kubernetes 1.29ではPodのpreStopライフサイクルフックにSleepアクションが導入され、コンテナが終了する前に指定された時間だけ一時停止できるようになりました。 これにより、接続のドレイン(排出)やクリーンアップ操作などのタスクを容易にするコンテナのシャットダウンを遅らせるための簡単な方法が提供されます。

preStopフックのSleepアクションは、現在ベータ機能としてゼロ秒の時間を受け付けることができます。 これにより、preStopフックが必要だが遅延が不要な場合に便利な、無操作(no-op)のpreStopフックを定義できるようになります。

この作業はSIG Nodeが主導したKEP-3960: Introducing Sleep Action for PreStop HookおよびKEP-4818: Allow zero value for Sleep Action of PreStop Hookの一環として行われました。

Kubernetesネイティブ型の宣言的検証のための内部ツール

ひそかに、Kubernetesの内部はオブジェクトとオブジェクトへの変更を検証するための新しいメカニズムの使用を開始しています。 Kubernetes v1.33では、Kubernetesコントリビューターが宣言的な検証ルールを生成するために使用する内部ツールvalidation-genを導入しています。 全体的な目標は、開発者が検証制約を宣言的に指定できるようにすることでAPI検証の堅牢性と保守性を向上させ、手動コーディングエラーを減らし、コードベース全体での一貫性を確保することです。

この作業はSIG API Machineryが主導したKEP-5073: Declarative Validation Of Kubernetes Native Types With validation-genの一環として行われました。

アルファの新機能

これはv1.33リリース後にアルファとなった改善点の一部です。

HorizontalPodAutoscalerの設定可能な許容値

この機能は、HorizontalPodAutoscaler設定可能な許容値を導入し、小さなメトリクス変動に対するスケーリング反応を抑制します。

この作業はSIG Autoscalingが主導したKEP-4951: Configurable tolerance for Horizontal Pod Autoscalersの一環として行われました。

設定可能なコンテナの再起動遅延

CrashLoopBackOffの処理方法を微調整できる機能です。

この作業はSIG Nodeが主導したKEP-4603: Tune CrashLoopBackOffの一環として行われました。

カスタムコンテナの停止シグナル

Kubernetes v1.33より前では、停止シグナルはコンテナイメージ定義内でのみ設定可能でした(例えば、イメージメタデータのStopSignalフィールドを介して)。 終了動作を変更したい場合は、カスタムコンテナイメージをビルドする必要がありました。 Kubernetes v1.33で(アルファの)フィーチャーゲートであるContainerStopSignalsを有効にすることで、Pod仕様内で直接カスタム停止シグナルを定義できるようになりました。 これはコンテナのlifecycle.stopSignalフィールドで定義され、Podのspec.os.nameフィールドが存在する必要があります。 指定されない場合、コンテナはイメージで定義された停止シグナル(存在する場合)、またはコンテナランタイムのデフォルト(通常Linuxの場合はSIGTERM)にフォールバックします。

この作業はSIG Nodeが主導したKEP-4960: Container Stop Signalsの一環として行われました。

豊富なDRA機能強化

Kubernetes v1.33は、今日の複雑なインフラストラクチャ向けに設計された機能を備えたDynamic Resource Allocation (DRA)の開発を継続しています。 DRAはPod間およびPod内のコンテナ間でリソースを要求および共有するためのAPIです。 通常、それらのリソースはGPU、FPGA、ネットワークアダプターなどのデバイスです。

以下はv1.33で導入されたすべてのアルファのDRAのフィーチャーゲートです:

  • ノードテイントと同様に、フィーチャーゲートのDRADeviceTaintsを有効にすることで、デバイスはTaintとTolerationをサポートします。 管理者またはコントロールプレーンコンポーネントはデバイスにテイントを付けて使用を制限できます。 テイントが存在する間、それらのデバイスに依存するPodのスケジューリングを一時停止したり、テイントされたデバイスを使用するPodを退避させたりすることができます。
  • フィーチャーゲートのDRAPrioritizedListを有効にすることで、DeviceRequestsはfirstAvailableという新しいフィールドを取得します。 このフィールドは順序付けられたリストで、ユーザーが特定のハードウェアが利用できない場合に何も割り当てないことを含め、リクエストが異なる方法で満たされる可能性を指定できるようにします。
  • フィーチャーゲートのDRAAdminAccessを有効にすると、resource.k8s.io/admin-access: "true"でラベル付けされた名前空間内でResourceClaimまたはResourceClaimTemplateオブジェクトを作成する権限を持つユーザーのみがadminAccessフィールドを使用できます。 これにより、管理者以外のユーザーがadminAccess機能を誤用できないようになります。
  • v1.31以降、デバイスパーティションの使用が可能でしたが、ベンダーはデバイスを事前にパーティション分割し、それに応じて通知する必要がありました。 v1.33でフィーチャーゲートのDRAPartitionableDevicesを有効にすることで、デバイスベンダーは重複するものを含む複数のパーティションを通知できます。 Kubernetesスケジューラーはワークロード要求に基づいてパーティションを選択し、競合するパーティションの同時割り当てを防止します。 この機能により、ベンダーは割り当て時に動的にパーティションを作成する機能を持ちます。 割り当てと動的パーティショニングは自動的かつユーザーに透過的に行われ、リソース使用率の向上を可能にします。

これらのフィーチャーゲートは、フィーチャーゲートのDynamicResourceAllocationも有効にしない限り効果がありません。

この作業はSIG Node、SIG Scheduling、SIG Authが主導した KEP-5055: DRA: device taints and tolerations、 KEP-4816: DRA: Prioritized Alternatives in Device Requests、 KEP-5018: DRA: AdminAccess for ResourceClaims and ResourceClaimTemplates、 およびKEP-4815: DRA: Add support for partitionable devicesの一環として行われました。

IfNotPresentとNeverのイメージに対する認証を行う堅牢なimagePullPolicy

この機能により、ユーザーはイメージがノード上に既に存在するかどうかに関わらず、新しい資格情報セットごとにkubeletがイメージプル認証チェックを要求することを確実にできます。

この作業はSIG Authが主導したKEP-2535: Ensure secret pulled imagesの一環として行われました。

Downward APIを通じて利用可能なノードトポロジーラベル

この機能により、ノードトポロジーラベルがダウンワードAPIを通じて公開されるようになります。 Kubernetes v1.33より前では、基盤となるノードについてKubernetes APIに問い合わせるために初期化コンテナを使用する回避策が必要でした。 このアルファ機能により、ワークロードがノードトポロジー情報にアクセスする方法が簡素化されます。

この作業はSIG Nodeが主導したKEP-4742: Expose Node labels via downward APIの一環として行われました。

生成番号と観測された生成番号によるより良いPodステータス

この変更以前は、metadata.generationフィールドはPodでは使用されていませんでした。 metadata.generationをサポートするための拡張に加えて、この機能はstatus.observedGenerationを導入し、より明確なPodステータスを提供します。

この作業はSIG Nodeが主導したKEP-5067: Pod Generationの一環として行われました。

kubeletのCPU Managerによる分割レベル3キャッシュアーキテクチャのサポート

これまでのkubeletのCPU Managerは分割L3キャッシュアーキテクチャ(Last Level Cache、またはLLCとも呼ばれる)を認識せず、分割L3キャッシュを考慮せずにCPU割り当てを分散させる可能性があり、ノイジーネイバー問題を引き起こす可能性がありました。 このアルファ機能はCPU Managerを改善し、より良いパフォーマンスのためにCPUコアをより適切に割り当てます。

この作業はSIG Nodeが主導したKEP-5109: Split L3 Cache Topology Awareness in CPU Managerの一環として行われました。

スケジューリング改善のためのPSI(Pressure Stall Information)メトリクス

この機能は、Linuxノードにcgroupv2を使用してPSI統計とメトリクスを提供するサポートを追加します。 これによりリソース不足を検出し、Podスケジューリングのためのより細かい制御をノードに提供できます。

この作業はSIG Nodeが主導したKEP-4205: Support PSI based on cgroupv2の一環として行われました。

kubeletによるシークレットレスイメージPull

kubeletのオンディスク認証情報プロバイダーが、オプションでKubernetes ServiceAccount(SA)トークンの取得をサポートするようになりました。 これにより、クラウドプロバイダーはOIDC互換のアイデンティティソリューションとより適切に統合でき、イメージレジストリとの認証が簡素化されます。

この作業はSIG Authが主導したKEP-4412: Projected service account tokens for Kubelet image credential providersの一環として行われました。

v1.33での昇格、非推奨化、および削除

GAへの昇格

これは安定版(一般提供、GAとも呼ばれる)に昇格したすべての機能を一覧にしたものです。 アルファからベータへの昇格や新機能を含む更新の完全なリストについては、リリースノートをご覧ください。

このリリースには、GAに昇格した合計18の機能強化が含まれています:

非推奨化と削除

Kubernetesの開発と成熟に伴い、プロジェクト全体の健全性を向上させるために機能が非推奨化されたり、削除されたり、より良い機能に置き換えられたりすることがあります。 このプロセスに関する詳細は、Kubernetes非推奨ポリシーを参照してください。 これらの非推奨化や削除の多くは、Kubernetes v1.33の先行紹介ブログで告知されました。

Endpoints APIの非推奨化

v1.21以降GAされたEndpointSlice APIは、元のEndpoint APIを事実上置き換えました。 元のEndpoint APIはシンプルで分かりやすかったものの、多数のネットワークエンドポイントへスケーリングする際にいくつかの課題がありました。 EndpointSlice APIにはデュアルスタックネットワーキングなどの新機能が導入され、これにより元のEndpoint APIは非推奨化されることになりました。

この非推奨化は、ワークロードやスクリプトからEndpoint APIを直接使用しているユーザーにのみ影響します。 これらのユーザーは代わりにEndpointSliceを使用するように移行する必要があります。 非推奨化による影響と移行計画に関する詳細を記載した専用のブログ記事が公開される予定です。

詳細はKEP-4974: Deprecate v1.Endpointsで確認できます。

Nodeステータスにおけるkube-proxyバージョン情報の削除

v1.31の「Deprecation of status.nodeInfo.kubeProxyVersion field for Nodes」で強調されているように、v1.31での非推奨化に続き、Nodeの.status.nodeInfo.kubeProxyVersionフィールドがv1.33で削除されました。

このフィールドはkubeletによって設定されていましたが、その値は一貫して正確ではありませんでした。 v1.31以降デフォルトで無効化されていたため、このフィールドはv1.33で完全に削除されました。

詳細はKEP-4004: Deprecate status.nodeInfo.kubeProxyVersion fieldで確認できます。

インツリーのgitRepoボリュームドライバーの削除

gitRepoボリュームタイプは、約7年前のv1.11から非推奨化されていました。 非推奨化されて以降、gitRepoボリュームタイプがノード上でrootとしてリモートコード実行を得るためにどのように悪用されうるかといった、セキュリティ上の懸念がありました。 v1.33では、インツリーのドライバーコードが削除されます。

代替手段としてgit-syncやinitコンテナがあります。 Kubernetes APIのgitVolumesは削除されないため、gitRepoボリュームを持つPodはkube-apiserverによって受け入れられます。 しかし、フィーチャーゲートのGitRepoVolumeDriverがfalseに設定されているkubeletはそれらを実行せず、ユーザーに適切なエラーを返します。 これにより、ユーザーはワークロードを修正するための十分な時間を確保するために、3バージョン分の期間、ドライバーの再有効化をオプトインできます。

kubeletのフィーチャーゲートとインツリーのプラグインコードは、v1.39リリースで削除される予定です。

詳細はKEP-5040: Remove gitRepo volume driverで確認できます。

Windows Podにおけるホストネットワークサポートの削除

Windows Podのネットワーキングは、コンテナがNodeのネットワーク名前空間を使用できるようにすることでLinuxとの機能パリティを達成し、クラスター密度を向上させることを目指していました。 元の実装はv1.26でアルファとして導入されましたが、予期せぬcontainerdの挙動に直面し、代替ソリューションが存在したため、Kubernetesプロジェクトは関連するKEPを取り下げることを決定しました。 サポートはv1.33で完全に削除されました。

これは、ホストネットワークおよびホストレベルのアクセスを提供するHostProcessコンテナには影響しないことに注意してください。 v1.33で取り下げられたKEPは、ホストネットワークのみを提供することに関するものでしたが、Windowsのネットワーキングロジックにおける技術的な制限のため、安定することはありませんでした。

詳細はKEP-3503: Host network support for Windows podsで確認できます。

リリースノート

Kubernetes v1.33リリースの詳細については、リリースノートをご覧ください。

入手方法

Kubernetes v1.33はGitHubまたはKubernetes公式サイトのダウンロードページからダウンロードできます。

Kubernetesを始めるには、チュートリアルをチェックするか、minikubeを使用してローカルKubernetesクラスターを実行してください。 また、kubeadmを使用して簡単にv1.33をインストールすることもできます。

リリースチーム

Kubernetesはそのコミュニティのサポート、コミットメント、そして懸命な働きによってのみ実現可能です。 リリースチームは、ユーザーが依存するKubernetesリリースを構成する多くの部分を構築するために協力する、献身的なコミュニティボランティアによって構成されています。 これには、コード自体からドキュメンテーションやプロジェクト管理まで、コミュニティのあらゆる分野の人々の専門的なスキルが必要です。

私たちは、Kubernetes v1.33リリースをコミュニティに提供するために熱心に取り組んだ時間について、リリースチーム全体に感謝します。 リリースチームのメンバーは、初めてのShadow(見習い)から、複数のリリースサイクルで培われた経験を持ち、復帰をしたチームリードまで幅広く存在します。 このリリースサイクルでは、リリースノートとDocsのサブチームを統合し、Docsサブチームに統一するという新しいチーム構造が採用されました。 新しいDocsチームから関連情報とリソースを整理する綿密な努力のおかげで、リリースノートとDocsの追跡は円滑かつ成功した移行を実現しました。 最後に、成功したリリースサイクルを通してのサポート、支援、誰もが効果的に貢献できるようにする取り組み、そしてリリースプロセスを改善するための課題に対して、リリースリードのNina Polshakovaに心より感謝します。

プロジェクトの活動状況

CNCF K8sのDevStatsプロジェクトは、Kubernetesおよび様々なサブプロジェクトの活動状況に関する興味深いデータポイントを集計しています。 これには個人の貢献から貢献企業数まで含まれ、このエコシステムの発展に費やされる努力の深さと広さを示しています。

v1.33リリースサイクル(2025年1月13日から4月23日までの15週間)において、Kubernetesには最大121の異なる企業と570人の個人から貢献がありました(執筆時点では、リリース日の数週間前の数値です)。 より広範なクラウドネイティブエコシステムでは、この数字は435社、合計2400人のコントリビューターに達しています。 データソースはこのダッシュボードで確認できます。 前回のリリースv1.32の活動データと比較すると、企業や個人からの貢献レベルは同様であり、コミュニティの関心と参加が引き続き強いことを示しています。

なお、「貢献」とはコミットの作成、コードレビュー、コメント、IssueやPRの作成、PRのレビュー(ブログやドキュメントを含む)、またはIssueやPRへのコメントを行うことを指します。 貢献に興味がある場合は、公式ドキュメントのコントリビューター向けのはじめにをご覧ください。

Kubernetesプロジェクトとコミュニティの全体的な活動状況についてさらに詳しく知るには、DevStatsをチェックしてください。

イベント情報

今後開催予定のKubernetesおよびクラウドネイティブイベント(KubeCon + CloudNativeCon、KCDなど)や、世界各地で開催される主要なカンファレンスについて紹介します。 Kubernetesコミュニティの最新情報を入手し、参加しましょう！

2025年5月

2025年6月

2025年7月

2025年8月

最新のKCD情報はこちらでご確認いただけます。

ウェビナーのご案内

Kubernetes v1.33リリースチームのメンバーと一緒に 2025年5月16日(金)午後4時(UTC) から、このリリースのハイライトやアップグレードの計画に役立つ非推奨事項や削除事項について学びましょう。 詳細および参加登録は、CNCFオンラインプログラム・サイトのイベントページをご覧ください。

参加方法

Kubernetesに関わる最も簡単な方法は、あなたの興味に合ったSpecial Interest Groups (SIGs)のいずれかに参加することです。 Kubernetesコミュニティに向けて何か発信したいことはありますか？ 毎週のコミュニティミーティングや、以下のチャンネルであなたの声を共有してください。 継続的なフィードバックとサポートに感謝いたします。

  • 最新情報はBlueSkyの@kubernetes.ioをフォローしてください
  • Discussでコミュニティディスカッションに参加してください
  • Slackでコミュニティに参加してください
  • Server FaultかStack Overflowで質問したり、回答したりしてください
  • あなたのKubernetesに関するストーリーを共有してください
  • Kubernetesの最新情報はブログでさらに詳しく読むことができます
  • Kubernetes Release Teamについての詳細はこちらをご覧ください