Service Proxy for Kubernetesで通信事業会社の5Gネットワークアーキテクチャを強化する

2018年の初め、私はネットワーキングや新たな5G標準の専門家である友人や同僚と、同じような会話を続けていました。私たちは皆、わからないことだらけの移行へと押し進んでいることに、漠然とした不安を抱いていました。5Gによりコンテナとクラウドネイティブアーキテクチャへの移行が進むことは理解していましたが、Kubernetesやその他のクラウドネイティブ ツールが、もともとは全く異なるユース ケースを想定して作成されたものであることも知っていました。私たち全員が（そしておそらくこの記事を読んでいる多くの人も）目にしたのは、私たちの業界が、胸焼けのするような、衝突への道を進んでいるということでした。

その不安な日々以降、通信サービスプロバイダ（CSP）はクラウドネイティブ インフラストラクチャへの移行を本格的に始めています。これらの導入の初期パイオニアは、当初設計されたKubernetesネットワーキングの重要な領域では、サービス プロバイダのユースケースの要求を満たすことができないという、想定外の障壁を実際に発見しています。通信事業会社の目標が5Gスタンドアロン（SA）コア導入への移行であれ、分散型クラウドアーキテクチャによるモダナイゼーション構想の一部であれ、ネットワークの相互運用性、キャリアグレードのスケール、キャリアのセキュリティ ポリシーをサポートするためにKubernetesを適応させることは、クラウドネイティブ インフラストラクチャ全体で必要とされる重要な機能となっています。

Kubernetesはその後、主にパブリック クラウドやエンタープライズ環境で実行されるWebやITのユース ケースに焦点を当てて進化してきたため、サービスプロバイダのユース ケースを展開するための独自の要件と、プロトコルのセットが計画されなかったことは理解できます。しかし、幸いなことに、Kubernetesのアーキテクトは、Kubernetesを拡張可能にする強固な一連の設計パターンを導入し、ネットワークトラフィック管理、可視性と制御、そしてHTTP/2、GTP、SIP、Diameterプロトコルなどの拡張プロトコル サポートといった、通信事業会社の基本的なユース ケースを実現する道を切り開きました。

Kubernetesを今日のサービスプロバイダのユース ケースに適合させるために必要な拡張について説明する前に、まずはサービス プロバイダ ネットワーク固有の要件を確認してみましょう。

Kubernetesは、より大きなエコシステムの中に組み込まなければならない

まず、Kubernetesクラスタは、より幅広いサービス プロバイダのネットワークや運用と統合する必要があります。アーキテクチャの決定は、運用コストと複雑さが増加するという点で、長期的に影響を及ぼす可能性があります。ネットワーク アーキテクトは、複数の通信事業会社のユース ケース、レガシー プロトコルのサポート、およびKubernetes内の動的な変更が既存のネットワーク トポロジにどのように影響するか（複雑さの増加につながる可能性）を考慮する必要があります。

2つ目に、通信事業会社のワークロード（ネットワーク機能）は、ITワークロードとは異なります。サービス プロバイダのネットワークとそのネットワーク機能では、標準的なHTTP/HTTPSやTCP以上のものを利用します。モバイル プロバイダにとって、SIP、GTP、SCTPなどのレガシー3G/4Gプロトコルと5G HTTP2の両方に対するネットワーク サポートが不可欠になります。通信事業会社のワークロードでは、ITワークロードと比較して、従来のネットワーク レイヤの上にさらに標準レイヤを追加する必要があります。

最後に、新しい自動化、可視化、および管理機能を必要とするすべての新しい露出ポイントに対して、セキュリティが最も重要であることは間違いないでしょう。セキュリティはすべてのレイヤに導入され、新しいテクノロジを導入する際には新しいクラスタと連携する必要があります。サービス プロバイダのSecOpsチームは、攻撃対象領域を減らし、一貫したセキュリティ管理を行う方法を常に模索しています。さらに、ネットワークの広範なセキュリティ ポリシーは、時間の経過とともに更新され、適応できなければなりません。

これらの機能ギャップに対応するための2つの最新アプローチ

Kubernetesのパターンを回避する

クラウドネイティブのパターンを回避するということは、アーキテクトが必要に迫られて対応手段を考案せざるを得なくなることを示します。なぜなら、Kubernetesが通信事業会社のワークロードを処理するためのツールをネイティブで備えていないからです。私たちは、通信事業会社がパターンを破っている次のような厄介な方法をいくつか確認しています。

