あらゆるチームに向けて設計された、Kubernetes向けのクラウドネイティブなトラフィック制御とセキュリティ

Karthik Krishnaswamyプロダクトマーケティング担当ディレクター | F5

Buu Lamコミュニティエバンジェリズム担当ディレクター

Kubernetesは、もはやアーリーアダプター向けの実験的なサンドボックスではありません。現代の企業のオペレーティングシステムです。約2,000万人のクラウドネイティブ開発者が世界中でKubernetesを基盤に開発しています。世界中の組織の90%超がコンテナ化されたアプリケーションを2027年までに本番環境で実行すると予測されています。また、生成AIを導入している組織の3分の2は、すでにKubernetes上で推論ワークロードを実行しています。コンテナオーケストレーションは、今やまさにミッションクリティカルな役割を担っています。

しかし、厳しい現実があります。本番環境でKubernetesを運用する組織のうち、わずか38%の組織しかエンタープライズレベルの成熟度に達していません。これは、The State of Enterprise Kubernetes Strategy 2026で示された結果です。同レポートは、F5がスポンサーを務めたSlashDataの調査に基づいています。約半数の51%は「確立済み」の段階にあるものの、ガバナンス、オブザーバビリティ、レジリエンス、またはソフトウェアサプライチェーンに重大な課題を抱えたままです。残る11%は、まだ標準化を進めている段階です。

企業が必要とするエンタープライズグレードのKubernetes成熟度に到達できるよう、F5 Application Delivery and Security Platform (ADSP)は統一されたアーキテクチャを提供します。外部ロードバランサーとクラスター内のIngressの運用上の分断を解消し、脆弱なマルチベンダーのツールチェーンを、一貫性のあるエンタープライズグレードのアーキテクチャに置き換えます。

チームをつなぐ共通基盤

Kubernetesは、その役割を非常に優れた形で果たします。ワークロードのスケジューリング、コンピューティングリソースの柔軟なスケーリング、障害が発生したPodの自己修復に加え、ハイブリッド環境やマルチクラウド環境全体で基盤となるハードウェアを抽象化します。しかし、コンテナのオーケストレーションは、必要な取り組みの半分にすぎません。もう半分は、トラフィックの制御とセキュリティの確保です。

Kubernetesは、分散したエンタープライズ環境全体でアプリケーションとAIのトラフィックの動作を制御するようには、そもそも設計されていません。グローバルなネットワーク状況に基づくリアルタイムのルーティング判断、イングレスとエグレスの経路全体でのエンタープライズセキュリティポリシーの一貫した適用、大規模環境でのマルチテナント間の厳密なトラフィック分離の保証は行いません。

さらに問題を難しくしているのは、Kubernetesのトラフィックとセキュリティを単一の役割の担当者が担っているわけではないことです。GitOpsを通じてマイクロサービスを公開するプラットフォームエンジニア、複数クラスターにわたるボーダーゲートウェイプロトコル（BGP）ピアリングとDPUオフロードを管理するネットワークアーキテクト、AIを活用したゼロデイ脆弱性の悪用から組織を守るCISOでは、運用上の要件が根本的に異なります。

すべての関係者に単一の画一的なツールを使わせる方法は、必ず失敗します。開発者には負担が大きすぎるか、エンタープライズのインフラチームには機能が不十分になるためです。F5 ADSPは異なるアプローチを採用し、各担当者が実際にトラフィックを制御し、セキュリティを確保する方法に合わせた、目的特化型のクラウドネイティブソリューションを提供します。これらすべてを支える共通基盤が、誰にも妥協を強いることなく、チーム間の連携を実現します。

チームごとに異なるトラフィックとセキュリティの優先事項

Kubernetesの規模が拡大するにつれ、特に組織がステートレスなWebアプリからステートフルで高スループットのAIワークロードへ移行する中で、4つの異なるペルソナが浮かび上がり、それぞれが大きく異なる課題を抱えています。

