Kubernetes v1.35: Timbernetes (The World Tree Release)

By Kubernetes v1.35 Release Team | 翻訳: Taisuke Okamoto (PLAID, Inc.) |

編集者: Aakanksha Bhende, Arujjwal Negi, Chad M. Crowell, Graziano Casto, Swathi Rao

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

このリリースは60個の機能改善で構成されています。 それらのうち、GAへの昇格が17個、ベータへの移行が19個、アルファとしての導入が22個となっています。

また、このリリースにはいくつかの非推奨化と削除があります。 これらに必ず目を通してください。

リリースのテーマとロゴ

2025年はOctarine: The Color of Magic(v1.33)の輝きで始まり、Of Wind & Will(v1.34)の風に乗って進んできました。 そして私たちは、多くの世界をつなぐ生命の木、北欧神話のユグドラシルにインスパイアされた「世界樹」に手を伸ばしながら、この一年を締めくくります。 偉大な木が年輪を重ねるように、Kubernetesもリリースを重ねて成長し、グローバルコミュニティの献身によって形作られています。

その中心には、地球を包み込むKubernetesの舵輪があります。 それを支えているのは、日々の仕事や人生の変化を乗り越えながら、着実にオープンソースの管理を続ける、回復力のあるメンテナー、コントリビューター、そしてユーザーたちです。 彼らは古いAPIを剪定し、新しい機能を接ぎ木し、世界最大級のオープンソースプロジェクトの一つを健全に保っています。

ロゴには、3匹のリスが木を守る姿が描かれています。 レビュアーを象徴する、LGTMの巻物を持った魔法使い。 新しいブランチを切り出すリリースチームを象徴する、斧とKubernetesの盾を持った戦士。 そして、山積みのIssueに光をもたらすトリアージ担当者を象徴する、ランタンを持ったローグです。

彼らは、より大きな冒険パーティーを代表しています。 Kubernetes v1.35は、世界樹に新たな年輪を刻みます。 それは多くの手によって、多くの道を経て形作られた新鮮な一刻であり、根を深く張りながら枝をより高く伸ばし続けるコミュニティの証です。

主なアップデート情報

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

Stable: Podリソースのインプレース機能の更新

PodリソースのインプレースがGA(General Availability)に昇格しました。 この機能により、Podやコンテナを再起動せずにCPUやメモリリソースを調整できます。 以前は、このような変更にはPodの再作成が必要で、特にステートフルアプリケーションやバッチアプリケーションでワークロードの中断を招く可能性がありました。 また、これまでのKubernetesリリースでは、既存のPodに対してインフラストラクチャのリソース設定(requestsとlimits)のみを変更することが許可されていました。 新しいインプレース機能により、中断のないスムーズな垂直スケーリングが可能になり、効率が向上し、開発もシンプルになります。

この作業はSIG Nodeが主導したKEP #1287の一環として行われました。

ベータ: Workload IdentityとセキュリティのためのPod証明書

以前は、Podに証明書を配布するには外部コントローラー(cert-manager、SPIFFE/SPIRE)、CRDオーケストレーション、およびSecret管理が必要で証明書のローテーションはサイドカーやInitコンテナで処理されていました。 Kubernetes v1.35では、自動証明書ローテーションによるネイティブなWorkload Identityが可能になり、サービスメッシュやゼロトラストアーキテクチャが大幅に簡素化されます。

kubeletが鍵を生成し、PodCertificateRequestを介して証明書を要求し、クレデンシャルバンドルをPodのファイルシステムに直接書き込むようになりました。 kube-apiserverはアドミッション時にノード制限を強制し、サードパーティの署名者が誤ってノード分離の境界に違反するという最も一般的な落とし穴を排除します。 これにより、発行パスにBearerトークンを含まない純粋なmTLSフローが可能になります。

この作業はSIG Authが主導したKEP #4317の一環として行われました。

アルファ: スケジューリング前のノード機能宣言

コントロールプレーンで新機能が有効になっていてもノードが古いバージョンのままである場合(Kubernetesのスキューポリシーで許可されている)、スケジューラーはその機能を必要とするPodを、互換性のない古いノードに配置してしまうことがあります。 ノード機能宣言フレームワークにより、ノードは自身がサポートするKubernetes機能を宣言できるようになります。 この新しいアルファ機能を有効にすると、ノードは自身がサポートする機能を報告し、新しい.status.declaredFeaturesフィールドを介してこの情報をコントロールプレーンに公開します。 その後、kube-scheduler、アドミッションコントローラー、およびサードパーティコンポーネントがこれらの宣言を使用できます。 例えば、スケジューリングやAPI検証の制約を強制して、Podが互換性のあるノードでのみ実行されるようにできます。

この作業はSIG Nodeが主導したKEP #5328の一環として行われました。

GAに昇格した機能

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

PreferSameNodeによるトラフィック分散

ServiceのtrafficDistributionフィールドが更新され、トラフィックルーティングをより明示的に制御できるようになりました。 新しいオプションPreferSameNodeが導入され、ローカルノード上のエンドポイントが利用可能な場合はそれを厳密に優先し、利用できない場合にのみリモートエンドポイントにフォールバックするようにServiceを設定できます。

同時に、既存のPreferCloseオプションはPreferSameZoneに名称が変更されました。 この変更により、トラフィックが現在のアベイラビリティゾーン内で優先されることが明示され、APIが自己説明的になりました。 PreferCloseは後方互換性のために保持されていますが、PreferSameZoneがゾーンルーティングの標準となり、ノードレベルとゾーンレベルの優先設定が明確に区別されるようになりました。

