Cloud

概要 KubernetesのSIG Networkは2026年3月20日、Ingressリソースから Gateway APIへの移行を支援するツール「Ingress2Gateway」のバージョン1.0を正式リリースした。Ingress-NGINXが2026年3月に廃止されることを受け、既存のIngress設定をGateway APIリソースへ自動変換するための公式ツールとして位置づけられている。以前のバージョンではわずか3つのアノテーションしかサポートしていなかったが、1.0では30以上のIngress-NGINXアノテーションに対応し、CORS設定、バックエンドTLS、正規表現パスマッチング、パスリライト、プロキシボディサイズ、タイムアウト設定、カスタムリクエストヘッダーなど幅広い構成の変換が可能になった。 Gateway APIへの移行が必要な背景 Gateway APIはIngress APIの後継として設計されたKubernetesのネットワーキングインターフェースであり、すでにGA（一般提供）に到達している。従来のIngressがアノテーションベースの拡張に依存していたのに対し、Gateway APIはモジュラーで拡張性の高いAPI設計、KubernetesネイティブのRBACサポート、より明確な抽象化を提供する。Ingress-NGINXの廃止により、Kubernetes上でトラフィック管理を行うすべての組織はGateway APIへの移行を迫られている状況だ。 技術的な特徴と移行プロセス Ingress2Gatewayはコマンドラインツールとして提供され、Go install、Homebrew、GitHubリリースからインストールできる。YAMLマニフェストファイルからの変換のほか、クラスターに接続して単一ネームスペースまたは全ネームスペースのIngressリソースを一括変換する機能を備える。さらに、出力先のGateway API実装としてagentgateway、envoy-gateway、kgatewayなどの実装固有のエミッターを指定可能だ。 1.0リリースの大きな特徴として、コントローラーレベルの統合テストが整備された点が挙げられる。このテストでは実際のIngress-NGINXコントローラーと複数のGateway APIコントローラーを起動し、変換前後のルーティングやリダイレクト、リライトといった実行時の振る舞いが同等であることを検証する。YAML構造の比較ではなくランタイムの動作を検証することで、Ingress-NGINXの予期しないデフォルト値やエッジケースを本番デプロイ前に検出できる仕組みとなっている。 移行における留意点と今後の展望 Ingress2Gatewayはワンショットの置換ツールではなく、反復的な移行プロセスを前提として設計されている。変換時には自動変換できない設定について明確な警告と代替手段の提案が出力されるため、チームはこれを確認しながら段階的に移行を進めることが推奨される。この移行プロセスは既存のアーキテクチャ判断を見直す機会でもあるという設計思想が反映されている。Kubernetes 1.36が2026年4月22日にリリース予定であり、Gateway APIの本格採用がさらに加速する見通しだ。本ツールはGoogle所属のBeka Modebadze氏とMicrosoft所属のSteven Jin氏が中心となって開発された。

