Kubernetes Dashboardは、かつてKubernetesの主要なビジュアルインターフェースでしたが、アーカイブされました。多くのユーザーにとって重要なオンランプとして機能し、クラスターの可視性とリソースの検査を簡素化しました。Headlampは、Dashboardの基盤の上に構築され、このレガシーを引き継いでいます。モダンなKubernetesの使用パターンを取り入れながら、明確なビジュアルインターフェースを提供します。Headlampは、マルチクラスターの可視性、Projectsを通じたアプリケーション中心のビュー、そしてプラグインによる拡張性を提供します。この移行は、Dashboardのユーザー中心のレガシーを尊重し、成長し続けるUIソリューションを提供することを目的としています。Kubernetes Dashboardの多くの使い慣れたワークフローはHeadlampにも引き継がれており、継続性と使いやすさを保証します。Headlampは、単一のインターフェースからマルチクラスター管理を可能にすることで機能を拡張し、分散環境での摩擦を軽減します。Headlamp内のProjectsは、関連リソースをグループ化して理解とトラブルシューティングを容易にする、アプリケーション中心のビューを提供します。このプラットフォームは、GitOpsワークフロー用のFluxプラグインやガイダンス用のAIアシスタントなどのプラグインを通じて拡張可能です。Headlampは、クラスター内ツールまたはデスクトップアプリケーションとして使用できる柔軟なデプロイメントオプションを提供します。現在のDashboardの使用状況（クラスター、名前空間、認証を含む）を理解することは、Headlampへのスムーズな移行を支援します。

Kubernetesは、より正確なCVEレコードを洗練させることで透明性を向上させています。古いCVEレコードには不一致が発見されており、一部では修正済みバージョンが誤って記載されていました。Kubernetesセキュリティ対応委員会は、2026年6月1日にこれらのレコードを修正します。これにより、脆弱性スキャナーが以前は検出されなかった問題を発見する可能性があります。この記事では、修正されていない3つの脆弱性、CVE-2020-8561、CVE-2020-8562、およびCVE-2021-25740に関する技術的な詳細を提供します。これらの更新により、正確な脆弱性スキャンが保証され、継続的な管理者による緩和策の必要性が明確になります。修正されていないCVE-2020-8554も、標準化されたバージョン番号形式で提供されます。特定された脆弱性が修正されていないのは、それらを修正するとKubernetesのコア機能が中断されるためです。各脆弱性には、管理者がクラスターを保護するために実装すべき特定の緩和策があります。これらの脆弱性のアーキテクチャ上の性質を考慮すると、これらの措置は非常に重要です。プロジェクトは、これらのリスクを管理するための「設定によるセキュア」アプローチを強調しています。これらのレコードの更新は、透明性と正確なリスク評価を促進する、成熟したセキュリティエコシステムを示しています。

SIG-Etcd は、分散データベースの重要なアップデートである etcd v3.7.0 の最初のベータ版をリリースしました。このバージョンでは、大規模な結果セットの処理を改善し、レイテンシとメモリ管理を強化するように設計された機能である RangeStream が導入されています。このリリースには、レガシーコンポーネントとインターフェースのリファクタリングとクリーンアップも含まれており、全体的なパフォーマンスが向上しています。開発者は、ユーザーにベータ版をテストし、etcd リポジトリで見つかった問題を報告することを奨励しています。主なハイライトは、etcd v2store の最後の痕跡が削除され、v3store への移行が完了したことです。この移行は、特に v3.6.11 にいないユーザーにとって、破壊的な変更をもたらす可能性があるため、遭遇した問題に関するフィードバックが求められています。このベータリリースには、bbolt および raft ライブラリのアップデートも組み込まれています。さらに、リリース時期は etcd v3.4 のサポート終了 (EOL) に連動しており、5 月以降はアップデートが停止されます。コミュニティは、最終的な廃止前に、必要に応じて v3.4 の追加セキュリティパッチをリリースする準備ができています。ユーザーは v3.4 からのアップグレードを強く推奨されています。今後のベータ版は計画されており、プロトバッファのリファクタリングがさらに進み、6 月または 7 月初旬にリリース候補版と最終版が登場する可能性があります。フィードバックは、GitHub のイシュー、Kubernetes Slack チャンネル、および etcd-dev メーリングリストを通じて積極的に募集されています。

