Kubernetes 1.35主要新機能と変更点を徹底解説: アップグレード前に知っておくべき重要なポイント

Kubernetes 1.35主要新機能と変更点を徹底解説: アップグレード前に知っておくべき重要なポイント

Kubernetes 1.35（コードネーム「Timbernetes」）は、効率性とAI/MLワークロード向けの最適化をテーマにしたメジャーリリースです。注目すべき新機能としては、稼働中のPodに対してリソース（CPU/メモリ）割り当てをコンテナを再起動せずに調整できるIn-Place Pod再起動機能のGA化があります。また、高度なデバッグ・可観測性を実現するバージョン管理されたz-pages APIの導入や、大規模ワークロードの信頼性を高めるWorkload Aware Scheduling（ワークロード認識型スケジューリング）のアルファ機能追加、分散リソースアカウンティング（DRA）の拡張によるGPU/AIハードウェア対応の強化なども含まれています。さらに、既存機能のアップグレードとして、Job Managed ByやPod証明書（PodCertificates）機能のGA化、Kubelet構成のドロップインディレクトリ機能のGA化などが行われました。一方で、従来のIPVSモードやcgroups v1サポートなど、古い機能の非推奨・削除も予定されており、アップグレード前の確認が重要です。この記事ではKubernetes 1.35の主要機能と変更点を整理し、アップグレード前に押さえておくべき重要ポイントを詳しく解説します。

Kubernetes 1.35のリリース情報とコードネーム『Timbernetes』の背景徹底解説ガイド

Kubernetes 1.35は2025年12月にリリース予定のバージョンで、コミュニティではコードネーム「Timbernetes（世界樹）Release」と呼ばれています。この名称は持続的な成長と生命力を象徴し、Kubernetesが大規模システムにおいて常に発展し続ける意志を表しています。リリースの特徴は、AI/MLワークロード向けの機能強化と運用効率の向上にフォーカスしている点で、これまでのリリースノートでもその方針が強調されています。また、リリース直前には公式ブログやコミュニティのSneak Peek投稿で主要機能が紹介され、ユーザーに事前周知されました。新バージョンに含まれる新機能や変更点は開発者ブログやGitHubのリリースノートでも詳細に説明されていますので、実際にアップグレードを行う前にしっかり目を通すことが推奨されます。「Timbernetes（世界樹）」というコードネームは、多くの機能が枝葉のように拡張されていくイメージから名付けられました。また2025年の最後を飾るリリースでもあり、Kubernetesコミュニティでは発表への注目度も非常に高まっています。リリースに関する詳細な情報は公式ブログやSIGリリースノートで公開されていますので、アップグレード前に必ず目を通しておきましょう。

Kubernetes 1.35で導入されたIn-Place Pod再起動機能の概要と期待効果徹底解説ポイント

In-Place Pod再起動機能（正式名称: In-Place Pod Resize）は、Kubernetes 1.35で正式にGA（一般利用可能）となった新機能です。この機能を利用すると、稼働中のPodに対してリソース（CPU/メモリ）割り当てを動的に調整でき、変更時にコンテナを再起動する必要がなくなります。例えば、メモリ需要が高い処理開始時に一時的にCPUやメモリを増やし、処理が終わったら元に戻すといったシナリオで有効です。特にJavaアプリケーションのように起動直後に多めのリソースを必要とするワークロードで効果を発揮し、全体のリソース利用効率を向上させることが期待されています。実際にこの機能を使用するにはPodのresources.requests/limitsフィールドを更新し、1.35以降のKubeletが対応している必要があります。無停止でのリソース変更という点が大きなメリットであり、Podの安定稼働やクラスターの効率化につながるでしょう。

Kubernetes 1.35における分散リソースアカウンティング(DRA)機能強化とAIハードウェア対応解説

DRA（Device Resource Accounting）機能は、GPUやAIアクセラレータのリソース使用量を細かく管理するための仕組みです。Kubernetes 1.35では、マルチインスタンスGPU（NVIDIA MIG）などのハードウェアをより高精度にスケジューリングできるよう、DRA機能がさらに強化されています。具体的には、ハードウェアレベルでのリソース分割を認識して割り当てることで、複数ワークロード間でのGPU利用を効率化し、AI/MLトレーニングジョブのパフォーマンスを最適化します。また、これまでのPodレベルリソース報告機能に加え、より詳細な使用状況のトラッキングが可能になるため、管理者はクラスター全体のリソース使用状況を正確に把握できます。AIネイティブワークロードにおいては、これらの強化によりハードウェアリソースの無駄を削減しつつ高パフォーマンスを維持できる点が大きなメリットです。

Kubernetes 1.35で導入されたWorkload Aware Scheduling（WAS）機能の概要と活用例徹底解説