概要 AWSは、Kubernetes Load Balancer ControllerにおけるGateway APIサポートのGA（一般提供）を発表した。これにより、Application Load Balancer（ALB）とNetwork Load Balancer（NLB）をGateway API仕様で管理できるようになり、従来のアノテーションベースの設定から型安全なCustom Resource Definitions（CRD）ベースの設定へと移行が可能になった。Gateway APIはKubernetes Ingress APIの後継として位置づけられており、今回のGA対応はAWSにおけるKubernetesネットワーキングの標準化にとって重要なマイルストーンとなる。 技術的な詳細 今回のリリースでは、レイヤー4ルーティング（TCP、UDP、TLS、NLB経由）とレイヤー7ルーティング（HTTP、gRPC、ALB経由）の両方がサポートされる。新たに導入されたCRDとして、TargetGroupConfiguration、LoadBalancerConfiguration、ListenerRuleConfigurationの3つがあり、スキーマバリデーション付きの型安全な設定が可能になった。従来のアノテーション方式ではJSONを埋め込む形で設定していたため、スキーマバリデーションやIDEサポートがなく、実行時にエラーが発覚するリスクがあった。新しいアプローチでは、適用時に設定が検証されるため、こうした問題が解消される。 RBACとの整合性とクロスネームスペースルーティング Gateway APIはリソースをGatewayClass（インフラストラクチャテンプレート）、Gateway（リスナー、TLS、サブネット配置）、Routes（パスベースルーティング）の3つに分離しており、Kubernetesのロールベースアクセス制御（RBAC）の境界と自然に対応する設計となっている。これにより、プラットフォームチームが共有Gatewayをプロビジョニングし、各アプリケーションチームは自身のネームスペースからHTTPRouteを作成して参照するという運用が、クラスタ管理者権限なしで実現できる。GitOpsフレンドリーなYAML設定との親和性も高く、開発者体験の向上にも寄与する。 今後の展望 なお、AWSのVPC Latticeはすでにサービスメッシュのeast-west（サービス間）トラフィックにおいてGateway APIをサポートしており、今回のリリースでnorth-south（イングレス）トラフィックのカバレッジが完成した形となる。これにより、AWS上のKubernetesネットワーキングはGateway APIを共通インターフェースとして統一的に管理できる基盤が整ったと言える。

概要 KubeCon Europe 2026にて、Kubernetes上でLLM推論を最適化する分散推論フレームワーク「llm-d」がCNCF Sandboxプロジェクトとして採択された。llm-dは2025年5月にRed Hat、Google Cloud、IBM Research、CoreWeave、NVIDIAによって立ち上げられたプロジェクトで、AMD、Cisco、Hugging Face、Intel、Lambda、Mistral AI、UCバークレー、シカゴ大学など幅広い企業・研究機関が支援している。KServeのような高レベルのコントロールプレーンとvLLMのような低レベルの推論エンジンの間を橋渡しし、ハードウェアベンダーに依存しない「あらゆるアクセラレータ上でのSoTA推論性能」の実現を目指している。 アーキテクチャと技術的特徴 llm-dの中核となる技術革新は「Disaggregated Serving（分離型サービング）」だ。LLM推論のprefill（入力処理）フェーズとdecode（トークン生成）フェーズを独立したスケーラブルなPodに分離することで、リソース配分とレイテンシ管理をきめ細かく制御できるようにしている。Red HatのAI CTO Brian Stevens氏は「分離によって入力処理とトークン生成を独立してスケールできるようになった」と説明している。 その他の主要な技術的特徴として、Kubernetes Gateway API Inference Extension（GAIE）を活用したプレフィックスキャッシュ対応ルーティング、LeaderWorkerSet（LWS）プリミティブによるマルチノードレプリカとエキスパート並列処理、GPU・TPU・CPU・ストレージを横断した階層的KVキャッシュオフロードが挙げられる。 ベンチマーク結果 マルチテナントSaaSシナリオにおいて、Qwen3-32Bモデルを16基のNVIDIA H100 GPUで実行した場合、llm-dはTime-to-First-Token（TTFT）レイテンシをほぼゼロに維持しながら約12万トークン/秒のスループットを達成し、高負荷時にベースラインのKubernetesサービスを大幅に上回るパフォーマンスを示した。 今後の展望 Red Hatのエンジニアリングディレクター Robert Shaw氏は、今後の優先事項としてマルチテナントモデルサービング、リクエスト優先順位付け、新しいアクセラレータへの対応、Kubernetes上のエージェントシステム向けセキュリティ強化を挙げている。また、CNCFのAI Conformanceプログラムとの連携を通じて、分離型サービング機能のエコシステム間相互運用性の確保と、推論性能測定のためのオープンなベンチマーク標準の策定も計画されている。Mistral AIもLeaderWorkerSet向けのDisaggregatedSetオペレータの開発にコミットしており、コミュニティ主導でのエンタープライズ推論基盤の標準化が進む見通しだ。