• プラットフォームとDevOpsのリーダーは、スピード、セルフサービス、KubernetesネイティブのYAMLワークフローを重視します。しかし、最近廃止されたコミュニティのingress-nginxプロジェクトのような無料のコミュニティ製コントローラーから始めた結果、数十もの本番クラスターでサポートのないソフトウェアを保守することになり、エンジニアの人的リソースを運用上のトイルに費やしてしまうケースが後を絶ちません。
• NetOpsとインフラストラクチャの責任者は、効率的なルーティング、大容量のTLSオフロード、厳格なマルチテナント分離、エンドツーエンドの可視性を求めています。トラフィックがクラスターに入ると、ネットワークチームは内部の状況を把握できなくなることが多く、障害がネットワークとPodのどちらに起因するのかを突き止めるために、関係者が4時間にわたり対応に追われる事態につながります。
• AIインフラの責任者はGPUクラスターに数百万規模の投資を行っていますが、十分に活用されていないケースが少なくありません。これはコンピューティング能力が不足しているからではなく、トークンの効率的な入出力、モデル間でのインテリジェントなリクエストルーティング、マルチテナント環境でのGPUトラフィックの分離がボトルネックになっているためです。
• CISOとSecOps責任者は、一時的なクラスター全体にわたる定量化できないリスクへの露出、Webアプリケーションファイアウォール（WAF）とAPIセキュリティのポリシーの不整合、そして今日の脆弱性が悪用される速さを懸念しています。

DevOpsにNetOpsのような考え方を求めたり、NetOpsにアプリケーションのYAMLの管理を求めたりするのではなく、F5は各チームに適したクラウドネイティブのデータプレーンとコントロールプレーンを提供します。

DevOpsチームとプラットフォームチーム向け：軽量でKubernetesネイティブな俊敏性

プラットフォームエンジニアや開発者が求めているのは、Kubernetes内でネイティブに動作し、CI/CDやGitOpsのパイプラインにシームレスに統合できる、軽量で迅速な開発を支えるソリューションです。その役割をまさに担うのが、F5 Ingress Controller for NGINXとF5 Gateway Fabric for NGINXです。どちらもF5 ADSPの一部です。

数百万のクラウドネイティブ環境への導入で信頼を得ているF5 NGINXは、クラスター内のアプリケーションとAPIのトラフィック管理を標準化するための自然な選択肢です。Kubernetes Ingressリソースを使用する場合も、AIワークロード向けのGateway API Inference Extensionを含む最新のKubernetes Gateway API標準を使用する場合も、F5のNGINXソリューションは超高速で開発者にとって使いやすい実行環境を提供します。

リソース効率の面では、競合するプロキシは、長いコンテキストのAIプロンプトやストリーミングペイロードを処理する際にメモリ使用量が急増します。一方、F5 Gateway Fabric for NGINXは、ペイロードのサイズにかかわらず、メモリ使用量を一定に保ち、予測可能にします。

提供を終了したコミュニティのingress-nginxプロジェクトから移行する組織に向けて、F5はエンタープライズサポートとSLAを備えた移行先を提供します。設定の自動変換により、移行の負担を軽減できます。

また、セキュリティは後付けではありません。チームは、F5 WAF製品、APIセキュリティ、認証（OIDC、JWT）、レート制限、AIのプロンプトと応答に対するリアルタイムのガードレールをKubernetesマニフェストに直接組み込むことで、コードの変更と同じスピードでアプリとLLMのトラフィックを保護できます。

インフラストラクチャおよびAIアーキテクト向け：マルチクラスターの分離とエグレス

軽量なクラスター内プロキシはアプリケーションチームに最適ですが、大規模なエンタープライズ環境、通信事業者、AIファクトリーには、キャリアグレードのスケール、厳格なテナント分離、双方向のトラフィック制御が必要です。そこで活躍するのがF5 BIG-IP Next for Kubernetesです。

BIG-IP Next for Kubernetesは、F5のコンテナネイティブなTraffic Management Microkernel (TMM)を基盤とし、標準のワーカーノード上での実行、またはNVIDIA BlueField-3 DPUへのオフロードに対応するよう設計されています。インフラストラクチャレベルのトラフィック制御とセキュリティをKubernetesに直接提供します。

ほとんどのKubernetesツールは、イングレスのみに重点を置いています。BIG-IP Next for Kubernetesは、イングレスとエグレスの両方のトラフィックを制御し、保護します。マイクロサービスやAIエージェントが外部API、上流のデータベース、Model Context Protocol（MCP）サーバー、クラスター間サービスにアクセスする中、管理されていないエグレスは、データ流出対策における大きな盲点となります。BIG-IP Next for Kubernetesは、決定論的なエグレスルーティング、SNAT、名前空間ベースのファイアウォール制御、ゼロトラストのマイクロセグメンテーションを適用します。