Workload Aware Scheduling（WAS）は、Kubernetes 1.35で追加予定の新しいスケジューリングアプローチです。WASを利用すると、複数のPodで構成されるワークロードに対して、信頼性要件を直接定義し、その要件に応じたスケジューリング制御が可能になります。具体的には、Podに新しいスケジューリング要件を記述し、例えば同じワークロードの複数Podを同じクラスター内で連携して配備する（Gang Scheduling）ことがサポートされる予定です。これにより、AI/MLトレーニングのような並列処理が求められるジョブでは、全てのPodが同時に実行されるようにスケジューラーが調整を行い、途中で一部だけ実行されてしまうリスクを減らせます。現在はアルファ段階の機能ですが、将来的にはワークロード認識型スケジューリングが安定動作することで、分散処理の効率やアプリケーションの信頼性が向上すると期待されています。

Kubernetes 1.35におけるCloud Controller ManagerのWatch Based Route Reconciliation機能概要

Cloud Controller Manager（CCM）の新機能「Watch Based Route Reconciliation」は、クラウド環境におけるルーティング設定の同期方式を改善する機能です。従来、CCMはクラウドプロバイダーのルーティング情報を定期的にポーリングしていましたが、1.35ではKubernetesのWatchメカニズムを活用してルート情報の変更をリアルタイムで検知・同期できるようになります。これにより、クラウドプロバイダー側でのルート変更やネットワーク構成の更新に対して迅速に対応でき、ネットワーク遅延や不整合を低減します。ユーザーは特別な設定を行うことなく、自動的に新しい方式の恩恵を受けられる予定です。

Kubernetes 1.35への安全なアップグレード手順ガイド（ステップバイステップ）と移行前に必要なチェックリスト

Kubernetesクラスタを1.35へアップグレードする際は、事前準備と段階的な手順が重要です。まずアップグレード前のチェックリストを確認し、必要な対応を済ませておきましょう。例えば、ノードOSがcgroup v2に対応しているか、現在のetcdバージョンがアップグレード要件を満たしているか、使用しているCSIドライバやネットワークプラグインが1.35でサポートされるかなどです。また、アップグレード作業ではデータバックアップを確実に取得することや、クラスタの負荷を考慮して段階的に制御プレーンとワーカーノードを更新することが推奨されます。以下では、アップグレード前後の各ステップで注意すべきポイントを詳しく解説します。

アップグレード前の事前チェック: cgroups v2対応、ノード要件、リソース状況完全ガイド

アップグレードを開始する前に、まずクラスタ環境がKubernetes 1.35の要件を満たしているか確認しましょう。特に重要なのはcgroups v2対応の確認です。Kubernetes 1.35ではcgroup v1サポートが無効化されるため、各ノードのOSがcgroup v2を使用するよう設定されているか必ずチェックしてください。また、Kubernetesの最小サポートバージョンや使用しているコンテナランタイム（containerdやCRI-O）も最新のLTSバージョンであることを確認しましょう。さらに、CPUやメモリの使用状況、ディスク容量、ネットワーク帯域などクラスタリソースに余裕があるかも事前に確認し、余裕を持った計画的なアップグレードに備えます。このようなガイドに従い、事前チェックを徹底することでアップグレード時の障害リスクを低減できます。

etcd 3.6への安全なアップグレード手順と移行時の注意点解説

Kubernetesのアップグレードを行う際、データストアであるetcdのバージョン要件に注意が必要です。1.35以降ではetcd 3.6以上が推奨されるため、etcdの安全なアップグレード手順を事前に確認しておきましょう。まず、現在稼働中のetcdクラスタのバックアップを取得し、最新版3.6への互換性を確認します。etcdクラスタの一部ノードをローリング再起動して段階的に3.6へ更新する方法や、バックアップしたデータを新規etcdクラスタにリストアする方法などがあります。移行時にはデータ同期の完了を確認し、不整合が起きていないかログを確認することも重要です。このようにetcdを適切にアップグレードすることで、後続のKubernetesアップグレード作業もスムーズに進められるようになります。

ステップバイステップで解説: kubeadmによる Kubernetes 1.35 クラスタアップグレード手順

kubeadmを利用したアップグレードは公式ドキュメントで詳細にガイドされています。まずステップバイステップで行うためには、コントロールプレーンノードから作業を始めます。kubectl upgrade plan コマンドでアップグレード可能なバージョンを確認し、kubeadm upgrade apply v1.35.0 を実行するとコントロールプレーンコンポーネント（APIサーバー、コントローラマネージャ、スケジューラ）が順次更新されます。その後、各ワーカーノードを対象に kubectl drain, kubeadm upgrade node, kubectl uncordon の順でノードを更新します。このとき、kubelet や kubectl バイナリも1.35対応版にアップデートしておくことを忘れないでください。これらを順序立てて実行することで、クラスタ全体を安全にアップグレードできます。