• Kubernetesのネットワーキングを回避する – CNFの大部分は、Kubernetesの制御範囲外に1つ以上のインターフェイスを配置しています。これらのCNFは、直接的なネットワーク アクセスを必要とします（しばしば、外部への直接的な追加のインターフェイスを許可するための「multus」の要求として提出されます）。ネットワーク制御を一元管理できなければ、内部のKubernetesの複雑性が外部のサービス プロバイダのネットワークに露呈することになり、運用の複雑性とコストの増加、セキュリティ攻撃対象の拡大を招くことになります。また、あらゆるアプリケーション/ネットワーク機能の開発者とネットワーク事業者に対して、IPアドレスの管理だけでなく、外部にさらされることになったKubernetesのコンテナの動的な性質の対処への要求も大きくなります。
• ネットワーク機能ごとに別々のクラスタ – Kubernetesのネットワーキングでは、ネットワーク トラフィックのイングレス/エグレスのための一元管理がネイティブで提供されていません。Kubernetesはいくつかのイングレス制御を提供していますが、エグレス トラフィックはほぼ完全に無視され、イングレス ネットワーキングとエグレス ネットワーキングを結合する方法は組み込まれていません。私たちは、サーバーのIPアドレスとネットワーク機能のIPアドレスを相関させるために、各ネットワーク機能が独自のクラスタで実行されているデプロイメントを多数目にしてきました。これはリソースのオーバーヘッドとCapExの増加を招き、さらに運用が複雑になるため、OpExの増加にもつながります。

Kubernetesパターンと整合させる

別のアプローチとしては、Kubernetesの設計パターンに沿って、Kubernetesクラスタのイングレス/エグレスのネットワーキングとセキュリティを把握できる「単一画面」を外部に提供するサービス プロキシを導入することです。サービス プロキシの目的は、Kubernetesをサービス プロバイダ環境で使用する際に生じる機能的なギャップを埋めることです。サービス プロキシには、次のような機能が必要です。

• Kubernetesネイティブ パターンを使用して、Kubernetesネットワーキング（カスタム リソース定義、K8sのコントロール ループ）を拡張する
• 幅広いネットワークとのインターフェイス（BGPルーティング、エグレスSNAT IP割り当て、IPv4/v6トランスレーション）を提供する
• CNFごとにイングレスとエグレスを個別にリンクする
• 幅広いL4/L7サポートを提供する（tcp、udp、sctp、NGAP、HTTP/2、Diameter、GTP、SIP）
• セキュリティ レイヤを提供する（TLSターミネーション、ファイアウォール、DDoS、Web Application Firewall）
• 一貫したCNFを示し、非常に動的なKubernetesイベントを隠す

F5のアプローチ — サービス プロキシの導入

F5は、上記の2番目のシナリオを選択し、Kubernetesを拡張してこのサービス プロキシを作成し、この不足している機能を提供することにしました。数十年にわたるトラフィック管理とセキュリティの専門知識に基づき、大規模なクラウドネイティブ移行のサポートに必要な重要な機能であると確信しています。Kubernetesの欠点に直接対処し、サービス プロバイダが標準のKubernetesに欠けているリソースを作成できるようにするために、私たちはクラウドネイティブなインフラストラクチャ製品であるBIG-IP Next Service Proxy for Kubernetes（SPK）を開発し、運用を開始しました。SPKは、より広範なネットワークやセキュリティのポリシーを自動化してスムーズに統合するフレームワークにより、アーキテクチャを簡素化し、安全性を確保します。このような通信事業会社向けのKubernetesに対するアプローチは、今後も複雑さと運用コストの低減に加え、より柔軟で安全なインフラストラクチャを実現することにつながるでしょう。今日、5G SAへの移行が減速している（「5G SAに失敗している通信事業会社」、GlobalData Finds）ことを目の当たりにしているように、適切なサービス プロキシを導入しなければ、移行はさらに停滞すると考えてよいでしょう。大規模なデジタル モダナイゼーションの真っ只中にある実運用中の通信事業会社の顧客は、SPKが自分たちでも把握していなかった5Gネットワーク アーキテクチャの問題に対するKubernetesソリューションであることに気づいています。

F5のSPKは現在GAであり、大規模な通信事業会社での運用が開始されています。今後開催されるイベントでは、他のアプローチと比較したSPKの機能や、当社プラットフォームでCNFを認証する方法について紹介する予定です。詳細については、こちらのページをご覧ください。また、F5のチーム メンバーに直接問い合わせたい場合は、当社までご連絡ください。