この作業はSIG Networkが主導したKEP #3015の一環として行われました。

Job APIのmanaged-byメカニズム

Job APIにmanagedByフィールドが追加され、外部コントローラーがJobのステータス同期を処理できるようになりました。 Kubernetes v1.35でGAに昇格したこの機能は、主にMultiKueueによって推進されています。 MultiKueueは、クラスター間でJobを分散実行するためのシステムです。 管理クラスターで作成したJobがワーカークラスターで実行され、その結果が管理クラスターに反映されます。 このワークフローを有効にするには、組み込みのJobコントローラーが特定のJobリソースに対してアクションを実行しないようにして、代わりにKueueコントローラーがステータス更新を管理できるようにする必要があります。

目的は、Jobの同期を別のコントローラーにクリーンに委譲できるようにすることです。 そのコントローラーにカスタムパラメーターを渡したり、CronJobの並行性ポリシーを変更したりすることは目的としていません。

この作業はSIG Appsが主導したKEP #4368の一環として行われました。

.metadata.generationによる信頼性の高いPodの更新追跡

これまで、Pod APIにはDeploymentなどの他のKubernetesオブジェクトにあるmetadata.generationフィールドがありませんでした。 このフィールドがなかったため、コントローラーやユーザーはkubeletがPodの仕様に対する最新の変更を実際に処理したかどうかを確実に検証する方法がありませんでした。 この曖昧さは、Podリソースのインプレース更新で特に問題でした。 リソースのリサイズ要求がいつ適用されたのかを正確に知ることが困難だったためです。

Kubernetes v1.33では、アルファ機能としてPodに.metadata.generationフィールドが追加されました。 このフィールドはv1.35のPod APIでGAになりました。 これにより、Podのspecが更新されるたびに.metadata.generationの値がインクリメントされます。 この改善の一環として、Pod APIには.status.observedGenerationフィールドも追加されました。 このフィールドは、kubeletが正常に確認して処理したgenerationを報告します。 また、Podの各conditionにも個別のobservedGenerationフィールドが含まれるようになり、クライアントはこれを報告したり監視したりできます。

この機能はv1.35でGAに昇格したため、すべてのワークロードで利用可能です。

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

トポロジーマネージャーのNUMAノード数制限の設定

トポロジーマネージャーは、アフィニティ計算時の状態爆発を防ぐため、サポートできるNUMAノードの最大数として8というハードコードされた制限を使用していました。 (ここで重要な点があります。NUMAノード はKubernetes APIのNodeとは異なります。) このNUMAノード数の制限により、8つを超えるNUMAノードを持つCPUアーキテクチャを搭載した最新のハイエンドサーバーをKubernetesで十分に活用できませんでした。

Kubernetes v1.31では、トポロジーマネージャーのポリシー設定に新しいベータオプションmax-allowable-numa-nodesが導入されました。 Kubernetes v1.35では、このオプションがGAになりました。 これを有効にすることで、クラスター管理者は8つを超えるNUMAノードを持つサーバーを使用できます。

この設定オプションはGAですが、Kubernetesコミュニティは大規模なNUMAホストでのパフォーマンスが低いことを認識しており、これを改善することを目的とした改善提案 (KEP-5726)があります。 詳細については、ノードのトポロジー管理ポリシーを制御するをご覧ください。

この作業はSIG Nodeが主導したKEP #4622の一環として行われました。

ベータの新機能

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

Downward APIによるノードトポロジーラベルの公開

Pod内からリージョンやゾーンなどのノードトポロジー情報にアクセスするには、通常Kubernetes APIサーバーへのクエリが必要でした。 この方法は機能しますが、インフラストラクチャのメタデータを取得するためだけに広範なRBAC権限やサイドカーコンテナが必要となり、複雑さとセキュリティリスクが生じていました。 Kubernetes v1.35では、Downward APIを介してノードトポロジーラベルを直接公開する機能がベータに昇格しました。

kubeletは、topology.kubernetes.io/zoneやtopology.kubernetes.io/regionなどの標準トポロジーラベルを、環境変数またはProjected VolumeファイルとしてPodに注入できるようになりました。 主な利点は、ワークロードがトポロジーを認識するためのより安全で効率的な方法が提供されることです。 これにより、アプリケーションはAPIサーバーに依存することなく、アベイラビリティゾーンやリージョンにネイティブに適応できます。 最小権限の原則を守ることでセキュリティが強化され、クラスター設定も簡素化されます。

注意: Kubernetesは、Downward APIへの入力として使用できるように、利用可能なトポロジーラベルをすべてのPodに注入するようになりました。 v1.35へのアップグレードにより、ほとんどのクラスター管理者は各Podにいくつかの新しいラベルが追加されていることに気づくでしょう。 これは設計の一部として想定された動作です。

この作業はSIG Nodeが主導したKEP #4742の一環として行われました。

Storage Version Migrationのネイティブサポート

Kubernetes v1.35では、Storage Version Migrationのネイティブサポートがベータに昇格し、デフォルトで有効になりました。 この変更により、マイグレーションロジックがKubernetesコントロールプレーンのコア(「in-tree」)に直接統合され、外部ツールへの依存がなくなりました。