ダウンタイムを最小限にするアップグレード戦略とローリングアップデート実践ガイド

大規模クラスタや本番環境では、アップグレード中のダウンタイムを最小限に抑えることが重要です。そのために、ノードアップグレード時にはkubectl drainコマンドで対象ノード上のPodを安全に他のノードに退避させ、kubectl uncordonでノードを再び利用可能にするローリング方式を採用します。また、Deploymentの設定ではmaxSurgeやmaxUnavailableを調整し、アプリケーションの可用性を確保しながら新旧Podの置き換えを行うことが推奨されます。さらに、アプリケーション側でもReadiness Probeを適切に設定し、アップグレードや再起動時にトラフィック停止が発生しないようにすることが重要です。このような実践ガイドに従うことで、アップグレード時のサービス停止を避け、スムーズな移行が可能になります。

アップグレード後のクラスタ検証と必要なロールバック戦略徹底解説

アップグレードが完了したら、クラスタ全体の機能確認を行います。まず kubectl get nodes や kubectl get pods –all-namespaces で各リソースのステータスを確認し、異常がないか確認します。また、主要サービスに対してエンドツーエンドの動作テストを実施し、性能やログにエラーがないかをチェックします。もし重大な問題が発生した場合には、事前に取得しておいたetcdのバックアップから復旧するなどロールバック戦略を用意しておくと安心です。なお、アップグレード前に自動化されたテスト環境やステージングで十分に検証を済ませていれば、本番クラスタでの想定外のトラブルを減らせます。これらの検証手順とロールバック体制を明確にすることで、安心してKubernetes 1.35への移行を完了できます。

Kubernetes 1.35で追加・強化されたセキュリティ機能と新たな安全対策の実装ポイント徹底解説

Kubernetes 1.35では、セキュリティ関連の大規模な機能強化とデフォルト設定の変更が行われています。特に、従来の脆弱性につながる要素の廃止・非推奨化と、認証・認可の強化が進められました。たとえば、Podの操作に利用されるSPDY通信からより安全なWebSocket通信への切り替えや、kubectlプラグインの実行を制限するcredentialPluginPolicyの導入、コンテナイメージの取得時にさらなる検証を行う仕組みなどが追加されています。ここでは、Kubernetes 1.35で注目される新たなセキュリティ機能のポイントを整理し、それぞれの機能がクラスタに与える影響や設定方法について詳しく解説します。

Kubernetes 1.35でcgroups v1サポートが無効化される: アップグレード前に確認すべきポイント

Kubernetes 1.35からcgroups v1のサポートがデフォルトで無効化されます。これは従来のcgroups機能の完全削除に向けた準備ステップであり、クラスターの運用方式に大きな影響を及ぼします。具体的には、各ノードのOSがcgroup v2対応になっていない場合、kubeletが起動に失敗しPodのスケジューリングが行えなくなります。アップグレード前には必ず、すべてのノードでcgroup v2が有効になっているかを確認し、必要に応じてLinuxのバージョンアップや設定変更を行いましょう。また、テスト環境で事前検証をしておくと、意図せぬダウンタイムを防ぐことができます。

Kubernetes 1.35から導入: credentialPluginPolicyによるkubectl認証プラグイン制御

kubectlクライアントで使用される認証プラグインを制限するcredentialPluginPolicyフィールドがKubernetes 1.35から利用可能になりました。このフィールドを利用すると、kubeconfigファイル内のexecプラグインが実行可能な範囲をクラスタ管理者が制御できるようになります。例えば、「どのプラグインコマンドを許可するか」をポリシーで指定することで、不正なプラグインが実行されるリスクを低減できます。運用面では、信頼されたプラグインのみをリスト化し、他は拒否するポリシーを設定するのが一般的です。これにより、外部ツールによる認証操作の安全性を高め、クラスタのセキュリティを向上させることが期待されます。

Kubernetes 1.35に追加: AuthorizePodWebsocketUpgradeCreatePermission機能ゲート概要

Kubernetes 1.35では、Pod exec/attachやport-forwardなどの操作で使用されるWebSocket接続の生成に新たな機能ゲートが導入されます。具体的には「AuthorizePodWebsocketUpgradeCreatePermission」機能ゲートにより、PodへのWebSocketアップグレード操作はデフォルトで無効化され、明示的に有効化された場合のみ使用が可能になります。管理者はRBACポリシーで特定のユーザーに create 権限を付与してこの操作を許可する必要があります。この強化により、Pod内でのコマンド実行やログ取得といった操作に対するアクセスコントロールが一層厳格化され、安全性が向上します。

Kubernetes 1.35におけるコンテナイメージ認証の強化と安全な取得方法

