ブログ

Kubernetes 向けサービス プロキシを使用して通信事業者の 5G ネットワーク アーキテクチャを強化

フィル・クラッテのサムネイル
フィル・クラッテ
2022年8月22日公開

2018 年の初め、私はネットワークや新たな 5G 標準の専門家である友人や同僚と同じような会話を何度も繰り返していました。私たちは皆、多くの未知の要素を抱えたまま移行に向かって急いでいることに漠然とした不安を感じていました。 5G がコンテナとクラウドネイティブ アーキテクチャへの移行を推進することは誰もが理解していましたが、Kubernetes やその他のクラウドネイティブ ツールはもともとまったく異なるユースケースを念頭に置いて作成されたこともわかっていました。 私たち全員が目にしたのは（そしておそらくこの投稿を読んでいる多くの人も気づいたでしょうが）、私たちの業界が胸焼けと衝突する道を歩んでいたということでした。

不安な日々から、通信サービスプロバイダー (CSP) はクラウドネイティブ インフラストラクチャへの移行という実際の作業を開始しました。 実際、こうした導入の先駆者たちは、当初設計された Kubernetes ネットワークの重要な領域がサービス プロバイダーのユース ケースの要求を満たすことができないという予期しない障壁を発見しています。 通信事業者の目標が 5G スタンドアロン (SA) コアの導入に移行することであろうと、分散クラウド アーキテクチャによる近代化イニシアチブの一部であろうと、Kubernetes を適応させてネットワークの相互運用性、キャリアグレードのスケール、キャリアのセキュリティ ポリシーをサポートすることは、クラウド ネイティブ インフラストラクチャ全体に必要な重要な機能です。

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

Kubernetes を今日のサービス プロバイダーのユース ケースに適合させるために必要な機能強化について説明する前に、まずサービス プロバイダー ネットワークがもたらす固有の要件を特定しましょう。

Kubernetesはより大きなエコシステムに適合する必要がある

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

第二に、通信事業者のワークロード (ネットワーク機能) は IT ワークロードとは異なります。 サービス プロバイダー ネットワークとそのネットワーク機能は、標準の HTTP/HTTPS や TCP 以上のものを活用します。 モバイル プロバイダーにとって、SIP、GTP、SCTP などの従来の 3G/4G プロトコルと 5G HTTP2 の両方のネットワーク サポートを備えることが重要になります。 また、通信事業者のワークロードには、IT ワークロードと比較して、従来のネットワーク層の上に追加の標準層が存在します。

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

こうした機能的ギャップに対処するための現在の2つのアプローチ

Kubernetes パターンを回避する

クラウド ネイティブ パターンを回避することは、Kubernetes に通信ワークロードを処理するツールがネイティブに付属していないため、アーキテクトが必然的にハックを作成せざるを得ないことを示しています。 私たちは、通信事業者がパターンを破っているいくつかの厄介な方法を観察してきました。

  • Kubernetes ネットワークの回避 – CNF の大部分は、1 つ以上のインターフェースを Kubernetes の制御外に配置しています。 これらの CNF には、直接的なネットワーク アクセスが必要です (多くの場合、「マルチス」の要求として提示され、外部への直接的な追加のインターフェイスを許可します)。 ネットワーク制御の中心点がなければ、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、Webapplicationファイアウォール）を提供する
  • 一貫性のある CNF を提示し、非常に動的な Kubernetes イベントを隠します。

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

F5 は、Kubernetes を拡張し、この不足している機能を提供するためにこのサービス プロキシを作成するために、上記の 2 番目のシナリオを選択しました。 当社は数十年にわたるトラフィック管理とセキュリティの専門知識に基づき、大規模なクラウドネイティブ移行をサポートするために必要な重要な機能であると考えています。 当社は、Kubernetes の欠点を直接解決し、サービス プロバイダーが「標準」の Kubernetes に欠けているリソースを作成できるようにするために、本番環境ですぐに使用できる BIG-IP Next Service Proxy for Kubernetes (SPK) クラウド ネイティブ インフラストラクチャ製品を開発しました。 SPK は、より広範なネットワークおよびセキュリティ ポリシーを自動化し、スムーズに統合するフレームワークにより、アーキテクチャを簡素化し、保護します。 通信事業者向け Kubernetes へのこのアプローチは、複雑さと運用コストの低減、そしてより回復力とセキュリティに優れたインフラストラクチャの実現につながります。 現在、5G SA への移行が減速しているのを目撃しています ( GlobalData によると、通信事業者は 5G SA に失敗)。適切なサービス プロキシが導入されなければ、移行はさらに停滞すると想定しても間違いないでしょう。 大規模なデジタル近代化の真っ只中にある実稼働中の通信事業者の顧客は、SPK が、彼らが気づいていなかった 5G ネットワーク アーキテクチャの問題に対する Kubernetes ソリューションであることを証明していることに気づき始めています。

 

F5 BIG-IP Next Service Proxy for Kubernetes (SPK) を使用した通信プロトコル向け Kubernetes イングレスの図

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