これまで管理者は、スキーマの更新や保存データの再暗号化のために、手動の「読み取り/書き込みループ」(多くの場合kubectl getをkubectl replaceにパイプする方法)に頼っていました。 この方法は非効率で、特にSecretのような大規模なリソースでは競合が発生しやすいものでした。 このリリースでは、組み込みコントローラーが更新の競合と整合性トークンを自動的に処理し、最小限の運用オーバーヘッドで保存データを最新の状態に保つ、安全で効率的かつ信頼性の高い方法を提供します。

この作業はSIG API Machineryが主導したKEP #4192の一環として行われました。

変更可能なボリュームアタッチ制限

CSI(Container Storage Interface)ドライバーは、ストレージシステムをコンテナ化されたワークロードに一貫した方法で公開するKubernetesプラグインです。 CSINodeオブジェクトは、ノードにインストールされているすべてのCSIドライバーの詳細を記録します。 しかし、ノードで報告されるアタッチ容量と実際の容量の間に不一致が生じることがあります。 CSIドライバーの起動後にボリュームスロットが消費されると、kube-schedulerは十分な容量がないノードにステートフルなPodを割り当ててしまい、最終的にContainerCreating状態で停止することがあります。

Kubernetes v1.35では、CSINode.spec.drivers[*].allocatable.countが変更可能になり、ノードで利用可能なボリュームアタッチ容量を動的に更新できるようになりました。 また、CSIDriverオブジェクトを介して設定可能な更新間隔を導入することで、CSIドライバーがすべてのノードでallocatable.count値を更新する頻度を制御できるようになりました。 さらに、容量不足によるボリュームアタッチの失敗を検出すると、CSINode.spec.drivers[*].allocatable.countを自動的に更新します。 この機能はv1.34でフィーチャーフラグMutableCSINodeAllocatableCountがデフォルトで無効の状態でベータに昇格しましたが、v1.35でもフィードバックを得る時間を確保するためベータのままです。 ただし、フィーチャーフラグはデフォルトで有効になっています。

この作業はSIG Storageが主導したKEP #4876の一環として行われました。

効率的なバッチスケジューリング

従来、KubernetesスケジューラーはO(Pod数 × Node数)の時間計算量でPodを順次処理していたため、互換性のあるPodに対して冗長な計算が発生することがありました。 このKEPでは、Podスケジューリング署名を使用して互換性のあるPodを識別し、それらをまとめてバッチ処理することでパフォーマンスを向上させる仕組みを導入しています。 これにより、フィルタリングとスコアリングの結果を複数のPod間で共有できます。

Podスケジューリング署名は、同じ署名を持つ2つのPodがスケジューリングの観点から「同一」であることを保証します。 この署名は、PodとNodeの属性だけでなく、システム内の他のPodやPod配置に関するグローバルデータも考慮します。 つまり、同じ署名を持つPodは、任意のNode群に対して同じスコアや実行可能性の結果を得ることになります。

このバッチ処理の仕組みは、必要に応じて呼び出せる2つの操作(createとnominate)で構成されています。 createは、有効な署名を持つPodのスケジューリング結果から新しいバッチ情報のセットを作成します。 nominateは、createで作成されたバッチ情報を使用して、署名が基準となるPodの署名と一致する新しいPodに対して、nominatedノード名を設定します。

この作業はSIG Schedulingが主導したKEP #5598の一環として行われました。

StatefulSetにおけるmaxUnavailable

StatefulSetはPodのグループを実行し、各Podに対して固定のIDを維持します。 これは、安定したネットワーク識別子や永続ストレージを必要とするステートフルなワークロードにとって重要です。 StatefulSetの.spec.updateStrategy.<type>がRollingUpdateに設定されている場合、StatefulSetコントローラーはStatefulSet内の各Podを削除して再作成します。 Pod終了時と同じ順序(最大の序数から最小へ)で進行し、一度に1つずつPodを更新します。

Kubernetes v1.24では、StatefulSetのrollingUpdate設定にmaxUnavailableという新しいアルファフィールドが追加されました。 このフィールドは、クラスター管理者が明示的にオプトインしない限り、Kubernetes APIの一部ではありませんでした。 Kubernetes v1.35では、このフィールドはベータになり、デフォルトで利用可能です。 これを使用して、更新中に利用不可にできるPodの最大数を定義できます。 この設定は、.spec.podManagementPolicyをParallelに設定した場合に最も効果的です。 maxUnavailableは正の数(例: 2)または希望するPod数の割合(例: 10%)として設定できます。 このフィールドが指定されていない場合、デフォルトは1となり、一度に1つのPodのみを更新する従来の動作が維持されます。 この改善により、複数のPodが停止しても許容できるステートフルなアプリケーションは、より高速に更新を完了できます。

この作業はSIG Appsが主導したKEP #961の一環として行われました。

kubercにおける認証情報プラグインポリシーの設定

オプションのkubercファイルは、実行中のCIパイプラインを予期しない出力で中断することなく、サーバー設定とクラスター認証情報をユーザー設定から分離する方法です。

v1.35リリースの一環として、kubercに認証情報プラグインポリシーを設定できる機能が追加されました。 この変更により、すべてのプラグインを許可または拒否するcredentialPluginPolicyフィールドと、credentialPluginAllowlistを使用して許可するプラグインのリストを指定する機能の2つのフィールドが導入されました。

この作業はSIG AuthとSIG CLIの協力によりKEP #3104の一環として行われました。

KYAML