昇格の概要 CNCF（Cloud Native Computing Foundation）の技術監視委員会（TOC）は2026年3月24日、KubernetesネイティブのCI/CDフレームワーク「Tekton」をIncubatingプロジェクトとして正式に承認した。TektonはCD Foundation（CDF）で既に卒業プロジェクトとしての地位を確立しており、CNCFにはSandboxを経ずに直接Incubatingレベルで受け入れられた。これはプロジェクトの成熟度、安定性、そしてクラウドネイティブエコシステムにおける重要性が認められた結果である。TOCスポンサーのChad Beaudin氏は「TektonはKubernetesネイティブなデリバリーのためのコアインフラとしての実力を証明した。Incubatingへの移行は、強力なマルチベンダーガバナンスとCNCFプロジェクトとの深い連携を反映している」と評価している。 Tektonのアーキテクチャと主要コンポーネント TektonはKubernetes上で動作するCI/CDフレームワークであり、Steps、Tasks、Pipelinesという構成可能なプリミティブを通じて、マルチクラウドおよびオンプレミス環境でのビルド、テスト、デプロイを実現する。プロジェクトは複数のコンポーネントで構成されており、CI/CDワークフローの中核を担う「Pipelines」（コアはv1.0安定版に到達済み）、Gitプッシュやプルリクエストなどのイベントに基づいてパイプラインを起動する「Triggers」、コマンドラインインターフェースの「CLI」、Webベースの管理UIである「Dashboard」、そしてアーティファクトの署名・証明を行うサプライチェーンセキュリティツール「Chains」がある。 コミュニティの成長と採用実績 Tektonのコミュニティは着実に成長を遂げており、GitHub上で11,000以上のスター、5,000以上のプルリクエスト、2,500以上のIssue、そして600人以上のコントリビューターを擁する。企業採用も広がっており、Red Hat OpenShift PipelinesやIBM Cloud Continuous Deliveryといった商用製品の基盤として活用されているほか、Puppet社やFord Motor Companyなどの大手企業でも導入されている。さらに、CNCFプロジェクトであるShipwrightやRed Hatが主導するKonfluxといったプロジェクトの基盤としても機能しており、エコシステム内での存在感を高めている。Argo CD（GitOps）、SPIFFE/SPIRE（アイデンティティ管理）、Sigstore（署名・検証）との統合も進んでいる。 今後のロードマップ Tektonの今後の開発では、サプライチェーンセキュリティの強化が重要な柱となる。SLSA Level 3をデフォルトで達成することを目指すほか、共有ストレージなしでタスク間のデータを安全に受け渡す「Trusted Artifacts」機能の開発が進められている。また、リモートのTask/Pipeline参照の構文改善、Kueueとの統合による高度なスケジューリング、長期的な履歴管理とクエリのためのResults APIの安定化、Artifact Hubを通じたCatalogの進化、そしてGitベースのワークフローを実現する「Pipelines as Code」の継続的な開発が予定されている。TOCスポンサーのJeremy Rickard氏は「Tektonのコンポーザブルな設計と幅広い採用は、クラウドネイティブワークフロー環境において重要な位置を占めている」と述べており、Incubating昇格によりエンタープライズ採用のさらなる加速が期待される。