Kubernetes 1.35では、コンテナイメージの取得時における認証プロセスも強化されています。例えば、ServiceAccountTokenを用いた安全な画像プルがデフォルトで推奨されるようになり、イメージレジストリへの認証情報取り扱いがより安全なものになりました。また、Secretが設定されていない場合はPullImageを許可しない「EnsurePullImageSecret」機能なども検討されています。これらの対策により、悪意あるレジストリからの不正なイメージ取得を防止し、信頼できるソースからのみコンテナを起動する設定が行いやすくなります。運用者は、必ず正式なレジストリからPullImage機能を使うようにポリシーを設計し、1.35で導入された新機能を活用することで、クラスターのセキュリティレベルを向上させられます。

Kubernetes 1.35で広がるユーザーネームスペース対応とセキュリティへの影響

Kubernetes 1.35では、ユーザーネームスペース（User Namespaces）の対応範囲がさらに拡大されます。これまで限定的だったユーザーネームスペースのサポートがデフォルトで有効化され、標準的なPodやHostNetwork Podでもユーザーネームスペースを利用できるようになります。ユーザーネームスペースを有効にすると、Pod内のroot権限の扱いがホストから隔離されるため、コンテナ内でのセキュリティ境界が強化されます。運用者はkubeletの設定でユーザーネームスペースを有効化し、既存ワークロードがこれに対応しているか事前に確認することが重要です。これにより、システム全体の攻撃面を減らし、コンテナの安全性を高める効果が得られます。

Kubernetes 1.35で非推奨・削除された機能の概要と完全移行に向けた考慮点徹底解説

Kubernetes 1.35では、古くなった機能や設計上の負債を軽減するため、いくつかの既存機能が非推奨化または削除対象となります。特に重要な変更として、kube-proxyのIPVSモード非推奨化や、Containerd v1.xシリーズの最終サポートとなる点が挙げられます。また、Ingressコントローラで広く使われてきた「Ingress NGINX」の運用サポートが2026年3月までのベストエフォート提供となり、事実上の退役が予定されています。これらの非推奨機能を使用している環境では、nftablesへの移行やGateway APIの採用、ランタイムのアップグレードなどが必要になります。本セクションでは、Kubernetes 1.35で廃止・非推奨となる主な機能と、それぞれの代替手段・移行戦略について詳しく解説します。

cgroups v1サポートの完全削除: 古いLinuxノードの移行対策

先述の通り、Kubernetes 1.35ではcgroups v1のサポートが削除されます。すでに非推奨化の段階にあったcgroup v1は、このリリースで完全に無効化されます。これにより、古いLinuxディストリビューションを使い続けているノードでは、アップグレード後にkubeletが起動できなくなります。クラスタ管理者はアップグレード前に、すべてのノードがcgroup v2に対応しているかを徹底的に確認し、必要に応じてOSやカーネルのアップデートを行う必要があります。特にオンプレミス環境では、ホストOSがcgroup v2をデフォルトで有効化していないケースが多いため、手順を先に検証しておくことが重要です。

kube-proxy IPVSモードの非推奨化とnftablesへの移行ガイド

Kubernetes 1.35では、kube-proxyのIPVSモードが非推奨になります。IPVSモードは従来、iptablesより高速なロードバランシングを提供していましたが、コードベースの複雑化により保守コストが増大していました。そのためこのリリースからIPVSモードは警告付きで非推奨となり、将来的な削除に向けた措置が開始されています。クラスタ設定で現在IPVSを使用している場合、今後はnftablesベースのモード（iptables-ng/ベータ）への移行が推奨されます。移行手順としては、kube-proxyの設定で –proxy-mode=iptables（最新環境ではnftablesに対応）に変更し、正常にPod間通信が維持されるか確認します。移行の過程ではロードバランシングの挙動検証や障害テストを入念に行いましょう。

Kubernetes 1.35: Containerd v1.x最終サポートとDockershim廃止ガイド

Kubernetes 1.35は、containerd v1.xシリーズのサポート最終版と位置付けられています。つまり、このリリースを最後にcontainerd 1.7.xなど旧バージョンのコンテナランタイムはサポートされなくなります。また、Dockerのコンテナランタイム統合（いわゆる「dockershim」）はすでに以前のバージョンで削除されていましたが、containerd 2.0への移行が必須となります。クラスタ管理者は、アップグレード前に各ノードで使用しているCRIランタイムを確認し、必要であればcontainerd 2.0以上やCRI-Oなどの最新ランタイムに移行しておく必要があります。ランタイム切り替え後は、各ノードで kubelet の起動オプション（–container-runtime-endpoint）が正しく設定されていることも併せて確認しましょう。

Ingress NGINXコントローラ退役の概要とGateway APIへの移行ガイド