YAMLは人間が読みやすいデータシリアライズ形式です。 Kubernetesでは、YAMLファイルはPod、Service、Deploymentなどのリソースを定義および設定するために使用されます。 しかし、複雑なYAMLは読みにくいという問題があります。 YAMLでは空白が意味を持つため、インデントとネストに注意が必要であり、文字列の引用符がオプションであることから予期しない型変換が発生することがあります(例: The Norway Bug)。 JSONは代替手段ですが、コメントをサポートしておらず、末尾のカンマやキーの引用符に厳格な要件があります。

KYAMLは、Kubernetes向けに特別に設計された、より安全で曖昧さの少ないYAMLのサブセットです。 v1.34でオプトインのアルファ機能として導入されたこの機能は、Kubernetes v1.35でベータに昇格し、デフォルトで有効になりました。 環境変数KUBECTL_KYAML=falseを設定することで無効にできます。

KYAMLはYAMLとJSONの両方が抱える課題に対処しています。 KYAMLファイルはすべて有効なYAMLファイルでもあるため、KYAMLで記述したマニフェストは任意のバージョンのkubectlで使用できます。 一方で、kubectlへの入力は厳密なKYAML形式である必要はなく、従来のYAMLもそのまま解析できます。

この作業はSIG CLIが主導したKEP #5295の一環として行われました。

HorizontalPodAutoscalerの許容値の設定

Horizontal Pod Autoscaler(HPA)は、これまでスケーリングアクションに対して固定のグローバルな10%の許容値に依存していました。 このハードコードされた値の欠点は、5%の負荷増加でスケールする必要があるような高感度を必要とするワークロードがスケーリングをブロックされることが多く、一方で他のワークロードが不必要に振動する可能性があることでした。

Kubernetes v1.35では、許容値を設定できる機能がベータに昇格し、デフォルトで有効になりました。 この機能強化により、HPAのbehaviorフィールド内でリソースごとにカスタムの許容値ウィンドウを定義できます。 特定の許容値を設定することで(例: 5%の場合は0.05に下げる)、オペレーターはオートスケーリングの感度を精密に制御でき、クラスター全体の設定変更を必要とせずに、重要なワークロードがメトリクスの小さな変化に素早く反応するようにできます。

この作業はSIG Autoscalingが主導したKEP #4951の一環として行われました。

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

Kubernetesにユーザー名前空間のサポートが追加され、Podはホストとユーザー/グループIDを共有する代わりに、分離されたIDマッピングで実行できるようになりました。 これにより、コンテナ内部ではrootとして動作しながら、実際にはホスト上の非特権ユーザーにマッピングされるため、侵害が発生した場合の権限昇格リスクが軽減されます。 この機能はPodレベルのセキュリティを向上させ、コンテナ内でrootが必要なワークロードをより安全に実行できるようにします。 時間の経過とともに、id-mapped mountsによりステートレスとステートフルの両方のPodにサポートが拡大されました。

この作業はSIG Nodeが主導したKEP #127の一環として行われました。

VolumeSource: OCIアーティファクトおよびイメージ

Podを作成する際、コンテナにデータ、バイナリ、または設定ファイルを提供する必要があることがよくあります。 従来は、コンテンツをメインのコンテナイメージに含めるか、カスタムのinitコンテナを使用してファイルをダウンロードしemptyDirに展開する必要がありました。 これらのアプローチは現在も有効です。 Kubernetes v1.31ではimageボリュームタイプのサポートが追加され、PodがOCIコンテナイメージのアーティファクトを宣言的にプルしてボリュームに展開できるようになりました。 これにより、設定ファイル、バイナリ、機械学習モデルなどのデータのみのアーティファクトを、標準的なOCIレジストリツールを使用してパッケージ化し配布できます。

この機能により、データをコンテナイメージから完全に分離でき、追加のinitコンテナや起動スクリプトが不要になります。 imageボリュームタイプはv1.33からベータであり、v1.35ではデフォルトで有効になっています。 この機能を使用するには、containerd v2.1以降などの互換性のあるコンテナランタイムが必要です。

この作業はSIG Nodeが主導したKEP #4639の一環として行われました。

キャッシュされたイメージに対するkubeletの認証情報検証の強制

imagePullPolicy: IfNotPresentの設定では、Pod自体がそのイメージをプルするための認証情報を持っていなくても、ノードにすでにキャッシュされているコンテナイメージを使用できます。 この動作の欠点は、マルチテナントクラスターでセキュリティの脆弱性を生むことです。 有効な認証情報を持つPodが機密性の高いプライベートイメージをノードにプルすると、同じノード上の後続の未認可Podがローカルキャッシュに依存するだけでそのイメージにアクセスできてしまいます。

このKEPでは、kubeletがキャッシュされたイメージに対して認証情報の検証を強制する仕組みを導入しています。 ローカルにキャッシュされたイメージをPodが使用することを許可する前に、kubeletはそのPodがイメージをプルするための有効な認証情報を持っているかどうかを確認します。 これにより、イメージがすでにノードに存在するかどうかに関係なく、認可されたワークロードのみがプライベートイメージを使用できるようになり、共有クラスターのセキュリティ体制が大幅に強化されます。

Kubernetes v1.35では、この機能はベータに昇格し、デフォルトで有効になっています。 KubeletEnsureSecretPulledImagesフィーチャーゲートをfalseに設定することで無効にすることもできます。 さらに、imagePullCredentialsVerificationPolicyフラグにより、オペレーターは後方互換性を優先するモードから最大限のセキュリティを提供する厳格な強制モードまで、希望するセキュリティレベルを設定できます。