マルチクラスター環境やマルチテナント環境では、BIG-IP Next for KubernetesがBGPを介してコアネットワークと直接ピアリングし、DPU上でL4～L7のトラフィック管理、mTLS暗号処理のオフロード、プレフィックスを考慮したトークンルーティングを高速化します。これにより、テナント間の厳格な分離、ホストCPUの負荷軽減、GPU使用率の最大化を実現します。

NetOpsチームとプラットフォームチームの連携を促進

では、NetOpsが境界でF5 BIG-IPを管理し、ハードウェアレベルのDDoS緩和、グローバル トラフィック管理、コンプライアンスに対応する一方で、プラットフォームチームがクラスター内でF5 Gateway Fabric for NGINXまたはF5 Ingress Controller for NGINXを運用すると、どうなるでしょうか。

F5 BIG-IP Container Ingress Services (CIS)が両チームのワークフローを自動的に連携させます。

BIG-IP CISは、自動化されたKubernetesネイティブのコネクターとして、Ingress、Gateway API、Routes、F5 IngressLink/GatewayLinkリソースを含むKubernetesおよびOpenShiftのAPIを監視し、外部のBIG-IPシステムをリアルタイムで動的に構成します。

開発者はKubernetes内で作業を続け、標準のYAMLでクラスター内のトラフィックルーティング、TLS、L7ポリシーを定義します。NetOpsは境界のガバナンスを維持し、CISがクラスターの変更を自動的に検出して、外部のBIG-IP上の仮想サーバー、プールメンバー、マルチクラスターDNS/GTMを更新するため、手動でチケットを発行する必要はありません。両チームはそれぞれの担当領域の管理責任を維持しながら、境界のVIPからポッドまでのエンドツーエンドのテレメトリを共有できます。また、ニーズの変化に応じてBIG-IP Next for Kubernetesへアップグレードする道筋も用意されています。

SecOpsとCISO向け：オープンソース版とエンタープライズ版のセキュリティを強化したリリース

それぞれの役割に適したトラフィックアーキテクチャを提供することは不可欠ですが、データプレーンソフトウェアには、AIによって加速する脅威の状況に耐えることも求められます。

数字を見てみましょう。2018年には、防御側に平均771日の猶予がありました。これは、CVEの公開からエクスプロイトが攻撃に利用できる形になるまでの期間です。現在では、攻撃用のAIエージェントは数分以内に脆弱性を攻撃に利用できる形にできますが、一般的な企業では依然として数週間かけてパッチを適用しています。公開オープンソースリポジトリでは、セキュリティに関するすべてのコミットが、事実上、攻撃者にとっての道しるべとなります。AIツールはコードの差分を解析し、下流のディストリビューションがパッケージを再ビルドする何週間も前にエクスプロイトを生成できます。

F5は、セキュリティを強化したリリースを提供することで、お客さまが安心して製品をリリースできるようにし、商用製品のお客さまとオープンソースコミュニティの両方を保護します。F5は、BIG-IP、BIG_IP Next for Kubernetes、NGINXのコードベース全体で社内のAIセキュリティ検証基盤を継続的に実行し、脆弱性を先回りして発見、修正しています。

セキュリティを強化した非公開リリースは、NGINX Enterprise、BIG-IP、BIG-IP Next for Kubernetesの商用のお客さまに、機能変更やAPIの非推奨化を一切含まない、必要な箇所に絞ったセキュリティ更新として提供されます。その後、企業のインフラに安全にパッチを適用するための先行期間を設けたうえで、約6週間後にF5がセキュリティ通知を公開し、同時にNGINX Open Source向けのCVEの詳細とパッチを公開します。

すべての要素を統合：マルチテナント型GPU-as-a-serviceプラットフォームの拡張

これらの要素が実際にどのように連携するのか、アジア太平洋地域で電子商取引と物流をリードする大手企業の最近の導入事例を見てみましょう。