このブログ記事は、当初日付が誤って記載されていましたが、現在は2026年5月15日の公開日となっています。Kubernetes v1.36では、Cloud Controller Managerのルートコントローラーに新しいアルファ版メトリック`route_controller_route_sync_total`が導入されました。このメトリックは、クラウドプロバイダーとのルート同期操作を追跡し、`CloudControllerManagerWatchBasedRoutesReconciliation`フィーチャーゲートの監視に役立ちます。このフィーチャーはv1.35で導入され、ルートコントローラーをウォッチベースのアプローチに切り替えます。この変更により、ノードが変更された場合にのみルートを調整するため、APIコールが削減されます。新しいフィーチャーをテストするには、フィーチャーゲートが無効な場合と有効な場合でメトリックの動作を比較してください。フィーチャーゲートが無効な場合、カウンターは一定の間隔で増加します。逆に、フィーチャーが有効な場合、カウンターはノードの変更時にのみ増加します。この違いは、ノードの変更がまれな安定したクラスターで最も顕著です。フィードバックは、Kubernetes Slack、GitHubイシュー、SIG Cloud Providerコミュニティページで提供できます。詳細については、KEP-5237を参照してください。

Mixed Version Proxy (MVP) は、不明なリソースのリクエストを新しいAPIサーバーに安全にルーティングすることで、Kubernetesクラスターのアップグレードを強化し、404エラーを防ぎます。Kubernetes 1.28でAlpha機能として最初に導入されたMVPは、バージョン1.36でBetaに移行し、デフォルトで有効になります。MVPは、アップグレード中のAPIサーバーのバージョンが異なる場合に発生する問題を解決します。新しいリソースに対するリクエストが古いサーバーで失敗する可能性があります。誤った404の代わりに、リクエストはそれを処理できるサーバーにプロキシされます。MVPのBetaバージョンは、ピアの機能を判断するためにStorageVersion APIの代わりに集約されたディスカバリを使用し、機能を向上させます。このアップデートには、ピア集約ディスカバリも含まれており、クライアントに利用可能なすべてのAPIの統一されたビューを提供します。MVPを有効にするには、APIサーバーは--peer-ca-fileフラグを必要とし、必要に応じて--peer-advertise-ipおよび--peer-advertise-portも必要です。kubeadmを使用すると、これらのフラグをClusterConfigurationファイルに含めることで、プロセスを合理化できます。ユーザーは、ステージング環境でMVPをテストし、1.36アップグレードの一部としてSIG API Machineryにフィードバックを提供することが推奨されます。

Kubernetes Service の `.spec.externalIPs` フィールドは、当初クラウド外のロードバランサー機能のために設計されましたが、CVE-2020-8554 で特定されたセキュリティ脆弱性により、現在非推奨となっています。このフィールドは、Service が応答する追加の IP アドレスを指定できますが、すべてのユーザー間の信頼を前提としているため、固有のセキュリティリスクがあります。Kubernetes 1.21 ではすでに `.spec.externalIPs` の無効化が推奨され、これを強制するためのアドミッションコントローラーが導入されました。代替手段として、手動で管理される LoadBalancer サービスや、MetalLB のようなクラウド外ロードバランサーコントローラーは、より優れたセキュリティと制御を提供します。MetalLB は、管理者が IP アドレスの割り当てを制御できるようにし、セキュリティ上の懸念を軽減します。Gateway API も安全なソリューションを提供し、管理者が Gateway リソースを通じて IP を制御できるようにします。Kubernetes 1.36 では `.spec.externalIPs` が正式に非推奨となり、その使用に関する警告が発行され始めました。Kube-proxy によるこの機能のサポートは将来のリリースで無効化され、完全な削除は後続のバージョンで計画されています。ユーザーは、この安全でない機能から移行することが推奨されます。