概要 Googleは2026年3月、Kubernetes上でマルチプレイヤーゲームの専用サーバーをオーケストレーション・スケーリングするオープンソースプラットフォーム「Agones」を、Cloud Native Computing Foundation（CNCF）にSandboxレベルのプロジェクトとして寄贈した。これにより、Agonesはベンダー中立なコミュニティ主導のガバナンス体制へと移行し、Google以外のクラウド事業者やゲームスタジオからの参加拡大が期待される。 Agonesは2017年にGoogleとUbisoftの共同開発で誕生し、現在は250人以上のコントリビューターによって支えられている。プロジェクト創設者でリードメンテナーのMark Mandel氏は「マルチプレイヤーゲームサーバーのホスティングはかつて独自のプロプライエタリシステムに完全に依存していたが、オープンソースがゲームを変えた」と語り、CNCF移管の意義を強調した。 技術的な特徴 Agonesの最大の強みは、Kubernetesを拡張してゲームサーバーのライフサイクル管理を標準化する点にある。PC、コンソール、モバイルといったプラットフォームを問わず、一度ビルドしたサーバーバイナリを修正することなく、オンプレミスを含む主要なクラウドプロバイダーへシームレスにデプロイできる「Build Once, Deploy Everywhere」のアプローチを採用している。UbisoftのThomas Lacroix氏も、このクラウドアグノスティックな設計により、ゲームサーバーバイナリを変更せずにあらゆるクラウドで一貫して専用サーバーを稼働できる点を評価している。 また、単一のサーバープロセスで複数のゲームセッションを安全にホストする機能や、再利用可能なゲームサーバーパターンによる効率化、共通APIによるサーバー管理の簡素化といった機能を備えており、大規模なマルチプレイヤーゲームの運用コスト削減に貢献する。 今後の展望 CNCFへの移管は、マルチプレイヤーゲームインフラのオープンスタンダード化を推進する重要な一歩となる。これまでゲーム業界ではプロプライエタリなインフラが主流だったが、Agonesがベンダー中立な基盤として広く採用されることで、業界全体のインフラ標準化が加速する可能性がある。2026年のKubeCon + CloudNativeCon Europe（アムステルダム）では、Mark Mandel氏とUbisoftのJean-François Hubert氏による基調講演が予定されており、Ubisoftにおけるオーケストレーション戦略が紹介される見込みだ。

概要 米上院議員のジョシュ・ホーリー（共和党）とエリザベス・ウォーレン（民主党）が、米エネルギー情報局（EIA）に対してデータセンターの電力消費に関する詳細情報の収集を求める書簡を送付した。党派を超えた両議員の共同書簡は、AI需要の急増に伴うデータセンターの電力消費が電力網に与える影響を正確に把握する必要性を訴えるものであり、議会によるデータセンターへの監視強化の動きが加速していることを示している。 要求の背景と目的 今回の書簡の背景には、AI演算の爆発的な増加がある。大規模言語モデルのトレーニングや推論処理には膨大な電力が必要とされ、従来の一般的なクラウドサービスとは比較にならない規模のエネルギーを消費する。両議員はEIAに対し、AI演算と一般クラウドサービスそれぞれの電力消費量の区別を含む、より詳細なデータの収集を求めている。これにより、データセンターが地域の電力網にどの程度の負荷をかけているかを正確に評価し、エネルギー政策の立案に役立てることが狙いだ。 議会の動向と今後の見通し 今回の動きは孤立した取り組みではなく、データセンターの電力消費に対する議会全体の監視が強まる中での一環と位置づけられる。TechCrunchの報道によれば、データセンターに対する議会の動きは「ますます活発なフロント」となっており、今後さらなる規制や情報開示の要求が続く可能性がある。保守派とリベラル派の議員が共同で行動している点は、この問題が党派を超えた関心事であることを示しており、実効性のある施策につながる可能性が高いと見られる。データセンター事業者にとっては、電力消費の透明性確保が今後の事業運営における重要な課題となりそうだ。