同社は長年にわたり大規模な社内AIワークロードを実行してきた経験を経て、NVIDIA DGXシステムを基盤とする大規模なオンプレミスのKubernetesクラスター上に、商用GPU-as-a-Service（GPUaaS）クラウドを立ち上げる取り組みを開始しました。社内クラスターをマルチテナントのクラウドに転換するにあたり、直ちに対処すべき3つの課題が生じました。

第1に、外部の企業テナントが、テナント間でトラフィックが漏れることなく、共有クラスターに同時にアクセスできる必要がありました。第2に、プラットフォームチームには、ネットワーク関連のチケットを手動で起票することなく、100を超えるノード全体でクラウドネイティブのL7ルーティング、TLS終端、名前空間の分離を実現する必要がありました。そして第3に、コミュニティのオープンソースコントローラーには、商用SLAを支えるために必要な堅牢なトラフィック管理機能と24時間365日のサポートが不足していました。

同社は、100のKubernetesノードにわたり、F5 BIG-IP rSeries LTM、BIG-IP CIS、F5 Ingress Controller for NGINXを組み合わせた2層のKubernetesトラフィックアーキテクチャを導入しました。エッジでは、BIG-IP rSeriesアプライアンスが高スループットのL4負荷分散を提供するとともに、専用のvCPU、メモリ、ルーティングパーティションによって仮想ロードバランサーを厳密に分離し、各テナントのドメインを分離された仮想IPに1対1でマッピングします。

BIG-IP CISはF5 IngressLinkを使用してKubernetes APIを監視し、手作業でのチケット発行なしで、外部のBIG-IP仮想サーバーをクラスター内のNGINX Podに自動的に接続します。クラスター内では、テナント専用のNGINX Ingress Controller PodがTLSを終端し、復号を行い、L7ルーティングと認証を適用して、各テナントの分離された名前空間とGPUリソースにトラフィックを振り分けます。

同社は、エッジではNetOpsにBIG-IPによるハードウェア分離を、クラスター内ではプラットフォームエンジニアにクラウドネイティブなNGINXの俊敏性を提供し、両者をBIG-IP CISで接続することで、予定どおりにGPUaaSプラットフォームを立ち上げました。同時に、AIファクトリーの拡大に伴うBIG-IP Next for Kubernetesへの移行に向けた道筋も整えました。

チームの働き方に合わせたトラフィック制御とセキュリティ

『エンタープライズKubernetes戦略の現状2026』によると、企業の24%は、たった1つの不足によってKubernetesの成熟度向上を阻まれています。その多くは、オブザーバビリティまたはアドミッションコントロールの不足です。「確立済み」と「エンタープライズグレード」の差は、プラットフォームの問題ではありません。トラフィック制御、セキュリティ、チーム間の連携の問題です。

F5は、あらゆる役割の担当者が抱えるそのギャップを解消します。エンタープライズサポートを備えた移行パスで、提供が終了したコミュニティ版ingress-nginxから移行できます。BIG-IP CISで、NetOpsとプラットフォームのワークフローを自動的に連携できます。BIG-IP Next for Kubernetesで、マルチテナントAIクラスターのイングレスとエグレスのトラフィックを管理できます。さらに、CVEの一般公開より数週間早く提供されるセキュリティ専用リリースで、全体のセキュリティを強化できます。F5 ADSPは、さまざまなチームのニーズに応える統合アーキテクチャにより、企業がKubernetesを大規模かつセキュアで効率的に運用するために必要なKubernetes運用の成熟度を実現します。

さらに詳しく知りたい方は、11 月 9～12 日にソルトレイクシティで開催されるKubeConのF5ブース#100にお越しください。エンジニアに直接相談してKubernetesネットワーキングのボトルネック解消に取り組み、インタラクティブなデモを体験し、実践的な説明を聞きながら、Kubernetesのボトルネック解消に取り組めます。

ブログ記事「大半の企業がエンタープライズレベルのセキュリティを実現できていない理由」をご覧ください。

ウェビナー「エンタープライズグレードのKubernetes戦略を他と分けるもの」にもぜひご登録ください。

著者について

Karthik Krishnaswamyプロダクトマーケティング担当ディレクター | F5

Karthik Krishnaswamyのその他のブログ記事

Buu Lamコミュニティエバンジェリズム担当ディレクター

Buu Lamのその他のブログ記事