Kubernetes v1.35 は、Workload API や同一 Pod に対する基本的な gang scheduling を含む、ワークロード認識型スケジューリングの改善を導入しました。Kubernetes v1.36 は、Workload API（静的テンプレート）を新しい PodGroup API（実行時状態）から分離することで、このアーキテクチャを洗練させます。この分離により、kube-scheduler が直接 PodGroup 情報を読み取れるようになり、パフォーマンスが向上します。 新しい PodGroup スケジューリングサイクルは、ワークロードの原子的な処理を可能にし、デッドロックを防ぐためにグループ全体を統一された操作として評価します。有効な配置が見つかり、グループ制約が満たされた場合、Pod は一緒にバインドされます。それ以外の場合、グループ全体はスケジューリング不可能と見なされ、後で再試行されます。これは、厳格なワークロード要件に対するオール・オア・ナッシングの配置を保証する gang scheduling の基盤を形成します。 v1.36 のトポロジー認識型スケジューリングは、PodGroup に対するトポロジー制約の定義を可能にし、ネットワーク遅延を削減するために特定の物理的または論理的なドメイン内に Pod を共同配置します。これには、スケジューリング制約に基づいて候補配置の生成、評価、スコアリングが含まれます。 ワークロード認識型プリエンプションは、PodGroup スケジューリングサイクルをサポートするために導入され、PodGroup 全体に対応するスペースを確保するために複数のノードから同時に Pod をプリエンプトします。PodGroup を単一のプリエンプターユニットとして扱い、PodGroup の優先度と disruptionMode フィールドがプリエンプションの動作を制御します。 最後に、v1.36 は Dynamic Resource Allocation (DRA) を Workload API と統合し、PodGroup が ResourceClaims を介して特殊なハードウェアリソースを要求および共有できるようにします。これらの進歩は、将来の Kubernetes リリースにおける高度なワークロードスケジューリング機能の構築のための堅牢な基盤を築きます。

Pressure Stall Information (PSI) は 2018 年から Linux カーネルに統合されており、リソース飽和が障害につながる前に特定するための高忠実度シグナルを提供します。従来の利用率メトリクスとは異なり、PSI は CPU、メモリ、I/O 全体で停止したタスクと失われた時間を定量化します。Kubernetes v1.36 では、ノード、ポッド、コンテナレベルでのリソース競合を監視するための安定したインターフェースが利用可能になりました。PSI は、一時的なスパイクと持続的なリソースの緊張を区別するために、停止時間の累積合計と移動平均（10 秒、60 秒、300 秒）を提供します。 SIG Node による高密度ワークロード（80 個以上のポッド）での広範なパフォーマンス テストにより、PSI の本番環境への対応が証明されました。KubeletPSI フィーチャーゲートを切り替えることで測定された Kubelet のオーバーヘッドは、リソース使用量への影響は無視できる程度でした。Kubelet の収集ロジックは軽量であることが証明され、標準のハウスキーピング サイクルにシームレスに統合され、0.1 コア未満またはノード容量の 2.5% 未満を消費しました。 カーネル オーバーヘッドに関して、Linux カーネルで PSI を有効にすると（psi=1 対 psi=0）、高負荷下で 0.037 から 0.125 コア（ノード容量の 0.925% ～ 3.125%）の一貫した差が生じました。プライマリ コレクターである kubelet プロセスも、驚くほど低い CPU 使用率を維持し、スパイクは 1 秒を超えて 0.25 コア（6.25%）を超えることはありませんでした。 v1.36 の改善点には、よりスマートなメトリクス発行が含まれます。Kubelet は、誤解を招くゼロ値のメトリクスを報告する前に、cgroup 構成を通じて OS レベルの PSI サポートを検出するようになりました。PSI を使用するには、ノードは Linux カーネル 4.20 以上を実行し、cgroup v2 を使用し、OS レベルで PSI が有効になっている必要があります（CONFIG_PSI=y、psi=0 ブート パラメータなし）。 PSI メトリクスは v1.36 で一般的に利用可能であり、フィーチャーゲートのオプトインは不要です。ユーザーは /metrics/cadvisor エンドポイントをスクレイピングするか、Summary API をクエリできます。PSI は Linux カーネル機能であり、Windows ノードでは利用できません。コントロール プレーンの API サーバーを介して Kubelet の HTTP API にプロキシすることで、Summary API からリアルタイムの圧力データを取得できますが、これは特権操作です。