概要 Google Cloudは2026年3月28日、NVIDIA GTC 2026において、AIクラウドインフラストラクチャの大幅な強化を発表した。今回の発表は、GPUリソースの柔軟な利用を可能にする分数GPU VM、次世代ラックスケールシステムVera Rubin NVL72への対応、そしてNVIDIA DynamoとGoogle Kubernetes Engine（GKE）の統合という3つの柱で構成されている。単なるGPUの提供にとどまらず、AIインフラをクラウドスタック全体の課題として捉え、柔軟な消費モデルと深いソフトウェア統合を重視する姿勢が示された。 分数G4 VM：GPUの柔軟な分割利用 Google Cloudは、NVIDIA RTX PRO 6000 Blackwell Server Edition GPUを搭載した分数G4 VMのプレビューを発表した。NVIDIAの仮想GPU（vGPU）技術を活用し、GPUを1/2、1/4、1/8単位で分割して利用できる新しい構成を提供する。これにより、推論、レンダリング、リモートデスクトップ、ストリーミングなどのワークロードに対して、必要なリソースを過不足なく割り当てることが可能になる。 さらに、Dynamic Workload Schedulerと組み合わせることで、分数スライスのフォールバック優先度を設定でき、スケジューラが自動的に利用可能なGPU構成を見つけることで、リソースの取得可能性が大幅に向上する。AI推論のコスト効率化を求める企業にとって、フルGPUを占有せずに済む選択肢が広がる形だ。 Vera Rubin NVL72ラックスケールシステムへの対応 Google Cloudは、2026年後半にNVIDIA Vera Rubin NVL72ラックスケールシステムを提供する最初のクラウドプロバイダーの一つとなる計画を明らかにした。このシステムはAI Hypercomputerアーキテクチャに統合され、新たにA4 Ultraインスタンスファミリーとして提供される。 A4 Ultraは、1ラックあたり72基のVera Rubin GPUをNVLink 6で接続し、FP8精度で1.4エクサFLOPSの演算性能を実現する。NVLink 6はH100システムで使用されるNVLink 4と比較してリンクあたりの帯域幅が2倍となり、学習時の勾配同期の高速化やModel FLOP Utilization（MFU）の改善が期待される。プレビューは2026年第2四半期にus-central1およびeurope-west4リージョンで開始され、一般提供は2026年後半、さらなるリージョン拡大は2027年を見込む。 なお、Google CloudはNVL72をTPU v5e/v5pインフラと並行して提供する方針であり、CUDA対応のトレーニングワークロードにはNVL72を、JAX最適化された推論にはTPUをという形で、マルチアクセラレータ戦略を維持する。 NVIDIA DynamoとGKE Inference Gatewayの統合 ソフトウェア面では、NVIDIA DynamoとGKE Inference Gatewayの統合が発表された。これにより、アプリケーション層からハードウェアまでをカバーするモジュラーかつオープンソースのコントロールプレーンが提供される。Kubernetesベースの推論デプロイメントにおいて、GPUリソースの管理と推論ワークロードのオーケストレーションがより効率的に行えるようになる。 Google Cloudの今回の発表は、AWS、Microsoft Azure、OCIといった他の主要クラウドプロバイダーもVera Rubinベースのインスタンスを2026年中に展開する中で、柔軟性とソフトウェア統合の深さで差別化を図る戦略を鮮明にしたものと言える。