この作業はSIG Nodeが主導したKEP #2535の一環として行われました。

きめ細かなコンテナ再起動ルール

従来、restartPolicyフィールドはPodレベルでのみ定義されており、Pod内のすべてのコンテナに同じ動作を強制していました。 このグローバル設定の欠点は、AI/MLトレーニングジョブなどの複雑なワークロードに対する粒度の欠如でした。 これらのジョブでは、ジョブの完了を管理するためにPodにrestartPolicy: Neverが必要なことが多いですが、個々のコンテナは特定のリトライ可能なエラー(ネットワークの問題やGPU初期化の失敗など)に対してインプレース再起動の恩恵を受けることができます。

Kubernetes v1.35では、コンテナAPI自体でrestartPolicyとrestartPolicyRulesを有効にすることでこの問題に対処しています。 これにより、Podの全体的なポリシーとは独立して動作する、個々の通常コンテナとinitコンテナの再起動戦略を定義できます。 たとえば、コンテナが特定のエラーコードで終了した場合にのみ自動的に再起動するように設定でき、一時的な障害のためにPod全体を再スケジュールするコストの高いオーバーヘッドを回避できます。

このリリースでは、この機能はベータに昇格し、デフォルトで有効になっています。 ユーザーはコンテナの仕様でrestartPolicyRulesをすぐに活用して、Podの広範なライフサイクルロジックを変更することなく、長時間実行されるワークロードのリカバリ時間とリソース使用率を最適化できます。

この作業はSIG Nodeが主導したKEP #5307の一環として行われました。

CSIドライバーがsecretsフィールドでServiceAccountトークンを受信可能に

Container Storage Interface(CSI)ドライバーにServiceAccountトークンを提供する方法は、従来volume_contextフィールドへの注入に依存していました。 このアプローチは重大なセキュリティリスクをもたらします。 volume_contextは機密性のない設定データを対象としており、ドライバーやデバッグツールによって平文でログに記録されることが多く、認証情報が漏洩する可能性があるためです。

Kubernetes v1.35では、CSIドライバーがNodePublishVolumeリクエストの専用secretsフィールドを介してServiceAccountトークンを受け取るためのオプトイン機構を導入しています。 ドライバーはCSIDriverオブジェクトでserviceAccountTokenInSecretsフィールドをtrueに設定することでこの動作を有効にでき、kubeletにトークンを安全に設定するよう指示します。

主な利点は、ログやエラーメッセージでの認証情報の意図しない露出を防止することです。 この変更により、機密性の高いワークロードIDが適切な安全なチャネルを介して処理されるようになり、既存のドライバーとの後方互換性を維持しながら、シークレット管理のベストプラクティスに沿った対応が可能になります。

この作業はSIG AuthがSIG Storageと協力して主導したKEP #5538の一環として行われました。

Deploymentステータスの追加: 終了中のレプリカ数

従来、Deploymentのステータスは利用可能なレプリカと更新されたレプリカの詳細を提供していましたが、シャットダウン中のPodに対する明示的な可視性がありませんでした。 この欠落の欠点は、ユーザーやコントローラーが安定したDeploymentと、クリーンアップタスクを実行中または長い猶予期間に従っているPodがまだ存在するDeploymentを簡単に区別できないことでした。

Kubernetes v1.35では、Deploymentステータス内のterminatingReplicasフィールドがベータに昇格しました。 このフィールドは、削除タイムスタンプが設定されているがまだシステムから削除されていないPodの数を提供します。 この機能は、DeploymentがPodの置き換えを処理する方法を改善するより大きな取り組みの基礎的なステップであり、ロールアウト中に新しいPodをいつ作成するかに関する将来のポリシーの基盤を築いています。

主な利点は、ライフサイクル管理ツールやオペレーター向けの可観測性の向上です。 終了中のPodの数を公開することで、外部システムは個々のPodリストを手動でクエリしてフィルタリングすることなく、完全なシャットダウンを待ってから後続のタスクに進むなど、より適切な判断を下せるようになります。

この作業はSIG Appsが主導したKEP #3973の一環として行われました。

アルファの新機能

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

KubernetesにおけるGangスケジューリングのサポート

AI/MLトレーニングジョブやHPCシミュレーションなどの相互依存するワークロードのスケジューリングは、デフォルトのKubernetesスケジューラーがPodを個別に配置するため、従来から困難でした。 これにより、一部のPodが開始される一方で他のPodがリソースを無期限に待機する部分的なスケジューリングが発生し、デッドロックやクラスター容量の浪費につながることがよくありました。

Kubernetes v1.35では、新しいWorkload APIとPodGroupコンセプトを介した、いわゆる「Gangスケジューリング」のネイティブサポートを導入しています。 この機能は「オール・オア・ナッシング (全か無か)」のスケジューリング戦略を実装し、定義されたPodのグループは、クラスターがグループ全体を同時に収容するのに十分なリソースを持っている場合にのみスケジュールされることを保証します。

主な利点は、バッチおよび並列ワークロードの信頼性と効率性の向上です。 部分的なデプロイメントを防ぐことで、リソースのデッドロックを排除し、完全なジョブが実行できる場合にのみ高価なクラスター容量が使用されるようになり、大規模なデータ処理タスクのオーケストレーションが大幅に最適化されます。

この作業はSIG Schedulingが主導したKEP #4671の一環として行われました。

制約付きなりすまし