Ingressコントローラとして長年利用されてきた「Ingress NGINX」は、Kubernetes 1.35の正式リリースには直接含まれませんが、重要なコミュニティ発表として退役計画が示されています。既存のIngress NGINXプロジェクトは2026年3月までベストエフォートでのメンテナンス提供となり、それ以降はアーカイブされる予定です。代替策としてKubernetes公式ではGateway APIの利用が推奨されており、よりセキュアで拡張性の高いロードバランシング管理が可能です。もしIngress NGINXを利用しているサービスがある場合は、アップグレード作業の際にGateway APIへ移行する計画を立て、Manifestの書き換えやテストを実施しておきましょう。

Kubernetes 1.35で削除または非推奨化された古い機能の概要と対策

Kubernetes 1.35では他にも、時代遅れになった機能の見直しが行われています。これには旧来のAPIバージョンやベータ段階のオプションが含まれますが、運用上特に影響が大きいものとしては先述のcgroups v1やIPVS以外には、古い暗号化方式やプラグインの利用などがあります。ユーザーはクラスタに対して kubectl get apiservices や kubectl api-resources –api-group を使って現在使用しているAPIのバージョンを把握し、可能な限り最新の安定版APIに移行してください。また、Kubernetes公式のリリースノートには「非推奨（Deprecation）」セクションが掲載されており、そちらも参照して必要なコードやマニフェストの修正を行うことが推奨されます。

Kubernetes 1.35におけるAIネイティブワークロード向けの強化ポイントと最適化施策徹底解説

Kubernetes 1.35は「Timbernetes」という名の通り、AI/MLワークロードに力を入れた機能拡張が特徴です。特に、GPU/AI向けのスケジューリング機能強化や、ディープラーニングなどのトレーニングジョブで求められる大規模並列処理をサポートする機能が追加されています。これまで紹介したIn-Place Pod再起動に加え、複数Podを束ねて扱うPodGroup APIや、同時配置を保証するGang Scheduling機能が予定されています。また、水平Podオートスケーリング（HPA）の挙動も改善され、分散トレーニングのように急激なリソース需要変動にも柔軟に対応できるようになりました。以下では、AIネイティブワークロードを想定したKubernetes 1.35の代表的な強化ポイントと、そのメリットを解説します。

In-Place Pod Resize機能の概要と実行中Podのリソース調整方法徹底解説

先に述べたIn-Place Pod再起動機能は、AIワークロードでも非常に有用です。特に、ディープラーニングのトレーニング時には、モデルのイニシャライズやデータロードの間だけ追加のCPUやメモリを割り当て、その後リソースを戻す運用が可能になります。この機能を利用するには、PodSpecのresources.requestsやresources.limitsを更新し、Podを再スケジュールする必要はありません。1.35以降ではkubectl patchコマンドで動的にリソース設定を変更でき、Podは自動的に拡張後のリソースを利用し始めます。結果として、AIジョブの処理時間短縮とクラスターのリソース有効利用を両立できる点が大きなメリットです。

Gang Schedulingアルファ機能の概要とAI/MLジョブ同時実行のメリット徹底解説

Kubernetes 1.35で導入されるGang Scheduling機能は、同じワークロード内の全Podを同時にスケジューリングすることで、分散処理の効率を高めます。AI/MLのトレーニングジョブでは、モデルのパラメータ更新を並列で処理するために複数Podを一括で稼働させる必要があり、この機能が効果を発揮します。Gang Schedulingを使用すると、全Podが揃った状態で一斉に実行されるため、片方だけ先行して計算を始めて後続が待機するなどの問題が解消されます。現在はアルファ機能として実験的に利用可能で、設定にはPodGroupリソースや専用のスケジューラフラグが必要ですが、安定すれば大規模並列処理のワークロード管理がより簡便になります。

新PodGroup APIリソースの導入とグループジョブ管理徹底解説

PodGroupは、Kubernetes 1.35で提供予定の新しいAPIリソースです。PodGroupを使うことで、複数Podを1つのグループとして一元的に管理できるようになります。具体的には、同じPodGroupに属するPod同士でリソース要件を共有し、Gang Schedulingと連携して同時スケジュールを実現することができます。また、PodGroupには全体の必要リソース量や優先度などを定義でき、たとえば特定のジョブが必要とする総メモリ量をあらかじめ指定することで、クラスターがそれを満たすタイミングでジョブが開始されます。これにより、AIトレーニングのような一斉実行が求められるジョブ管理が容易になり、リソース不足によるデッドロックや余裕あるクラスター割り当てが可能になります。

拡張されたHPA許容度設定の概要とAIトレーニング最適化徹底解説