概要 2026年3月24日から26日にかけてアムステルダムで開催されたKubeCon + CloudNativeCon Europe 2026には、13,000人以上が参加した。誕生から12年を迎えたKubernetesは成熟期に入り、今年のカンファレンスではeBPFとmTLSによるネットワークセキュリティの強化、AI推論ワークロードへの対応、そしてBSD統合による実行環境の多様化が主要テーマとして浮上した。MicrosoftのBrendan Burns氏（Corporate Vice President兼Technical Fellow）は、AIインフラにおける課題が「動作するか壊れるか」から「良い結果か悪い結果か」へと根本的に変化していると指摘し、Kubernetesの運用成熟度を現代のワークロードに適用することの重要性を強調した。 サイドカーレスmTLSの実現：CiliumとeBPFの統合 今回のKubeConで最も注目を集めた技術トピックの一つが、Cilium v1.19以降で実現されたサイドカープロキシ不要のmTLS（相互TLS認証）である。従来のサービスメッシュではサイドカーコンテナが必要だったが、新しいアプローチではeBPF（Extended Berkeley Packet Filter）とIstioのztunnel（Rust実装のコンポーネント）を組み合わせ、各ノード上の軽量プロキシがTLS処理を担う「アンビエントモード」を採用している。設定はCilium Helm chartでztunnel機能を有効化し、ネームスペースにio.cilium/mtls-enabled=trueラベルを適用するだけの3ステップで完了する。この方式はノード単位ではなくセッション単位の認証を実現し、ハンドシェイク時のパケットロスも解消されている。 Microsoftはこの技術をAzure Kubernetes Service（AKS）にも統合し、「Azure Kubernetes Application Network」としてフルサービスメッシュのオーバーヘッドなしにmTLS、アプリケーション対応の認可、トラフィックテレメトリを提供する。さらにWireGuardによるノード間暗号化やCilium Cluster Meshによるクロスクラスタネットワーキングも発表された。 AI推論基盤とスケジューリングの進化 AI関連では、Dynamic Resource Allocation（DRA）がKubernetesで正式にGA（一般提供）となり、Kubernetes 1.36ではWorkload APIにDRAサポートが追加された。Microsoftは新たなオープンソースプロジェクト「AI Runway」を発表し、推論ワークロード向けのKubernetes APIとWebインターフェース、HuggingFace統合、GPUメモリ適合インジケーターを提供する。AKSにおいてもGPUメトリクスのPrometheus/Grafana統合や、自然言語によるネットワーク診断クエリ機能「Agentic Container Networking」が追加された。CNCFサンドボックスプロジェクトの「HolmesGPT」はエージェント型のトラブルシューティングツールとして紹介された。 BSD統合と新しいコンテナランタイム Kubernetesエコシステムの実行環境も多様化が進んでいる。CNCFメンバーであるProject Limaはバージョン2.1をリリースし、macOSに加えFreeBSDをゲストOSとしてサポートした（実験段階）。K3s、k0s、RKE2と互換性があり、コンテナに匹敵する軽量な仮想マシンを実現する。また、CNCFに約1年前に加入したProject uruncは、ユニカーネルコンセプトを採用した新しいコンテナランタイムで、BSDアプリケーションをLinuxコンテナ向けに移植することなく、隔離された環境で実行可能にする。 運用成熟度の向上と今後の展望 AKSでは運用面の改善も多数発表された。ブルーグリーン方式のエージェントプールアップグレード、エージェントプールのロールバック機能（フル再構築なしに前バージョンへ復帰可能）、プリロード済みコンテナと設定を含むカスタムノードイメージ仕様「Prepared Image Specification」、そしてローカル開発環境「AKS Desktop」のGA化などが含まれる。一方で、ヨーロッパの参加者にとって重要なデータ主権の問題については議論が限定的だったとの指摘もあり、今後のカンファレンスでの課題として残された。次回のKubeCon Europeは2027年にバルセロナ、2028年にベルリンで開催される予定である。

概要 米国サイバーセキュリティ・インフラストラクチャセキュリティ庁（CISA）は2026年3月3日、BroadcomのVMware Aria Operationsに存在するコマンドインジェクション脆弱性（CVE-2026-22719）を、既知の悪用された脆弱性（KEV）カタログに追加した。この脆弱性はCVSSスコア8.1と高い深刻度に分類されており、未認証の攻撃者がサポート支援による製品マイグレーション処理中に任意のコマンドを実行できるというものだ。野外での積極的な悪用が確認されており、連邦文民行政機関（FCEB）には2026年3月24日までにパッチを適用することが義務付けられた。 影響を受ける製品と修正バージョン 影響を受ける製品は、VMware Aria Operations 8.x系、VMware Cloud Foundation 9.x系、およびVMware vSphere Foundation 9.x系の3製品である。それぞれ、Aria Operations 8.18.6、Cloud Foundation 9.0.2.0、vSphere Foundation 9.0.2.0で修正されている。Broadcomは2026年2月下旬にアドバイザリをリリースしており、同時にストアド型クロスサイトスクリプティング脆弱性（CVE-2026-22720）と管理者権限への特権昇格脆弱性（CVE-2026-22721）も修正している。 緩和策と今後の対応 Broadcomは悪用報告について「独自に確認することはできない」としつつも、野外での悪用の可能性を認識していると述べている。即座にパッチを適用できない環境向けには、各Aria Operations仮想アプライアンスノード上でroot権限で実行する回避策シェルスクリプト（aria-ops-rce-workaround.sh）が提供されている。未認証でリモートからコード実行が可能という脆弱性の性質上、該当製品を使用する組織は早急な対応が求められる。