従来、Kubernetes RBACのimpersonate動詞はオール・オア・ナッシングの方式で機能していました。 ユーザーがターゲットIDになりすますことを認可されると、関連するすべての権限を取得していました。 この広範な認可の欠点は、最小権限の原則に違反し、管理者がなりすましを行うユーザーを特定のアクションやリソースに制限できないことでした。

Kubernetes v1.35では、なりすましフローに二次的な認可チェックを追加する新しいアルファ機能、制約付きなりすましを導入しています。 ConstrainedImpersonationフィーチャーゲートを介して有効にすると、APIサーバーは基本的なimpersonate権限だけでなく、新しい動詞プレフィックス(例: impersonate-on:<mode>:<verb>)を使用して、なりすましを行うユーザーが特定のアクションに対して認可されているかどうかも確認します。 これにより、管理者はきめ細かなポリシーを定義できます。 たとえば、サポートエンジニアがログを表示するためだけにクラスター管理者になりすますことを許可し、完全な管理アクセス権を付与しないようにできます。

この作業はSIG Authが主導したKEP #5284の一環として行われました。

KubernetesコンポーネントのFlagz

APIサーバーやkubeletなどのKubernetesコンポーネントのランタイム設定を検証するには、従来ホストノードへの特権アクセスやプロセス引数へのアクセスが必要でした。 これに対処するため、コマンドラインオプションをHTTP経由で公開する/flagzエンドポイントが導入されました。 しかし、その出力は当初プレーンテキストに限定されており、自動化ツールが設定を確実に解析して検証することが困難でした。

Kubernetes v1.35では、/flagzエンドポイントが機械可読な構造化JSON出力をサポートするように強化されました。 認可されたユーザーは、標準的なHTTPコンテンツネゴシエーションを使用してバージョン管理されたJSONレスポンスをリクエストできるようになり、元のプレーンテキスト形式も人間による検査用に引き続き利用可能です。 このアップデートにより、可観測性とコンプライアンスのワークフローが大幅に改善され、外部システムが脆弱なテキスト解析や直接的なインフラストラクチャアクセスなしに、コンポーネント設定をプログラムで監査できるようになります。

この作業はSIG Instrumentationが主導したKEP #4828の一環として行われました。

KubernetesコンポーネントのStatusz

kube-apiserverやkubeletなどのKubernetesコンポーネントのトラブルシューティングには、従来、構造化されていないログやテキスト出力の解析が必要であり、これは脆弱で自動化が困難でした。 以前から基本的な/statuszエンドポイントは存在していましたが、標準化された機械可読形式がなく、外部監視システムでの有用性が制限されていました。

Kubernetes v1.35では、/statuszエンドポイントが機械可読な構造化JSON出力をサポートするように強化されました。 認可されたユーザーは、標準的なHTTPコンテンツネゴシエーションを使用してこの形式をリクエストし、バージョン情報やヘルスインジケーターなどの正確なステータスデータを、脆弱なテキスト解析に頼ることなく取得できます。 この改善により、すべてのコアコンポーネントにわたって、自動デバッグおよび可観測性ツールのための信頼性が高く一貫したインターフェースが提供されます。

この作業はSIG Instrumentationが主導したKEP #4827の一環として行われました。

CCM: informerを使用したwatch-basedルートコントローラーの調整

クラウド環境内でのネットワークルートの管理は、従来Cloud Controller Manager(CCM)がクラウドプロバイダーのAPIを定期的にポーリングしてルートテーブルを検証および更新することに依存していました。 この固定間隔での調整アプローチは非効率になりがちで、大量の不要なAPI呼び出しを生成し、ノードの状態変化と対応するルート更新の間に遅延が生じることがよくありました。

Kubernetes v1.35リリースでは、cloud-controller-managerライブラリがルートコントローラー用のwatch-based調整戦略を導入しています。 タイマーに依存する代わりに、コントローラーはinformerを利用して、追加、削除、関連フィールドの更新などの特定のNodeイベントを監視し、実際に変更が発生した場合にのみルート同期をトリガーします。

主な利点は、クラウドプロバイダーAPIの使用量が大幅に削減されることで、レート制限に達するリスクが低下し、運用オーバーヘッドが軽減されます。 さらに、このイベント駆動モデルは、クラスタートポロジーの変更後すぐにルートテーブルが更新されることを保証し、クラスターのネットワーク層の応答性を向上させます。

この作業はSIG Cloud Providerが主導したKEP #5237の一環として行われました。

しきい値ベースの配置のための拡張toleration演算子

Kubernetes v1.35では、ワークロードが信頼性要件を表現できるようにすることで、SLA対応のスケジューリングを導入しています。 この機能はtolerationに数値比較演算子を追加し、サービス保証や障害ドメインの品質などのSLA指向のtaintに基づいて、Podがノードにマッチするか回避するかを制御できるようにします。

主な利点は、より正確な配置によるスケジューラーの強化です。 重要なワークロードは高SLAノードを要求でき、優先度の低いワークロードは低SLAノードを選択できます。 これにより、信頼性を損なうことなく使用率が向上し、コストが削減されます。

この作業はSIG Schedulingが主導したKEP #5471の一環として行われました。

Jobが一時停止時のコンテナリソースの変更

バッチワークロードの実行には、リソース制限の試行錯誤が伴うことがよくあります。 現在、Jobの仕様は不変であり、Jobがメモリ不足(OOM)エラーやCPU不足で失敗した場合、ユーザーは単にリソースを調整することができません。 Jobを削除して新しいJobを作成する必要があり、実行履歴とステータスが失われます。