Kubernetes 1.35では、Horizontal Pod Autoscaler（HPA）の許容度設定がより柔軟になりました。従来は固定値だったスケールアウト/インのしきい値を、カスタム許容度（Tolerance）として調整できるようになっています。これにより、AIトレーニングジョブのように急激な負荷変動が起こるワークロードでも、HPAが過剰にPodを増減させることなく、適切なスケール調整が行えるようになります。たとえば、ポッド起動時のバーストを考慮した許容度設定を行うことで、リソースの過不足を抑制しつつよりきめ細かなスケーリングが可能です。HPAの新オプションを活用してリソース要求に対する弾力性を高めることで、トレーニングの安定性と効率を両立できます。

Flagz/statuszエンドポイント拡張による運用監視強化解説

Kubernetes 1.35では、/flagz や /statusz といったAPIサーバーおよびコントロールプレーンコンポーネントのデバッグ用エンドポイントも強化されています。これらのエンドポイントは内部状態や設定パラメータをHTTP経由で取得できるもので、新バージョンではバージョン管理されたz-pagesとして公式ドキュメントに統合されました。運用者は、通常のログでは取得しづらい情報をこれらのエンドポイントから得られるため、クラスター挙動の詳細な分析やトラブルシューティングに役立ちます。特に大規模クラスターでは、/statusz によるコアコンポーネントの健全性確認などが運用の効率化につながります。

Kubernetes 1.35でスケーラビリティとパフォーマンスが向上した新機能と最適化施策徹底解説

Kubernetes 1.35には、クラスタのスケーラビリティ向上とパフォーマンスの最適化を支援する機能強化も含まれています。特に、ノードメンテナンス時のサービス影響を低減するためにKubeletの挙動が改善され、再起動後もPodのステータスが維持されるようになりました。また、水平Podオートスケーリング（HPA）機能の拡張や、トップロジーを考慮した新しいスケジューリングオプション（Topology-Aware Scheduling）の導入により、より効率的なリソース配置が可能になります。さらに、APIサーバーのList/Watch処理が最適化され、大規模なクラスタ運用でも負荷軽減が期待できます。これらの改善により、Kubernetes 1.35では大規模環境での安定性とスループットが全般的に向上します。

Kubernetes 1.35で実現したKubelet再起動時のPod安定性向上とダウンタイム低減

従来、kubelet再起動時にはコンテナ状態がリセットされ、一時的にPodがNotReadyとなる問題がありました。Kubernetes 1.35では、この問題が改善され、kubeletが起動時にランタイムから直接コンテナの状態を回復できるようになりました。その結果、ノードのメンテナンスや再起動時にもPodのステータスが維持され、ロードバランサーから除外される時間が短縮されます。運用上のメリットとして、ノード更新時にもアプリケーションの可用性を高く維持しやすくなり、クラスタ全体の安定性が向上します。

拡張HPA許容度設定によるオートスケーリング精度向上解説

上記AIワークロードの章でも触れた通り、HPAの許容度設定強化は大規模なクラスタ環境でのスケーラビリティに直結します。Kubernetes 1.35ではスケールアウト/インのしきい値をカスタマイズ可能になり、急激な負荷変動に対しても適切にPod数を増減できるようになりました。これにより、スケーラビリティの要求が高いアプリケーションでも、リソースの過不足を抑制しつつ、よりきめ細かなスケーリングが可能になります。結果として、クラスター全体のリソース消費を最適化しつつ、パフォーマンスを損なわない運用が実現できます。

Kubernetes 1.35: Topology-Aware Scheduling機能の概要とスケジューラ最適化

Topology-Aware Schedulingは、Kubernetes 1.35で導入される新しいスケジューリングオプションです。この機能を使うと、Podの配置時にノードの地理的配置やネットワークトポロジーを考慮できるようになります。例えば、リージョンやゾーンごとにPodを分散配置することで、耐障害性を高めながらデータ転送レイテンシを最小化することが可能です。また、トポロジー情報を考慮することで、同一ノード上への過集中を防ぎ、クラスター全体の負荷分散を最適化します。これにより、大規模クラスター環境でのスケジューラーの柔軟性が向上し、効率的なリソース利用が促進されます。

Kubernetes APIサーバのリスト/ウォッチ処理最適化と大規模クラスタ対応

Kubernetes 1.35では、APIサーバーのList/Watchメカニズムにも改善が加えられ、特に大規模クラスタでの効率が向上しています。具体的には、メモリ使用量の削減や、watchイベントの通知遅延の最小化といった最適化が行われました。これにより、大量のPodやServiceを管理する環境でもAPIサーバーがボトルネックになりにくくなり、応答性が高まります。運用者はこれらの最適化により、クラスタのスループットが向上し、よりスムーズなスケーラビリティを実現できる点に留意しておくと良いでしょう。

クラスター全体のリソース割り当て最適化による性能改善の取り組み

