RSS Kubernetes ブログ ノート

RSS Kubernetes ブログ

Kubernetesの公式ホームページは、コンテナーオーケストレーションシステムで、コンテナー化されたアプリケーションのデプロイメント、スケーリング、管理を自動化するためのプラットフォームです。このプラットフォームは、Cloud Native Computing Foundationが維持するKubernetesプロジェクトに関する包括的なドキュメントを提供します。Kubernetesを使用してステートレスアプリケーションとステートフルアプリケーション、バッチジョブ、CI/CDワークフローを実行する詳細なガイド、チュートリアル、リファレンス資料、APIドキュメント、コミュニティーエンゲージメントイニシアチブが含まれています。これらのリソースを使用して、Kubernetesを始め、クラウドベースのアプリケーションを効率的に管理するためのKubernetesの機能を効果的に活用することができます。

ノートのスレッド

SIG etcd は、分散型キーバリューストアの重要なアップデートである etcd v3.7.0 のリリースを発表しました。このリリースでは、待望の RangeStream 機能が導入され、大規模な結果セットの効率的なストリーミングが可能になります。また、より高速なリース操作や最適化されたキーのみのレンジリクエストを含む、さまざまなパフォーマンスの向上が実現されています。レガシーな v2 ストアへの依存は完全に排除され、etcd は v3store からのみ起動するようになり、運用が簡素化されました。包括的な protobuf のオーバーホールにより、古いライブラリがサポートされているバージョンに置き換えられ、セキュリティと保守性が向上しました。このリリースでは、コア依存関係も更新され、bbolt は v1.5.1、raft は v3.7.0 になりました。さらなる改善点として、ローカル開発およびテスト用の Unix ソケットのサポートが含まれます。etcdutl コマンドには、無期限のブロックを防ぐためのタイムアウト引数が追加されました。Client v3 は、直接 JWT を設定できる機能と、認証なしで AuthStatus を取得できる機能により、認証の柔軟性が向上しました。監視強化のために、新しいウォッチおよびリクエストの期間メトリクスが追加されました。etcdctl コマンドは明確化のために再編成され、非推奨の実験的フラグは削除されました。レガシーな v2 API パッケージおよびコードの大規模なクリーンアップも実施されました。
AIはソフトウェア開発を変革し、コード生成を通じてより多くの貢献者を可能にしています。しかし、この進歩はコード保守の改善を上回っており、課題を提示しています。Kubernetesコミュニティは、包括的なAIポリシーを確立することで、AI支援コーディングに積極的に適応しています。このポリシーは、イノベーションと説明責任のバランスを取り、コード品質と人間の監督を確保することを目的としています。中核的な原則は透明性であり、貢献者はプルリクエストでAIの使用を開示する必要があります。極めて重要なのは、人間の説明責任が最優先されることです。AIは共同著者または共同署名者としてリストすることはできません。貢献者は、AI生成コードについても個人的に説明する必要があり、知識のギャップを防ぎます。プロジェクトは、AI支援のものを含むすべての共同著者に対して貢献者ライセンス契約を施行し、不完全なPRにフラグを立てます。コード品質を向上させ、初期フィードバックを提供するために、自動AIレビューが検討されています。GitHub CopilotやCodeRabbitのようなツールは、特定のKubernetesプロジェクト内で評価およびテストされています。これらのツールは、人間のレビューの前に迅速なスポットチェックを提供する品質ゲートとして機能できます。コミュニティは、レビューツールの調整、新興AI技術の評価、およびメンテナーの燃え尽き症候群の軽減とテストトリアージの支援におけるAIの可能性の探求に積極的に協力を求めています。
Headlampは、ブラウザからクラスターリソースを管理するためのオープンソースのKubernetes UIプロジェクトです。Cluster API (CAPI) は、クラスターライフサイクル管理のための宣言的なKubernetesスタイルのAPIを提供します。Headlamp Cluster APIプラグインは、CAPIリソースの管理を簡素化し、生のkubectlコマンドの必要性をなくします。このプラグインは、Headlampに専用のCAPIセクションを追加し、一貫したリストビューと詳細ビューを通じて、コアCAPIリソースへの完全な可視性を提供します。主な機能には、クラスター概要、Machineの可視性、およびヘルスモニタリングのための集中化されたCluster APIダッシュボードが含まれます。ユーザーは、KubeadmControlPlaneレプリカを追跡し、MachineDeploymentsとMachineSetsをスケーリングし、所有リソース階層を視覚化できます。このプラグインは、生のYAMLなしでKubeadmConfigを検査でき、トポロジー認識も提供します。マップビューは、Cluster、Control Plane、およびWorkerの関係を視覚化し、v1beta1とv1beta2の両方のCluster APIバージョンをサポートします。Prometheusメトリクスは、詳細ページにインラインでライブパフォーマンスデータを提供するために統合されています。CNCF LFX Mentorshipプログラム中に開発されたこのプラグインは、Cluster API管理エクスペリエンスを向上させることを目的としています。これはアルファリリースであり、今後の開発のためにコミュニティからのフィードバックを奨励しています。
CdXz5zHNQW_bupmQg41I4.png
Volcanoは、ハイパフォーマンスコンピューティング、AI/ML、その他のバッチワークロード向けに設計された、Kubernetes向けのクラウドネイティブなバッチスケジューラです。Kubernetesは元々長時間実行されるサービスのために構築されましたが、バッチワークロードはしばしば動的なジョブの到着、リソースの競合、複数のワーカーの同時起動を必要とします。Volcanoは、キュー、優先度、クォータ、ギャングスケジューリングといった概念でKubernetesを拡張し、ワークロードを独立したPodではなく、全体として扱います。拡張可能なKubernetes Web UIであるHeadlamp向けのVolcanoプラグインは、これらのスケジューリングの詳細を単一のインターフェースにもたらします。このプラグインは、Volcano Jobs、Queues、PodGroups専用のビューを提供し、バッチワークロードの運用とトラブルシューティングを容易にします。Jobビューは、ワークロードのステータス、タスクの詳細、Podのステータスを表示し、一時停止/再開やログへのアクセスといった直接的な操作を可能にします。Queueビューは、リソース割り当て、容量、予約の詳細に関する洞察を提供します。PodGroupビューは、ギャングスケジューリングの状態と潜在的なブロッカーを明確にします。重要な機能の1つはマップビューであり、Jobs、Queues、PodGroups、Podsがどのように相互接続されているかを視覚的に表現し、保留中または進行しないワークロードの問題を迅速に特定するのに役立ちます。このプラグインは、自動化のためのCLIツールを置き換えることなく、関連リソース、構造化された詳細、および実行時出力を一元化することで、インタラクティブなトラブルシューティングエクスペリエンスを強化します。将来の機能強化には、Prometheusとの統合や、より豊富なスケジューリングの洞察が含まれる可能性があります。ユーザーは、HeadlampのPlugin Catalogを通じてプラグインをインストールし、その開発を形成するためのフィードバックを提供できます。
CdXz5zHNQW_lVauTs2nj6.png
Headlampは、Kubernetesリソースを管理およびデバッグするために設計されたオープンソースプロジェクトです。KnativeはKubernetes上でサーバーレスワークロードを可能にしますが、複数のツールを横断して運用するのは複雑になる可能性があります。この課題に対処するため、Knative用のHeadlampプラグインが開発されました。このプラグインにより、ユーザーはHeadlamp内からKnativeを包括的に管理できます。KnativeリソースをHeadlampのリソースマッピングビューに統合し、KService、Revision、DomainMapping間の関係を表示します。プラグインはKServiceの詳細ビューを提供し、トラフィック分割とオートスケーリング構成のライブ編集を可能にします。ユーザーは、KServiceヘッダーから直接ポッドを再起動したり、ログにアクセスしたりすることもできます。プラグインは、段階的なロールアウトとA/Bテストのために、リビジョン間の詳細なトラフィック分割を容易にします。各リビジョンのトラフィック分布、準備状況、タグを視覚的に表示します。オートスケーリング構成は明確に提示され、設定が明示的であるか、クラスターのデフォルトから継承されているかを示します。Prometheusプラグインと組み合わせると、KServiceおよびRevisionのリクエストレートやレイテンシなどのメトリクスを提供します。プラグインは、Revision、DomainMapping、およびネットワーキングの概要を含む、他のKnative CRDのリストビューと詳細ビューも提供します。インストールは、HeadlampのプラグインカタログからKnativeプラグインを検索してインストールすることを含みます。フィードバックやバグレポートは、GitHubのissueまたはKubernetes Slackチャンネルを通じて提出できます。
CdXz5zHNQW_uA3Yt1MH58.png
デバイス管理ワーキンググループは、Kubernetesにおける特殊ハードウェア管理の増大するニーズに対応します。GPU、TPU、および特定のネットワークインターフェースを必要とするAI、エッジ、および通信ワークロードには、従来のコンピューティングリソース割り当て方法では不十分です。ワーキンググループの主要プロジェクトである動的リソース割り当て(DRA)は、一般提供可能(General Availability)に達し、大きな進歩を示しました。DRAは、モデリング、要求、スケジューリング、およびアクチュエーションの4段階の構造化されたフレームワークでデバイス管理を提供します。この新しいアプローチにより、ベンダーは詳細なハードウェア機能を宣伝でき、ユーザーは正確なハードウェア要件を指定できます。その後、Kubernetesスケジューラは、これらの要件をインテリジェントに利用可能なハードウェアに一致させます。DRAは、デバイスを単純な整数として扱っていた従来のデバイスプラグインAPIを、柔軟で宣言型のAPIに置き換えます。ワーキンググループは、Kubernetesコンポーネント全体での包括的な統合を確保するために、複数のSIGが関与するクロスSIGの取り組みです。現在の取り組みは、DRAの表現力の向上、運用可視性のサポート、およびマルチノードおよび複雑なハードウェアトポロジ管理の改善に焦点を当てています。今後の作業には、デバイスのヘルスモニタリングと、グループ化されたデバイス使用のサポート強化が含まれます。ワーキンググループは、Kubernetesのよりプログラマブルでハードウェアを意識した未来を創造することを目指しています。
この記事は、永続データとボリューム管理を担当するKubernetesの特別関心グループであるSIG Storageに焦点を当てています。SIG Storageの共同議長であるXing Yangは、グループが基本的な永続ボリュームの処理から複雑なストレージ機能の推進へと進化してきた経緯について説明しています。当初はステートレスワークロード向けに設計されたKubernetesは、現在ではステートフルアプリケーションもサポートしており、専用のストレージソリューションが必要となっています。SIG Storageはこれらの課題に対処するために結成され、PersistentVolumesやPersistentVolumeClaimsといったプリミティブを導入しました。重要な進歩は、サードパーティのストレージプロバイダーがコアKubernetesの変更なしにシステムを統合できるようにするContainer Storage Interface(CSI)でした。現在の作業には、クラッシュ整合性のあるマルチボリュームスナップショットのためのVolume Group Snapshotと、効率的なバックアップのためのChanged Block Trackingが含まれており、これらは最近安定版に昇格しました。Container Object Storage Interface(CSI)も、オブジェクトストレージ統合の標準化に向けて進んでいます。ユーザーにとって最近の成果としては、IOPSのようなストレージプロパティの動的な調整を可能にするVolumeAttributesClassが一般提供(General Availability)に昇格したことが挙げられます。将来のロードマップには、運用上の可視性を向上させるためのVolume Healthと、潜在的な自動修復機能が含まれています。SIG Storageは、バグ修正、テスト、レビュー、およびMutable PV Affinityやボリュームレプリケーションのような機能に関するフィードバックについて、コミュニティの協力を求めています。ステートフルワークロードの課題には、データグラビティ、Day-2運用の複雑さ、データモビリティが含まれます。AIワークロードが増加するにつれて、Kubernetesにおけるストレージはよりインテリジェントになると予想されており、オブジェクトストレージが重要性を増しています。高性能、低遅延ストレージ、およびデータ認識スケジューリングも、予想されるトレンドです。SIG Storageは、これらの進化するストレージ需要に対処するために、コミュニティの関与を歓迎しています。
Kubernetes Dashboardは、かつてKubernetesの主要なビジュアルインターフェースでしたが、アーカイブされました。多くのユーザーにとって重要なオンランプとして機能し、クラスターの可視性とリソースの検査を簡素化しました。Headlampは、Dashboardの基盤の上に構築され、このレガシーを引き継いでいます。モダンなKubernetesの使用パターンを取り入れながら、明確なビジュアルインターフェースを提供します。Headlampは、マルチクラスターの可視性、Projectsを通じたアプリケーション中心のビュー、そしてプラグインによる拡張性を提供します。この移行は、Dashboardのユーザー中心のレガシーを尊重し、成長し続けるUIソリューションを提供することを目的としています。Kubernetes Dashboardの多くの使い慣れたワークフローはHeadlampにも引き継がれており、継続性と使いやすさを保証します。Headlampは、単一のインターフェースからマルチクラスター管理を可能にすることで機能を拡張し、分散環境での摩擦を軽減します。Headlamp内のProjectsは、関連リソースをグループ化して理解とトラブルシューティングを容易にする、アプリケーション中心のビューを提供します。このプラットフォームは、GitOpsワークフロー用のFluxプラグインやガイダンス用のAIアシスタントなどのプラグインを通じて拡張可能です。Headlampは、クラスター内ツールまたはデスクトップアプリケーションとして使用できる柔軟なデプロイメントオプションを提供します。現在のDashboardの使用状況(クラスター、名前空間、認証を含む)を理解することは、Headlampへのスムーズな移行を支援します。
CdXz5zHNQW_NGyZ88sXD3.png
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 からリアルタイムの圧力データを取得できますが、これは特権操作です。
CdXz5zHNQW_xWB13lRlZh.png
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 への移行に重点を置いています。
Kubernetesコントローラーは、特に高カーディナリティのリソースを監視する際に、クラスターサイズが増加するにつれてスケーリングの課題に直面します。クライアントサイドシャーディングは機能的ですが、APIサーバーからのデータ量を削減しないため、非効率性を引き起こします。Kubernetes v1.36でアルファ機能(KEP-5866)として導入されたサーバーサイドシャーディングリストとウォッチは、この非効率性を解消します。APIサーバーは、コントローラーが指定したハッシュ範囲に基づいてイベントをフィルタリングし、各レプリカに関連するデータのみを送信します。コントローラーはインフォーマーを使用してリソースをリストおよびウォッチし、WithTweakListOptionsを介してshardSelectorを組み込みます。shard selectorは、オブジェクトのmetadata.uidまたはmetadata.namespaceに基づいてリソースをフィルタリングするために使用されます。APIサーバーは、shard selectorが正しく適用されたことを確認するために、リスト応答メタデータにshardInfoフィールドを返します。これが存在しない場合、クライアントは完全なフィルタリングされていないコレクションを処理する必要があり、クライアントサイドフィルタリングに頼る可能性があります。この機能には、ShardedListAndWatchフィーチャーゲートを有効にする必要があります。Kubernetesコミュニティは、特に大規模クラスターを管理しているコントローラー作成者やオペレーターからのフィードバックを求めています。このアプローチは、要求の厳しいKubernetes環境におけるコントローラーのパフォーマンスとスケーラビリティを向上させるように設計されています。
Kubernetes v1.36 は、ネイティブ型向けの宣言的バリデーションを導入し、一般提供を開始しました。これにより、バリデーションルールの定義が手書きの Go コードから IDL タグへと移行し、API の信頼性と予測可能性が向上します。以前は手書きコードに依存していたため、技術的負債、不整合、不透明な API が生じていました。このソリューションは、タグを解析して Go のバリデーション関数を自動生成するコードジェネレーターである validation-gen を利用します。このフレームワークには、存在、制約、コレクション、ユニオン、不変性に関するさまざまなマーカータグが含まれています。主な利点は「アンビエントラチェッティング」であり、既存のオブジェクトを壊すことなく、バリデーションを即座に厳格化または緩和できます。宣言的バリデーションにより、kube-api-linter のようなツールを使用した API レビューが容易になり、一貫性が向上します。プロジェクトは、残りのレガシーコードの移行と、新しい API に対する宣言的バリデーションの義務化を計画しています。これにより、kubectl のようなツールによるクライアントサイドバリデーションや、Kubebuilder のようなツールとの統合など、将来的なエコシステムのメリットも解き放たれます。移行は進行中であり、Kubernetes コードベースへの貢献の機会があります。このドキュメントは、貢献者への謝辞で締めくくられ、Kubernetes バリデーションの宣言的な未来を歓迎しています。
Kubernetes の v1.36 で導入されたマニフェストベースの Admission Control は、クラスターブートストラップ中のセキュリティポリシー施行のギャップに対処します。既存の API ベースの Admission Control には脆弱性があります。ポリシーは API オブジェクトであり、削除される可能性があるため、セキュリティ上のウィンドウが生じます。この新機能により、Admission Webhook と CEL ベースのポリシーを、API サーバーが起動時にロードするファイルとして定義できます。これにより、リクエストが処理される前にポリシーがアクティブになり、不正な変更から保護されます。これは、AdmissionConfiguration ファイルの staticManifestsDir フィールドを使用して、ポリシー YAML ファイルを含むディレクトリを指定します。これらのファイルは、API ベースの設定と区別するために、.static.k8s.io で終わる名前を持つ必要があります。この機能は、Admission 設定自体を削除や変更から保護できます。マニフェストファイルへの変更は、実行時に自動的に更新されます。API サーバーは、起動中に厳密な検証を施行し、実行時の更新をアトミックに処理します。これを実装するには、ManifestBasedAdmissionControlConfig フィーチャーゲートを有効にする必要があります。
Kubernetes v1.36 は、アルファ機能として Pod レベルのリソースマネージャーを導入し、パフォーマンスに敏感なワークロードのリソース管理を強化します。これは、kubelet の Topology Manager、CPU Manager、Memory Manager を、コンテナごとの仕様を超えた、ポッド中心のリソース割り当てモデルに拡張します。これにより、プライマリアプリケーションコンテナに対して、軽量なサイドカーを効率的にサポートしながら、専用の NUMA アラインされたリソースを提供するという課題に対処します。以前は、予測可能なパフォーマンスを実現するためには、すべてのコンテナに専用リソースを割り当てる必要がありましたが、サイドカーにとっては無駄でした。あるいは、そうしないと、ポッドの Guaranteed QoS が犠牲になっていました。Pod レベルのリソースマネージャーは、ハイブリッド割り当てを可能にし、高性能ワークロードがリソースを無駄にすることなく NUMA アラインメントを実現できるようにします。例えば、レイテンシに敏感なデータベースポッドでは、メインコンテナが専用の CPU とメモリを受け取り、サイドカーは他のノードリソースから分離された、別のポッド共有プールを共有できます。別のユースケースとしては、トレーニングコンテナが専用の NUMA アラインされたリソースを受け取り、サービスメッシュサイドカーが一般的なノード全体共有プールで実行される ML ワークロードが挙げられます。CPU の分離は、専用コンテナに対する CFS クォータの強制を無効にし、共有プールコンテナに対してはポッドレベルで強制することで管理されます。有効化するには、特定の kubelet feature gate、Topology Manager ポリシー、および静的な CPU および Memory Manager の設定が必要です。新しい kubelet メトリクスは、リソース割り当てとコンテナ割り当てのオブザーバビリティを提供します。この機能は現在アルファ段階であり、既知の制限事項や注意点があり、Kubernetes コミュニティチャネルを通じてユーザーからのフィードバックを奨励しています。
Kubernetes v1.36 は、コンテナメモリ管理を改善するために cgroup v2 を使用する Memory QoS 機能のアップデートを導入します。v1.36 の主なアップデートには、Pod QoS クラスに基づいた階層的な保護を提供するオプトインメモリ予約が含まれます。Guaranteed Pod はハードメモリ保護 (memory.min) を受け取るようになり、Burstable Pod はソフト保護 (memory.low) を受け取ります。BestEffort Pod は特別な保護なしで完全に回収可能なままです。新しい memoryReservationPolicy は、スロットリングと予約の個別の制御を可能にします。ノード全体での memory.min および memory.low の使用状況を監視するためのオブザーバビリティメトリクスが提供されます。カーネルバージョンチェックは、潜在的なライブロックの問題により、カーネルが 5.9 より古い場合にユーザーに警告します。この実装は、memory.maxmemory.minmemory.low、および memory.high cgroup v2 インターフェイスを活用します。ノードメモリ割り当ては kubelet によって管理され、各 Pod および QoS クラスに対して適切な保護が保証されます。この機能は kubelet 設定を介して有効にすることができ、TieredReservation が主要な設定となります。推奨される前提条件は、Kubernetes v1.36 以降、cgroup v2 および Kernel 5.9 以降の Linux です。ユーザーは、フィードバックや貢献のために SIG Node コミュニティに参加できます。
Kubernetesのコントローラは、キャッシュされたデータが古くなることで不正確なアクションや遅延アクションを引き起こす、ステイールネスに悩まされることがあります。Stalenessは、コントローラのローカルキャッシュがクラスタの実際の状態と同期していないことから発生します。Kubernetes v1.36では、膠着状態を緩和し、コントローラの動作を改善する機能が導入されている。これらの改善には、client-goでのアトミックFIFO処理が含まれ、キューの一貫性が強化されている。 kube-controller-managerは、DaemonSetやReplicaSetのようないくつかの主要なコントローラに、これらのclient-goの改善を統合しました。これらのコントローラは、動作前にキャッシュリソースのバージョンをチェックするようになり、古いデータに対するアクションを防止します。Informerの作者は、ConsistencyStoreを使用してリソースのバージョンを追跡・管理し、コントローラの陳腐化を軽減することができます。ConsistencyStoreは、書き込みの記録、キャッシュの準備状況のチェック、古くなったオブジェクトエントリのクリアのための機能を提供する。 Kubernetes v1.36では、コントローラの健全性を監視するための新しいメトリクスも提供され、これには、陳腐化による同期のスキップ数などが含まれる。Client-goはまた、共有インフォーマーの最新のリソースバージョンを公開するメトリクスを発行するようになった。 Kubernetesチームは、これらの陳腐化緩和機能をより多くのコントローラに拡張し、コントローラランタイムに統合することを計画している。彼らはユーザーからのフィードバックと今後の開発を奨励している。
Kubernetes v1.36 では、一時停止中の Job の Pod テンプレート内でコンテナのリソース要求と制限を変更できる機能がベータ版に昇格しました。v1.35 でアルファ版として導入されたこの機能により、キューコントローラーや管理者は、Job が実行される前に、一時停止中に CPU、メモリ、GPU などのリソース仕様を調整できるようになりました。以前は、リソース要件は一度設定されると変更できず、変更するには Job を削除して再作成する必要があり、貴重なメタデータが失われていました。この新しい機能は、Job 作成時にリソースニーズが正確に分からなかったり、クラスターの容量が変動したりする場合に対応します。たとえば、キューコントローラーは、機械学習 Job の GPU 要求を、4 つから 2 つに、利用可能な GPU が 2 つしかない場合に減らすことができます。Kubernetes API サーバーは、一時停止中の Job に対して特定のリソースフィールドの不変性制約を緩和し、Job の spec.suspend が true であること、および以前に実行されていた場合はすべてのアクティブな Pod が終了していることを要求します。ベータ版では、MutablePodResourcesForSuspendedJobs 機能ゲートは v1.36 でデフォルトで有効になっています。ユーザーは、一時停止中の Job を作成し、そのリソースを編集し、それを再開することでこれをテストできます。矛盾を防ぐために、一時停止中の実行中の Job のリソースを変更する前に、すべてのアクティブな Pod が終了していることを確認することが重要です。
Kubernetes v1.36 では、コンテナ化されたワークロードのセキュリティ分離を強化する Linux 専用機能であるユーザー名前空間の一般提供 (GA) が導入されました。この長らく待望されていたマイルストーンにより、Kubernetes アプリケーションの「rootless」セキュリティ分離が可能になります。重要な機能は、hostUsers: false を設定することで、特権を持つワークロードを実行しながらも、ユーザー名前空間内に閉じ込めることができる点です。これにより、CAP_NET_ADMIN のような特定のケーパビリティが名前空間化され、ローカルコンテナリソースに対する管理権限のみが付与されます。以前は、コンテナ内のルートプロセスはホスト上でもルート権限を持っており、ブレークアウト時の重大なセキュリティリスクとなっていました。この機能の主要な実現要因は、ID マッピングマウントです。これは、ディスクの所有権を変更することなく、マウント時に UID と GID を透過的に再マッピングします。これにより、開発初期段階で問題となっていたボリューム所有権の更新に関連するパフォーマンスの問題が解決されます。ユーザー名前空間の実装は簡単です。Pod 仕様で hostUsers: false を設定するだけで、コンテナイメージや複雑な設定を変更する必要はありません。この機能は、アルファ段階で導入されたものと同じインターフェースを利用しています。この進歩は、Kubernetes SIG Node、コンテナランタイム、および Linux カーネル間の長年にわたるクロスプロジェクトの協力の成果です。
Kubernetes v1.37では、ボリュームのセットアップ速度を向上させるSELinuxMountフィーチャーゲートがデフォルトで有効になる予定です。この変更により、特に特権Podと非特権Pod間でボリュームを共有しているアプリケーションなど、古い再帰的なリラベル方式に依存しているアプリケーションが動作しなくなる可能性があります。この記事では、v1.36のクラスタを監査して、SELinuxに関連する潜在的な競合を特定し、対処することを推奨しています。SELinuxが有効になっている場合、kubeletはアクセス制御のためにボリュームにSELinuxラベルを適用しますが、新しいアプローチでは、より高速なリラベルのためにマウントオプションを使用します。SELinuxChangePolicyフィールドとRecursiveオプションは、このパフォーマンス向上メソッドをオプトアウトするために作成されました。条件が満たされると、kubeletは適切なSELinuxラベルでボリュームを直接マウントできるようになり、再帰的なリラベルの必要がなくなります。selinux-warning-controllerは、新しい構成で動作しなくなる可能性のある競合するPodを特定し、イベントとメトリクスを発行します。提供されたメトリクスを使用することで、クラスタ管理者は潜在的な問題を検出し、適切な調整を行うことができます。推奨されるアップグレードパスには、コントローラーの有効化、競合の解決、エラーを監視しながらSELinuxMountが有効になっているバージョンへのアップグレードが含まれます。管理者は、特定のPodに対してオプトアウトを強制するために、さまざまな方法を使用できます。新しい動作により、パフォーマンスが向上しますが、異なるPod間でのボリューム共有が変更されます。
Kubernetes v1.36 がリリースされました。70 の機能強化が施され、そのうち 18 が安定版に、25 がベータ版に移行しました。今回のリリースのテーマは「Haru」で、春、晴天、遠い地平線を象徴しており、ロゴは葛飾北斎の「赤富士」にインスパイアされています。このリリースはコミュニティの協力を重視しており、多くの個人やチームがその成功に貢献しました。主な安定版の機能には、最小権限アクセス制御を改善するための、きめ細かい kubelet API 認可が含まれます。割り当てられたデバイスのリソースヘルスステータスがベータ版になり、ハードウェア障害の統一的なレポートを提供します。アルファ版では、関連する Pod を単一の論理エンティティとして扱い、より良いリソース管理を実現する Workload Aware Scheduling が導入されました。ボリュームグループスナップショットが安定版になり、複数の PersistentVolumeClaim にわたるクラッシュ整合性のあるスナップショットが可能になりました。可変 CSI ノード割り当て可能制限も安定版になり、ノードのボリューム容量を動的に更新できるようになりました。外部 ServiceAccount トークン署名機能は、トークン署名を外部システムにオフロードするために、安定版になりました。Dynamic Resource Allocation (DRA) の管理者アクセスと優先リストが安定版になり、リソース管理のための安全なフレームワークを提供します。宣言型のミューティングアドミッションポリシーが安定版になり、リソースミューテーションのための Webhook のネイティブな代替手段を提供します。validation-gen を使用した Kubernetes ネイティブタイプの宣言型検証も安定版に移行し、カスタムリソースの開発を合理化しました。Kubernetes API タイプに対する gogo protobuf 依存関係の削除は、セキュリティと保守性の大きな進歩を示しています。
Gateway API v1.5 は、2026年3月14日にリリースされ、これまでのリリースの中で最も重要なものとなります。このバージョンでは、以前は実験的な機能であったいくつかの機能が安定版チャネルに昇格されることに重点が置かれています。主な昇格機能には、ListenerSet、TLSRoute、HTTPRoute CORS Filter、Client Certificate Validation、Certificate Selection for Gateway TLS Origination、ReferenceGrant が含まれます。プロジェクトはリリース管理モデルを採用し、Kubernetes SIG Release と同期することで、より予測可能なアップデートを実現しています。この新しいプロセスには、専任のリリース マネージャーとリリース シャドウの役割が含まれます。ListenerSet は、リスナーを独立して定義し、Gateway にマージすることを可能にし、スケーラビリティとマルチテナンシーを向上させます。TLSRoute は、TLS 接続の SNI に基づいたルーティングを可能にし、Passthrough モードと Terminate モードの両方をサポートします。HTTPRoute CORS フィルターは、クロスオリジン リソース共有設定に対する詳細な制御を提供します。クライアント証明書検証、または相互 TLS (mTLS) は、Gateway が信頼された CA に対して証明書をチェックすることで、クライアントの ID を検証することを可能にします。この機能は、セキュリティを強化するために、グローバルまたはポートごとに設定できます。
2026年後半にリリース予定のKubernetes v1.36では、重要な削除、非推奨化、および多数の強化が導入される。このプロジェクトは、厳格な非推奨化ポリシーに従っており、安定したAPIは、新しい安定したバージョンが利用可能になり、最低限のライフタイムが保証された後でしか削除されない。最近の例として、2026年3月24日以降、Ingress NGINXプロジェクトのサポートとセキュリティアップデートが終了した。v1.36では、セキュリティ上の懸念(CVE-2020-8554)により、Serviceの.spec.externalIPsフィールドが非推奨化され、v1.43では完全に削除される予定で、LoadBalancer、NodePort、またはGateway APIへの移行が推奨される。v1.11以降非推奨化されていたgitRepoボリュームドライバーは、ルートコードの実行を可能にする重大なセキュリティ脆弱性のため、v1.36で永久に無効化される。gitRepoを使用しているワークロードは、initコンテナや外部のgit-syncツールなどの代替手段に移行する必要がある。v1.36の主な強化点としては、ボリュームのSELinuxラベル付けのパフォーマンスが向上し、Podの起動遅延が減少する。v1.28でベータ版として導入されたこの機能は、spec.SELinuxMountを指定したPodのすべてのボリュームでデフォルトで有効になる。ベータ版として導入されたServiceAccountトークンの外部署名は、v1.36で安定版になる予定で、クラスターが外部のキーマネジメントシステムと統合してセキュリティを強化できる。Dynamic Resource Allocation(DRA)も進化し、Deviceの汚染と容認がベータ版になることで、特殊なハードウェアリソースを特定のワークロードに制限できる。さらに、DRAはパーティショナブルデバイスをサポートし、単一のハードウェアアクセラレータを複数の論理ユニットに分割できるため、GPUなどの高価なリソースのリソース利用が向上する。これらの変更は、Kubernetesにおけるセキュリティ、効率、先進的なリソース管理への継続的な焦点を強調する。
Ingress-NGINXは2026年3月に退役予定であり、Gateway APIへの移行が必要となります。IngressからGateway APIへの移行は大きな転換であり、拡張された注釈からモジュール化された拡張可能なAPIへの移行です。Ingress2Gatewayツールは、Ingressのリソースとその注釈を翻訳することで、チームの移行を支援します。SIG Networkは安定した移行アシスタントであるIngress2Gateway バージョン1.0をリリースしました。この新リリースでは、Ingress-NGINXの注釈サポートが大幅に向上し、30以上の一般的な注釈がカバーされています。包括的な統合テストにより、Ingress-NGINX構成および生成されたGateway APIマニフェストの動作的同等性が保証されます。Ingress2Gatewayは翻訳不能な設定に対する明確な通知や手動介入の提案も提供しています。このツールは、サポートされている構成の移行、サポートされていない設定の特定、既存設定の再評価を促すことを目指しています。ユーザーはIngress2Gatewayをインストールし、Ingressマニフェストを提供するかクラスタに接続します。特に、生成された出力や警告を確認し、正確な翻訳を確保し、潜在的な問題を特定することが重要です。Ingress2Gatewayは多くのプロセスを自動化しますが、Gateway APIマニフェストの手動検証と調整が不可欠です。
生成AIは、無状態の関数呼び出しから、継続的に実行され、協調して動作するAIエージェントのシステムへと進化しています。これらのエージェントは、永続的なコンテキスト、ツールの使用、コード実行、そして長期間にわたるエージェント間の通信を必要とします。Kubernetesは、これらのワークロードに最適なインフラストラクチャですが、従来のプリミティブは、これらのステートフルでシングルトンなエージェントのニーズに完全に合致していません。SIG Appsが開発中の新しいKubernetes Agent Sandboxプロジェクトは、このギャップを埋めることを目指しています。これは、AIエージェントのランタイムを管理するためのカスタムリソース定義(CRD)を導入します。Sandbox CRDは、gVisorやKata Containersなどのランタイムを使用して、信頼できないコード実行に対して強力な分離を提供します。また、堅牢なライフサイクル管理も提供し、アイドル状態のときにエージェントをゼロまでスケールダウンし、即座に再開できます。さらに、各Sandboxには、シームレスなエージェント間通信のために安定したIDが割り当てられます。急速に変化するAI分野での開発を加速するために、Extensions APIレイヤーが利用可能です。SandboxWarmPool拡張機能は、すぐに使用できる事前プロビジョニングされたSandboxポッドのプールを維持することにより、コールドスタートを排除します。ユーザーは、コアコンポーネントと拡張コンポーネントをKubernetesクラスターにインストールできます。Agent Sandboxプロジェクトはオープンソースであり、クラウドネイティブAIエージェントの未来を構築するためのコミュニティの参加を歓迎しています。
「本番環境のデバッグは、広範なアクセスに依存することが多く、監査とセキュリティのリスクを伴います。この記事では、Kubernetesで安全なデバッグプラクティスを実装することを推奨しています。主な戦略としては、Role-Based Access Control (RBAC) を用いた最小権限の活用が挙げられます。セッションのセキュリティと説明責任のためには、短命でIDに紐づいた資格情報が不可欠です。SSHスタイルのゲートウェイは「玄関」として機能し、アクセスを一時的なものにします。アクセスブローカーはRBACを強化し、コマンドを制御し、承認を要求することができます。Kubernetes RBACは、許可されたアクションを定義し、通常は個人ではなくグループにアクセス権を付与します。OIDCトークンやクライアント証明書のような短命の資格情報は、セッションをユーザーに紐づけ、有効期限が切れます。これらの資格情報は、定期的にローテーションされる認証局によって署名されるのが理想的です。ジャストインタイムアクセスゲートウェイ(多くの場合、SSH経由)は、安全なデバッグセッションを提供します。ゲートウェイは、資格情報を使用してユーザーを認証し、その後、Kubernetes APIと対話する前にポリシーを適用します。セッションのスコープは、特定のクラスターと名前空間に制限できます。」
Kubernetes のイメージプロモーターである kpromo は、パフォーマンスと保守性を向上させるために完全に書き直されました。その主な機能は、コンテナイメージをステージングレジストリから本番レジストリにコピーし、署名し、署名を複製し、Kubernetes リリースのために不可欠なアテステーションを生成することです。この書き換えは、既存のコードベースの複雑さ、パフォーマンスの低下、および頻繁なレート制限エラーが原因で促されました。プロジェクトは段階的なアプローチを採用し、レート制限、インターフェース、パイプラインエンジン、およびセキュリティ機能を扱いました。主な改善点としては、パイプラインエンジンの合理化、レジストリ読み込みの並列化、タイムアウトと接続の再利用の実装などがありました。書き換えの結果、コードベースは 20% 小さくなり、パフォーマンス、堅牢性、およびプロビナンスなどの新機能が強化されました。広範囲にわたる変更にもかかわらず、書き換えチームはユーザーのワークフローを壊さないことに尽力しました。チームは、段階的なリリース中に軽微な回帰を特定し、迅速に修正しました。今後の計画としては、署名複製を排除することによるさらなる合理化、ルーティングに archeio を使用すること、または署名をレジストリインフラストラクチャにより近づけて統合することなどが検討されています。このプロジェクトは、長年にわたるコミュニティの努力の成果です。
Kubernetesコミュニティは、AIワークロードのネットワーキングに焦点を当てたAI Gatewayワーキンググループの設立により拡大しています。AI Gatewayは、Gateway APIを利用したネットワークインフラであり、AIワークロード向けに機能を強化します。これには、トークンベースのレート制限、アクセス制御、ペイロード検査などが含まれます。ワーキンググループは、KubernetesにおけるAIインフラストラクチャの標準とベストプラクティスを確立することを目指しています。その目標には、APIの作成、コラボレーションの促進、AI固有のゲートウェイ拡張機能の拡張性の確保が含まれます。現在進行中の提案では、セキュリティと最適化のためのペイロード処理、およびEgress Gatewayの定義が扱われています。これらの提案は、安全な外部AIサービス統合と高度なトラフィック管理を可能にします。グループは、プラットフォームオペレーター、開発者、およびコンプライアンスエンジニアのニーズに対応します。ワーキンググループは、KubeCon + CloudNativeCon Europe 2026でその成果を発表する予定です。AI Gatewayワーキンググループは、Kubernetes内でのAI対応ゲートウェイ機能の将来を形作るために、様々な関係者からの貢献を歓迎します。興味のある方は、提案をレビューし、会議に参加し、議論に参加することができます。グループは、AIワークロードネットワーキングの標準を開発するために、オープンな貢献モデルの下で活動しています。
Kubernetesは強力ですが、ユーザーにとって多くの潜在的な落とし穴があります。よくある間違いとして、Podの仕様内でリソース要求と制限を無視することが挙げられます。これは、リソースの枯渇や過剰な占有につながる可能性があります。また、ヘルスチェック(liveness probe)とレディネスチェック(readiness probe)を過小評価することも問題です。これにより、応答のないサービスやユーザーへのサービス中断が発生する可能性があります。「kubectl logs」だけにログを頼ると、コンテナのライフサイクルによって重要な情報が失われる可能性があります。開発環境と本番環境を同一に扱うと、パフォーマンスの問題やセキュリティ脆弱性につながる可能性があります。不要なリソースを削除せずに放置すると、リソースを消費し、管理を複雑にします。基本的なことを理解せずに複雑なネットワークに飛び込むと、トラブルシューティングが困難になります。最後に、セキュリティとRBAC(Role-Based Access Control)を怠ると、クラスターが様々なリスクにさらされる可能性があります。これらの一般的なエラーは、ベストプラクティスを採用し、Kubernetesのコア機能を理解することで回避できます。著者は、間違いから学び、公式ドキュメントやコミュニティリソースを活用することを推奨しています。
ヘッドランプは、Kubernetesクラスターリソースの探索、管理、デバッグのためのオープンソースプラットフォームです。Karpenterは、新しいノードを効率的にプロビジョニングし、そのライフサイクルを管理するKubernetesの自動スケーリングプロジェクトです。新しいヘッドランププラグインが開発され、ヘッドランプUI内で直接Karpenterの操作をリアルタイムで可視化できるようになりました。このプラグインは、KarpenterリソースとコアKubernetesオブジェクト間の接続を視覚化します。リソース使用率、許可される中断、プロビジョニングレイテンシなどのライブメトリクスを表示します。ユーザーは保留中のポッドを検査し、Karpenterのスケーリング決定を理解することで、デバッグに役立ちます。このプラグインは、Karpenterリソースの安全なライブ編集のための検証機能付き設定エディターも提供します。クラスターがスケーリングするにつれて、NodeClaimなどのKarpenterリソースのリアルタイムビューを提供します。ダッシュボードは、保留中のポッドとそれらがスケジュールできない理由を強調します。このプラグインは、AWSおよびAzureのKarpenterプロバイダーでテストされており、プロバイダー固有の情報を提供します。テストされていないプロバイダーやフィードバックについては、問題を提出することが推奨されています。使用方法については、プラグインのREADMEファイルで確認できます。
CdXz5zHNQW_c7B4Nv7Eh7.png
Kubernetes の新しいアルファ機能は、変更ブロック追跡 (Changed Block Tracking) によってストレージエコシステムを強化します。このメカニズムにより、CSI ストレージドライバーは、PersistentVolume スナップショット内の変更されたブロックを効率的に特定できます。ブロックレベルで変更を追跡することで、バックアップ操作は大幅に高速化され、リソース効率も向上します。ボリューム全体をスキャンする代わりに、バックアップは変更されたデータのみに焦点を当てることができます。この改善は、Container Storage Interface (CSI) および Kubernetes ストレージサポートに統合されています。この機能は現在、ブロックボリュームに限定されており、ファイルボリュームはサポートされていません。従来のバックアップ方法は、長いバックアップウィンドウ、高いリソース使用率、および冗長なデータによるストレージコストの増加といった課題に直面しています。変更ブロック追跡 API は、CSI インターフェースを介した増分バックアップのためのネイティブ Kubernetes サポートを提供します。主要なコンポーネントには、CSI SnapshotMetadata Service API、Kubernetes CustomResourceDefinition、および External Snapshot Metadata Sidecar が含まれます。ストレージプロバイダーは、特定の CSI RPC を実装し、ブロック変更を追跡するためのバックエンド機能を持っている必要があります。バックアップソリューションは、認証を処理し、ストリーミングクライアントコードを実装し、この新しいメタデータを活用するためにワークフローを最適化する必要があります。この機能を使用するには、CSI ドライバーがスナップショットとメタデータ機能をサポートしており、SnapshotMetadataService カスタムリソースが登録されていることを確認してください。API は、ブロックを特定するために GetMetadataAllocated および GetMetadataDelta 関数を提供します。今後の計画としては、フィードバックと採用状況に基づいて、この実装をベータ版に移行することが含まれています。
Kubernetes v1.34 では、重要な改善点として、ボリューム拡張の失敗からの自動復旧が導入されました。以前は、誤ったストレージサイズを指定するなど、拡張エラーを修正するには、手動での介入とクラスター管理者権限が必要でした。この新機能により、拡張が完了していない限り、ユーザーは要求された PVC サイズを小さくすることができます。Kubernetes はその後、サイズを自動的に修正し、消費されたクォータを返却し、PersistentVolume のサイズを変更します。例では、ユーザーがストレージ要求のタイプミスを修正する方法が示されています。修正後のサイズは、ボリュームの縮小はサポートされていないため、元のボリュームサイズよりも大きくする必要があります。この実装には、ボリューム拡張の完全な見直しが含まれており、拡張の進捗状況を監視するための新しい API フィールドが導入されました。エラー処理とレポート機能が改善され、エラーは PVC 条件として永続化され、失敗した拡張はより低いレートで再試行されます。この機能は、サイズ変更ワークフローにおける長年のバグにも対応しています。ユーザーは、発生した問題について報告することが推奨されています。この機能の開発は、様々な個人や Kubernetes コミュニティからのフィードバックと貢献によって実現しました。
Kubernetes の「動的リソース割り当て (DRA)」は、Pod のデバイスのような希少なリソースを管理し、単純なデバイス割り当てを超えて機能します。DRA は、リソース共有を含む、カスタム設定を持つ特定のデバイスのリクエストを可能にします。このブログでは、よりきめ細かいデバイス共有に不可欠な、Kubernetes 1.34 の新しい「消費可能なキャパシティ」機能を詳しく説明します。消費可能なキャパシティは、複数の ResourceClaim または DeviceRequest 間で、さらには名前空間を跨いでデバイスを共有することを可能にします。スケジューラーは、デバイスリソースの一部を割り当て、全体的なキャパシティを管理するようになりました。新しい DistinctAttribute 制約は、単一のデバイスが同じ Claim 内で複数回割り当てられるのを防ぎます。この機能を使用するには、さまざまな Kubernetes コンポーネントで DRAConsumableCapacity 機能ゲートを有効にする必要があります。開発者は、AllowMultipleAllocations を設定することで複数の割り当てを許可でき、デバイスキャパシティリクエストのポリシーを定義できます。ユーザーは ResourceClaim を介してデバイスの一部をリクエストでき、デバイスステータスには IP アドレスなどの動的な情報を含めることができます。この機能強化は、帯域幅を意識したネットワーキングとマルチテナントデバイス共有をサポートし、スケジューリングとリソース制御を改善します。このブログは、DRA をさらに洗練させるための実験とフィードバックを推奨しています。
Kubernetes v1.34 では、Pod で使用される GPU のような特殊なハードウェアの健全性に関する洞察を提供するアルファ機能が導入されました。KEP-4680 に基づいて構築されたこの新しい機能は、動的リソース割り当て (DRA) ドライバーを拡張します。デバイスの健全性ステータスは、DRA を介して Pod のステータスフィールドに直接報告されるようになりました。デバイスの健全性を公開することで、ユーザーはステートフルアプリケーションや長時間実行されるジョブの問題を迅速に診断できます。これにより、オペレーターや開発者は、基盤となるハードウェア障害を特定できます。これは、dra-health API グループで定義された新しい gRPC ヘルスサービスを通じて行われます。Kubelet は DRA ドライバーと統合され、ヘルスアップデートをキャッシュに保存します。デバイスの健全性が変化すると Pod のステータスが更新され、allocatedResourcesStatus フィールドに反映されます。これにより、ユーザーは kubectl を使用して Pod のステータスを検査することで、ハードウェア障害を特定できます。この機能を使用するには、ResourceHealthStatus フィーチャーゲートを有効にする必要があります。計画されている機能強化には、詳細なヘルスメッセージと設定可能なタイムアウトが含まれます。Kubernetes コミュニティは、ハードウェア障害の処理を改善することを目指しており、ユーザーからのフィードバックを歓迎します。
Kubernetes は、ボリュームグループスナップショットを Alpha 機能として導入し、Beta を経て、現在は2回目の Beta リリースに至りました。この機能は、拡張 API を介して、ボリュームのグループに対してクラッシュ整合性のあるスナップショットを提供します。Kubernetes は、スナップショット作成のためにラベルセレクターを使用して PersistentVolumeClaims をグループ化し、スナップショットからのワークロード復旧を目指しています。この機能は、実装に CSI ボリュームドライバに依存しています。最近の Beta 2 リリースでは、CSI ドライバが ListSnapshots RPC 呼び出しを欠いている場合の restoreSize フィールドに関する問題が解決されました。v1beta2 API では、詳細なスナップショット情報のために VolumeSnapshotInfo 構造体と VolumeSnapshotInfoList が導入されました。既存の v1beta1 オブジェクトは、変換 Webhook を使用して v1beta2 に変換されます。このプロジェクトは、コミュニティからのフィードバックと採用状況に基づいて、General Availability (GA) を目指しています。設計仕様、コードリポジトリ、CSI ドキュメントなど、さらに学習するためのリソースが提供されています。コミュニティは、Kubernetes Storage SIG および Data Protection Working Group への新しい貢献者を歓迎しています。
Kubernetes ユーザーにとって、cgroup ドライバーの設定は歴史的に複雑な問題でした。Linux システムには、cgroupfs と systemd の 2 つの cgroup ドライバーがあります。以前は、kubelet と containerd や CRI-O などの CRI 実装の両方を同じように設定する必要があり、明確なエラーメッセージなしに kubelet の誤動作を避ける必要がありました。これは、クラスター管理者に大きなフラストレーションを引き起こすことがよくありました。Kubernetes v1.28.0 では、KubeletCgroupDriverFromCRI 機能ゲートが導入されました。これにより、kubelet は CRI 実装に好みの cgroup ドライバーを照会できるようになりました。数回のリリースサイクルを経て、この機能は Kubernetes 1.34.0 で一般提供 (GA) に達しました。これを利用するには、管理者は CRI 実装が十分に更新されていることを確認する必要があります。Containerd はバージョン v2.0.0 以降が必要ですが、CRI-O はバージョン v1.28.0 以降が必要です。Kubernetes は containerd v1.y バージョンのサポートを非推奨にしています。CRI-O のリリースは Kubernetes のバージョンと一致しますが、containerd には独自のリリースサイクルがあり、その機能サポートは v2.0 以降にのみ存在します。Kubernetes 1.34 は、v1.7 のような古い containerd LTS リリースも引き続きサポートしています。Kubernetes SIG Node コミュニティは、containerd v1.y サポートの段階的な廃止のタイムラインを設定しました。このサポートが含まれる最後の Kubernetes リリースは v1.35 の最終バージョンとなり、v1.36.0 でサポートが終了します。この移行を支援するために、kubelet_cri_losing_support というメトリックを監視できます。このメトリックが containerd バージョン 1.36.0 を示す場合、containerd ランタイムが今後の要件に対して古いことを示します。管理者は、kubelet を v1.36.0 にアップグレードする前または同時に、containerd を v2.0 以降にアップグレードする必要があります。
Kubernetes v1.34 では、CSI ドライバーがノード上のアタッチ可能なボリューム数を更新する機能がアルファ版からベータ版に移行しました。この機能は、ステートフル Pod のスケジューリングの精度を向上させることを目的としています。以前は、CSI ドライバーは静的なボリューム制限を報告していましたが、これは古くなる可能性がありました。情報が古くなる理由としては、外部ボリューム操作、ハードウェアによるスロットの消費、複数のドライバー間の相互作用などが挙げられます。この不正確さにより、Pod が起動に失敗し、ContainerCreating 状態でスタックしてしまう可能性がありました。新しい機能により、CSI ドライバーは実行時にノードのアタッチ容量を動的に報告できるようになります。Kubernetes は、定期的な更新とアタッチ失敗時の即時更新の 2 つの更新メカニズムをサポートするようになりました。このベータ版機能を有効にするには、kube-apiserver と kubelet で MutableCSINodeAllocatableCount フィーチャーゲートを有効にする必要があります。CSI ドライバーは、定期的な更新のために nodeAllocatableUpdatePeriodSeconds で設定でき、最小間隔が強制されます。即時更新は、ボリュームのアタッチ中に ResourceExhausted エラーによってトリガーされ、Pod が恒久的な障害に陥るのを防ぎます。ユーザーは、v1.34 でこの機能を有効にしてテストし、一般提供への移行に向けてフィードバックを提供することが推奨されています。
Kubernetes は従来、環境変数に ConfigMap と Secret を使用していましたが、これは複雑さを増し、余分な API 呼び出しを必要とします。 Pod とその設定を別々に管理することは、特に更新時に困難になる可能性があります。 これは、環境変数をハードコードしたり、ボリュームマウントを使用したりしたくないベンダーコンテナを扱う場合に特に当てはまります。EnvFiles と呼ばれる新しいアルファ機能は、これらのシナリオに対する代替ソリューションを提供します。 EnvFiles 機能ゲートが有効になっている場合、kubelet は、コンテナの環境変数を emptyDir ボリューム内のファイルから直接読み込むことができます。 これにより、ファイルをコンテナ自体にマウントする必要がなくなります。 コア機能は、Kubernetes がファイル (多くの場合、initContainer によって生成される) を解析し、起動時にメインコンテナの環境変数を設定できるようにします。ファイルは、Pod のライフサイクル中に持続する一時的なストレージである emptyDir ボリュームに存在します。 メインコンテナはこのボリュームをマウントする必要はありません。kubelet がファイルを読み取り、変数を注入します。 これらの変数を定義するには、Pod spec で fileKeyRef フィールドを使用し、ファイルパスと抽出するキーを指定します。ファイル形式は KEY=VALUE 構文をサポートしており、このアルファ段階では、emptyDir ボリュームに書き込む必要があります。 init コンテナはファイルを emptyDir ボリュームに書き込む必要がありますが、メインアプリケーションコンテナはボリュームにアクセスする必要はありません。 この機能は機密データを処理できますが、ファイルシステムへのアクセス権を持つノードオペレーターは、emptyDir ボリュームからこのデータを取得できる可能性があることに注意することが重要です。 したがって、機密情報を保存する際には、不正アクセスからノードを保護するために、堅牢なクラスタセキュリティポリシーが不可欠です。 この EnvFiles 機能は、複雑な回避策を減らすことで、アプリケーションの作成を簡素化し、新しいユースケースを可能にします。
Kubernetes は、リストリクエストの問題に対処することで、API サーバーの安定性とパフォーマンスを大幅に向上させました。大きな進歩は、v1.34 でベータ版となったスナップショット可能な API サーバーキャッシュであり、これにより、ほとんどの読み取りリクエストを API サーバーのメモリから直接処理できるようになりました。この機能は、v1.31 で導入された、ウォッチキャッシュからの整合性のある読み取りなどの以前の機能強化に基づいて構築されており、これにより、フィルタリングされたコレクションが etcd をバイパスできるようになりました。v1.33 では、大きなレスポンスを効率的に処理するために、アイテムを個別に送信し、メモリの急増を防ぐストリーミングエンコーダーが追加されました。スナップショット可能なキャッシュは、ページネーションによく使用される履歴 LIST リクエストもキャッシュから処理できるようにすることで、最後のギャップを埋めます。これは、更新ごとにキャッシュの状態の軽量でメモリ効率の高いスナップショットを作成することによって機能します。履歴リクエストが到着すると、API サーバーは関連するスナップショットを取得し、メモリから直接データを提供します。これらの機能の相乗効果により、API サーバーのメモリ負荷と etcd の負荷が劇的に軽減されます。その結果、Kubernetes コントロールプレーンは、より安定し、スケーラブルで、信頼性が高くなりました。SnapshottableCache 機能は Kubernetes v1.34 でデフォルトで有効になっており、これらの改善の恩恵を受けるためにユーザーによる操作は必要ありません。