Kubernetes v1.35では、一時停止状態のJobに対してリソースリクエストと制限を更新する機能を導入しています。 MutableJobPodResourcesForSuspendedJobsフィーチャーゲートを介して有効にすると、この機能強化により、ユーザーは失敗しているJobを一時停止し、適切なリソース値でPodテンプレートを変更してから、修正された設定で実行を再開できます。

主な利点は、設定ミスのあるJobに対するよりスムーズなリカバリワークフローです。 一時停止中にインプレースで修正できるようにすることで、ユーザーはJobのライフサイクルIDを中断したり完了ステータスを見失ったりすることなくリソースのボトルネックを解決でき、バッチ処理の開発者体験が大幅に向上します。

この作業はSIG Appsが主導したKEP #5440の一環として行われました。

その他の注目すべき変更

Dynamic Resource Allocation(DRA)の継続的な革新

コア機能はv1.34でGAに昇格し、無効にする機能が提供されていました。 v1.35では常に有効になっています。 いくつかのアルファ機能も大幅に改善され、テストの準備が整っています。 今後のリリースでベータへの昇格を目指すこれらの機能について、フィードバックをお寄せいただくことをお勧めします。

DRAを介した拡張リソースリクエスト

Device Pluginを介した拡張リソースリクエストと比較していくつかの機能的な差分が対処されました。 たとえば、initコンテナでのデバイスのスコアリングと再利用などです。

デバイスのTaintとToleration

新しい「None」エフェクトを使用すると、スケジューリングや実行中のPodに直ちに影響を与えることなく問題を報告できます。 DeviceTaintRuleは、進行中の退避に関するステータス情報を提供するようになりました。 「None」エフェクトは、実際にPodを退避する前の「ドライラン」として使用できます:

  • 「effect: None」でDeviceTaintRuleを作成する
  • ステータスを確認して、退避されるPodの数を確認する
  • 「effect: None」を「effect: NoExecute」に置き換える

パーティション可能なデバイス

同じパーティション可能なデバイスに属するデバイスを、異なるResourceSliceで定義できるようになりました。 詳細については公式ドキュメントをご覧ください。

消費可能な容量とデバイスバインディング条件

いくつかのバグが修正され、テストが追加されました。 消費可能な容量とバインディング条件の詳細については、公式ドキュメントをご覧ください。

比較可能なリソースバージョンのセマンティクス

Kubernetes v1.35では、クライアントがリソースバージョンを解釈する方法が変更されました。

v1.35より前は、クライアントがサポートできる唯一の比較は文字列の等価性チェックでした。 2つのリソースバージョンが等しければ、それらは同じでした。 クライアントはAPIサーバーにリソースバージョンを提供し、特定のリソースバージョン以降のすべてのイベントをストリーミングするなど、コントロールプレーンに内部比較を依頼することもできました。

v1.35では、すべてのin-treeリソースバージョンがより厳格な新しい定義を満たしています。 値は特殊な形式の10進数です。 そして、比較可能であるため、クライアントは2つの異なるリソースバージョンを比較する独自の操作を実行できます。 たとえば、クラッシュ後に再接続するクライアントは、更新があったが変更が失われていない場合と区別して、更新を失ったことを検出できます。

このセマンティクスの変更により、Storage Version Migration、 informer (クライアントヘルパーの概念)のパフォーマンス改善、コントローラーの信頼性など、他の重要なユースケースが可能になります。 これらのケースはすべて、あるリソースバージョンが別のリソースバージョンより新しいかどうかを知る必要があります。

この作業はSIG API Machineryが主導したKEP #5504の一環として行われました。

v1.35での昇格、非推奨、削除

GAへの昇格

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

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

非推奨、削除、コミュニティの更新

Kubernetesの開発と成熟に伴い、プロジェクト全体の健全性を向上させるために、機能が非推奨になったり、削除されたり、より良いものに置き換えられたりすることがあります。 このプロセスの詳細については、Kubernetesの非推奨と削除のポリシーをご覧ください。 Kubernetes v1.35にはいくつかの非推奨が含まれています。

Ingress NGINXの引退

長年にわたり、Ingress NGINXコントローラーはKubernetesクラスターへのトラフィックルーティングにおいて人気のある選択肢でした。 柔軟性があり、広く採用され、数え切れないほどのアプリケーションの標準的なエントリーポイントとして機能してきました。

しかし、プロジェクトの維持が持続不可能になりました。 メンテナーの深刻な不足と増大する技術的負債により、コミュニティは最近、引退させるという難しい決断を下しました。 これは厳密にはv1.35リリースの一部ではありませんが、非常に重要な変更であるため、ここで強調したいと思います。

その結果、Kubernetesプロジェクトは、Ingress NGINXが2026年3月までベストエフォートのメンテナンスのみを受けることを発表しました。 この日以降、アーカイブされ、今後の更新は行われません。 推奨される移行先はGateway APIであり、トラフィック管理のためのより現代的で安全かつ拡張可能な標準を提供します。

詳細については公式ブログ記事をご覧ください。

cgroup v1サポートの削除

Linuxノードでのリソース管理において、Kubernetesは従来cgroups(コントロールグループ)に依存してきました。 オリジナルのcgroup v1は機能していましたが、一貫性がなく制限があることが多くありました。 そのため、Kubernetesはv1.25でcgroup v2のサポートを導入し、よりクリーンで統一された階層構造と優れたリソース分離を提供しました。