Kubernetes 1.35ではそのほかにも、クラスター全体のパフォーマンスを向上させる多くの改善が行われています。例えば、etcdへのアクセス効率化、コントロールプレーンコンポーネントの共有ライブラリ最適化、不要な処理の削減などが挙げられます。これにより、大規模クラスターでのCPU・メモリ使用効率が向上し、総合的なスケーラビリティが改善されます。また、運用監視やメトリクス収集ツールとの連携が強化されているため、ボトルネックの検出やパフォーマンスチューニングも容易になります。これらの改善は目に見えにくいものの、システム全体の健全性向上に寄与しています。

Kubernetes 1.35で押さえておきたい運用ベストプラクティスと効率的な管理手法: 完全ガイド解説

Kubernetes 1.35への移行・運用に際しては、機能理解に加え、日常的な運用の最適化が求められます。まず、クラスターの監視・ログ収集を強化し、PrometheusやGrafanaなどでリソース使用状況やアプリケーションの健全性を可視化しましょう。また、etcdやコントロールプレーンの定期的なバックアップと復旧訓練を実施し、いざというときのリスクに備えます。セキュリティ面ではPodSecurityPolicyやネットワークポリシーを適切に設定し、必要な権限のみを付与する原則（最小権限）を徹底します。さらに、アップグレード後もスムーズに運用できるように、CI/CDパイプラインやマニフェストの検証ルールを更新し、新バージョンのAPIに対応させておくとよいでしょう。これらの運用ベストプラクティスを取り入れることで、Kubernetes 1.35環境を安定かつ効果的に管理できます。

Kubernetes 1.35でのリソース監視とログ収集: 重要メトリクスとツール解説

安定運用のためには、リソース監視とログ収集が欠かせません。Kubernetes 1.35では、各ノードやPodのCPU・メモリ使用率、スループット、エラーレートなどの重要なメトリクスを常に監視し、異常検知を迅速に行える体制を整えましょう。PrometheusやGrafanaを用いてダッシュボードを構築し、Kubernetes固有のメトリクス（kube-apiserverの応答時間やetcdのレイテンシなど）も収集対象に含めます。また、ELKスタックやFluentdなどでログを集約し、イベントや障害時のトラブルシュートに役立てます。監視ツールのアラート設定は早期検知の鍵となるため、事前に閾値をチューニングしておくことが重要です。

継続的アップグレードとパッチ適用のベストプラクティス

Kubernetesとその依存コンポーネントは頻繁に更新されるため、継続的なアップグレード計画が必要です。各リリースのセキュリティパッチやバグフィックスを迅速に適用するため、ステージング環境を使った検証プロセスを構築しましょう。バックアップ後に順次クラスタをアップグレードし、問題なければ自動化ツール（AnsibleやArgoCDなど）で実作業を行います。また、Kubernetes LTSサポート期間を意識し、古いバージョンを長期間稼働させ続けない運用体制を整えることも重要です。ポッドを常に最新イメージに更新するRollout機能や、自動修復を促すPodDisruptionBudgetの活用もベストプラクティスです。

強化されたPodセキュリティとネットワークポリシーの運用管理

Kubernetes 1.35ではセキュリティ機能も強化されています。PodSecurityPolicy（PSP）またはPod Security Admissionなどでポッドの権限を制限し、コンテナ実行時のセキュリティ境界を強固にしてください。ネットワークポリシーを活用し、各Namespace間のトラフィックやPod間通信のアクセス制御を明確化することも重要です。また、特権コンテナの使用やホストパスボリュームのマウントは必要最低限に留め、可能な限り非特権ユーザーでPodを実行する運用を心がけましょう。これらのポリシー遵守により、脅威の拡散を防ぎ、堅牢なクラスタ環境が維持できます。

リソースオートスケーリングの運用ポイント: HPA/KEDAとクラスタオートスケーラ

動的な需要に対応するため、Horizontal Pod Autoscaler（HPA）やKEDAといったオートスケーリング機能を適切に運用しましょう。HPAでは正しいメトリクス（CPU、メモリ、カスタムメトリクス）を設定し、最小・最大Pod数の上限を明示して過度なスケールアウトを防ぎます。Kubernetesクラスター全体のノードを自動追加するCluster Autoscalerを組み合わせると、Pod数増加時に必要なノードリソースを自動で確保できます。これらのオートスケール機能の設定を継続的に見直し、リソース使用パターンに応じて適切にチューニングすることで、コストを抑えつつ負荷に応じた柔軟なスケーリングが可能になります。

トラブルシューティングガイド: Kubernetes 1.35で遭遇しやすい問題と解決策

新バージョンへの移行後は、既知の問題や設定ミスに対処することが不可欠です。Kubernetes 1.35では、新機能に伴う予期せぬ挙動として、コマンドラインツール（kubectl）のバージョンミスマッチや、新しい機能ゲートのデフォルト値による権限エラーなどが報告されています。まず kubectl とクラスター間のバージョン互換性を確認し、必要ならクライアントを1.35に更新します。RBAC周りでは、新機能ゲートを有効化した場合の権限不足が多いため、ログにPermissionDeniedエラーがないかチェックします。クラスタが起動しない場合は、kubectl describe nodeやkubectl logsでエラーの詳細を取得し、公式ドキュメントやコミュニティフォーラムを参照して解決策を見つけましょう。このようなトラブルシュートを習慣化すれば、運用の安定性が高まります。