Kubernetes v1.36 は、以前は Alpha および Beta の機能拡張であったボリュームグループスナップショットの一般提供 (GA) を導入します。この機能は、拡張 API を活用して、複数のボリュームのクラッシュ整合性スナップショットを同時に有効にします。システムはラベルセレクターを使用して PersistentVolumeClaim オブジェクトをグループ化し、ワークロードを整合性のあるリカバリポイントにリストアできるようにします。この機能は CSI ボリュームドライバーでのみサポートされており、書き込み順序の整合性を必要とする複数のボリュームを利用するアプリケーションに大きな利点をもたらします。 以前は、個々のボリュームスナップショットは、特にマルチボリュームアプリケーションの場合、異なる時間に取得されると不整合を引き起こす可能性がありました。グループスナップショットは、手動でのアプリケーションの静止の必要性をなくし、煩雑な逐次的な個々のスナップショットなしに、グループ内のすべてのボリュームでクラッシュ整合性を提供します。Kubernetes は、3 つのカスタム API の種類である VolumeGroupSnapshot、VolumeGroupSnapshotContent、および VolumeGroupSnapshotClass を通じてグループスナップショットを管理します。これらの CRD は、GA リリースで v1 に昇格され、ユーザーはそれぞれグループスナップショットを要求し、プロビジョニングされたリソースを追跡し、作成ポリシーを定義できます。 GA リリースでは、以前のベータ版からのフィードバックに基づいた安定性の向上、バグ修正、およびリストアサイズのレポートの改善がもたらされます。この機能を使用するには、ユーザーはグループ化する PersistentVolumeClaims にラベルを付け、これらのラベルに一致するセレクターと VolumeGroupSnapshotClass を持つ VolumeGroupSnapshot オブジェクトを定義する必要があります。リストアの場合、新しい PersistentVolumeClaims は、より大きな VolumeGroupSnapshot の一部である個々の VolumeSnapshot オブジェクトから作成されます。ストレージベンダーは、CSI ドライバー内に新しいグループコントローラーサービスと RPC を実装することでサポートを追加できます。

Kubernetes v1.36 の Dynamic Resource Allocation (DRA) は、CPU やメモリなどのネイティブリソースにまで機能を拡張し、専門的なハードウェアを超えた大幅な進歩をもたらします。ネットワークを含むさまざまなハードウェアタイプに対するドライバーサポートが拡大しており、DRA はよりハードウェアに依存しないソリューションとなっています。スケジューリングの柔軟性とクラスターの利用率を高めるいくつかの主要な機能が卒業しました。Prioritized list 機能は、デバイスリクエストのフォールバックプリファレンスを可能にし、リソース割り当ての効率を向上させます。Extended resource support は、従来の拡張リソースを介したリソースリクエストを可能にすることで、DRA への段階的な移行を可能にします。Partitionable devices は、物理ハードウェアをより小さく論理的なインスタンスに動的に分割するためのネイティブ DRA サポートを提供します。Device taints は、障害のあるデバイスの割り当てを防いだり、特定のハードウェアを予約したりすることで、管理者がハードウェアをより効果的に管理できるようにします。Device binding conditions は、外部リソースが完全に準備されるまで Pod のコミットメントを遅延させることで、スケジューリングの信頼性を向上させます。Resource health status は、Pod ステータスにデバイスの正常性情報を直接公開し、ハードウェア障害の迅速な特定と対応を支援します。新しいアルファ機能には、PodGroups 間で共有リソースを管理することにより、大規模な AI/ML を最適化する、ワークロード向けの ResourceClaim サポートが含まれます。Node allocatable resources は、CPU とメモリの割り当てを DRA の傘下に統合し、きめ細かなパフォーマンスチューニングを可能にします。DRA リソースの可用性の可視性は、管理者にリアルタイムのデバイス容量情報を提供し、より良い計画を可能にします。Deterministic device selection は、ドライバーが辞書順によるスケジューリングに影響を与えることを可能にします。コンテナ内の Discoverable device metadata は、ドライバーがデバイス属性をコンテナに公開するための標準プロトコルを提供します。将来のロードマップは、既存の機能の成熟、パフォーマンスとスケーラビリティの向上、ワークロード認識型およびトポロジー認識型スケジューリングとの統合に焦点を当てており、Device Plugin からのユーザーの DRA への移行に重点を置いています。