cgroup v2が現代の標準となったため、Kubernetesはv1.35でレガシーなcgroup v1サポートを廃止する準備が整いました。 これはクラスター管理者にとって重要なお知らせです。cgroup v2をサポートしていない古いLinuxディストリビューションでノードを実行している場合、kubeletは起動に失敗します。 ダウンタイムを回避するには、それらのノードをcgroup v2が有効になっているシステムに移行する必要があります。

詳細についてはcgroup v2についてをお読みください。
また、KEP-5573: Remove cgroup v1 supportで移行作業を追跡できます。

kube-proxyのipvsモードの非推奨化

数年前、Kubernetesは標準のiptablesよりも高速なロードバランシングを提供するために、kube-proxyにipvsモードを採用しました。 パフォーマンスの向上をもたらしましたが、進化するネットワーキング要件との同期を維持することで、過度の技術的負債と複雑さが生じました。

このメンテナンス負担のため、Kubernetes v1.35ではipvsモードが非推奨になりました。 このリリースではモードは引き続き利用可能ですが、kube-proxyはipvsを使用するよう設定されている場合、起動時に警告を出力するようになります。 目標はコードベースを合理化し、現代の標準に焦点を当てることです。 Linuxノードでは、現在推奨される代替手段であるnftablesへの移行を開始する必要があります。

詳細についてはKEP-5495: Deprecate ipvs mode in kube-proxyをご覧ください。

containerd v1.Xの最終サポート

Kubernetes v1.35は引き続きcontainerd 1.7およびその他のLTSリリースをサポートしていますが、これがそのようなサポートを提供する最後のバージョンです。 SIG Nodeコミュニティは、v1.35をcontainerd v1.Xシリーズをサポートする最後のリリースに指定しました。

これは重要なリマインダーです。次のKubernetesバージョンにアップグレードする前に、containerd 2.0以降に切り替える必要があります。 どのノードに対応が必要かを特定するために、クラスター内のkubelet_cri_losing_supportメトリクスを監視できます。

詳細については公式ブログ記事またはKEP-4033: Discover cgroup driver from CRIをご覧ください。

kubelet再起動時のPod安定性の向上

以前は、kubeletサービスの再起動により、Podステータスに一時的な中断が発生することがよくありました。 再起動中、kubeletはコンテナの状態をリセットし、アプリケーション自体が正常に実行されていても、正常なPodがNotReadyとしてマークされ、ロードバランサーから削除されていました。

この信頼性の問題に対処するため、シームレスなノードメンテナンスを確保するようにこの動作が修正されました。 kubeletは起動時にランタイムから既存のコンテナの状態を適切に復元するようになりました。 これにより、kubeletの再起動やアップグレード中もワークロードはReady状態を維持し、トラフィックは中断されることなく流れ続けます。

詳細についてはKEP-4781: Fix inconsistent container ready state after kubelet restartをご覧ください。

リリースノート

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

入手方法

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

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

リリースチーム

Kubernetesは、コミュニティの支援と献身的な努力によって成り立っています。 各リリースチームは、皆さんが利用するKubernetesリリースを構成する様々な要素を協力して構築する、献身的なコミュニティボランティアで構成されています。 これを実現するには、コードそのものからドキュメント作成、プロジェクト管理に至るまで、コミュニティのあらゆる分野の専門スキルが必要です。

私たちは、技術的な卓越性と周囲を巻き込む情熱でKubernetesコミュニティに永続的な影響を残した、長年にわたるコントリビューターであり尊敬されるエンジニアであるHan Kangを追悼します。 HanはSIG InstrumentationとSIG API Machineryにおいて重要な存在であり、プロジェクトのコアの安定性に対する重要な貢献と持続的なコミットメントにより、2021 Kubernetes Contributor Awardを受賞しました。 技術的な貢献に加えて、Hanはメンターとしての寛大さと人々のつながりを築くことへの情熱で深く称賛されていました。 彼は、新しいコントリビューターの最初のPull Requestを導いたり、忍耐と優しさで同僚をサポートしたりと、他者のために「扉を開く」ことで知られていました。 Hanの遺志は、彼がインスパイアしたエンジニアたち、彼が構築を手助けした堅牢なシステム、そして彼がクラウドネイティブのエコシステム内で育んだ温かく協力的な精神を通じて生き続けています。

Kubernetes v1.35リリースをコミュニティに届けるために多くの時間を費やして取り組んでくれたリリースチーム全体に感謝します。 リリースチームには、初参加のShadow(見習い)から、複数のリリースサイクルで経験を積んだベテランのチームリードまで、様々なメンバーが参加しています。 リリースリードのDrew Hagenに心より感謝します。 彼の実践的な指導と活力あふれるエネルギーは、複雑な課題を乗り越える力となっただけでなく、この成功したリリースの背後にあるコミュニティ精神を燃え立たせました。

プロジェクトの活動状況

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

v1.35リリースサイクル(2025年9月15日から2025年12月17日までの14週間)において、Kubernetesには最大85の異なる企業と419人の個人から貢献がありました。 より広範なクラウドネイティブエコシステムでは、この数字は281社、合計1769人のコントリビューターに達しています。

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

データソース:

イベント情報

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

2026年2月

2026年3月

2026年5月

2026年6月

2026年7月

最新のイベント情報はこちらでご確認いただけます。 ​

ウェビナーのご案内

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

参加方法

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

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