Kubernetes 1.35の変更が既存ワークロードに与える影響と移行時に必要な対策徹底解説

既存のワークロードをKubernetes 1.35環境に移行する際は、新旧バージョンの機能差分がアプリケーションにどのような影響を与えるか慎重に評価する必要があります。たとえば、APIやCRDのバージョン変更により動作が変わるリソース（例:デプロイメントやボリューム関連の設定）については事前にマニフェストを見直してください。また、Podのセキュリティ設定やネットワークポリシーの強化により、これまで接続できていたサービスがブロックされる可能性があります。カスタムコントローラやオペレーターを利用している場合は、新バージョンでの互換性を確認し、必要に応じてバージョンアップや設定変更を行います。移行後には性能試験や安定性チェックを行い、リソース利用量やレスポンスタイムに異常がないかを確認しましょう。これらの対応を事前に行うことで、Kubernetes 1.35への移行後も既存ワークロードがスムーズに動作し続けるようになります。

既存マニフェストとCRDの互換性チェック: API変更点と対応策

アップグレード後にワークロードを正常動作させるには、マニフェスト（YAML定義）の互換性を確認することが不可欠です。まず、apiVersionやリソースのスキーマが1.35でサポートされているか確認し、非推奨APIが使われていれば最新のAPIバージョンに置換します。カスタムリソース（CRD）を使用している場合も、新しいKubernetesバージョンでCRDバージョンの互換性が維持されているかをチェックし、必要に応じてCRDのアップデートを行ってください。たとえば、Podのspec.selectorやVolumeの変更点を事前に把握し、古いフィールドを使っていないかマニフェスト全体を検査することで、不具合の発生を予防できます。

Deployment/ReplicaSetの動作変化: Kubernetes 1.35で確認すべき設定

DeploymentやReplicaSetなどのコントローラー動作も、Kubernetes 1.35で細かく改善されています。例えば、PodのTerminationGracePeriodの扱いや、Pod Replacement Policyなどアップグレードに伴ってデフォルト設定が変わる可能性があります。ワークロード定義にpodTemplateのオプションやJob/Deployment固有のフィールドが含まれている場合は、公式リリースノートでこれらの詳細な変更を確認し、必要に応じて値を調整してください。また、Environment変数やVolumeマウントが新バージョンに対応していることも併せて検証します。これらの設定を見直すことで、既存アプリケーションが意図したとおりに動作し続けることを確保できます。

ネットワーク設定の互換性: Service・Ingressの確認ポイント

Kubernetes 1.35においては、ServiceやIngressの仕様変更も確認が必要です。ClusterIPやLoadBalancerタイプのServiceでは、古いSessionAffinityやヘルスチェックオプションが廃止されている場合があります。また、先述のIngress NGINXの退役に伴い、既存のIngressリソースが正しく動作しない可能性があるため、新しいIngressコントローラへの移行準備が必要です。ネットワークプラグイン（CNI）のバージョンアップも忘れず、ネットワークポリシーが新しいバージョンでサポートされる形式で書かれているか検証しましょう。これらの対策で、ネットワーク周りのトラブルを事前に回避することができます。

カスタムコントローラ/オペレーターの動作検証方法

社内開発のカスタムコントローラやサードパーティ製のオペレーターを使用している場合は、Kubernetes 1.35での動作互換性を事前に検証します。特にCRDのバージョンや、コントローラがKubernetes APIをどのように呼び出しているか（例えば、古いAPIコールを参照していないか）をチェックしてください。動作確認には専用のテストワークロードやデバッグツールを使用して、1.35環境で同じ動作を再現できるか試験します。問題が見つかった場合は、オペレーターのアップデートや設定変更を行い、クラスターと同期するようにします。これによって、アップグレード後もカスタム機能が期待どおりに動作するか保証されます。

移行後のパフォーマンスと安定性評価の実施方法

最後に、Kubernetes 1.35に移行した後は、既存ワークロードのパフォーマンスと安定性を評価してください。負荷テストツールやベンチマークを使ってアプリケーションの応答時間やスループットを測定し、移行前後で大きな差がないか比較します。また、Podの再起動頻度やエラー率などもモニタリングし、クラスター全体の健全性を確認します。性能低下や新たなエラーが発生した場合は、リソース割り当ての見直しやコード・設定の最適化を行いましょう。十分な検証が行われていれば、アップグレード後もユーザー体験を損なうことなく、新機能の恩恵を享受できます。