通信事業者向けにKubernetesを最適化

F5エコシステム | 2021年2月10日

ITの世界では、Kubernetesが広く普及しています。43,000人を超えるコントリビューターに支えられたこのオープンソースシステムは、クラウドで最新のアプリケーションをデプロイする際の標準的な手段となっています。その理由は、Kubernetesによって開発者の作業が大幅に容易になり、アプリケーションの展開が迅速化され、エンドユーザーにとって基盤となるプラットフォームの価値が高まるためです。

通信事業者が閉鎖的な環境からオープンプラットフォームへの移行を目指す中、k8sとも呼ばれるKubernetesは、近年、通信業界で注目を集めています。このシステムは、スタンドアロン5Gネットワークの能力を最大限に引き出すために必要な、柔軟なクラウドネイティブアーキテクチャに不可欠な要素となる見込みです。真のクラウドネイティブネットワークには、サービスの迅速な展開や自動化から、レジリエンスと効率の大幅な向上まで、さまざまなメリットがあります。その一例として、Googleは、Kubernetesの前身である社内プラットフォームBorgを使用して、週に20億個を超えるコンテナをデプロイしています。

このような柔軟性とスケーラビリティは、5Gネットワークを、サードパーティが開発する幅広いサービスやアプリに対応する汎用性の高いプラットフォームへと進化させる「通信事業者向けクラウド」のビジョンに不可欠です。Kubernetesを利用すると、通信事業者はアプリをポータブルなコンテナとしてデプロイできます。たとえば、サービスをエンドユーザーに近いネットワークエッジに配置し、レイテンシーを低減できます。

抽象化により開発者にとって魅力的

では、Kubernetesは実際に何をするのでしょうか。一般に、最新のアプリケーションは、注文管理、レポート作成、決済など、それぞれ特定の機能を担う複数のマイクロサービスで構成されています。マイクロサービスをコンテナにパッケージ化すると、Kubernetesがそのデプロイ、スケーリング、管理を自動化します。また、マイクロサービスのクラスターで障害が発生した場合の自動復旧もサポートできます。

重要なのは、Kubernetesが基盤となる内部ネットワークの複雑さの一部を抽象化し、アプリ開発者の負担を大幅に軽減することです。つまり、Kubernetesを使用すれば、アプリをシンプルかつ容易に外部へ公開できます。

Kubernetes Ingress Controllerは、エンドユーザーがHTTPプロトコルを介してWebアプリケーションを利用するための経路です。また、トラフィック管理機能を提供し、ユーザーのリクエストをKubernetesクラスター内の適切なマイクロサービスにルーティングします。

通信事業者には発想の転換が必要

5Gネットワークのサービスベースアーキテクチャでは、通信事業者が新たな考え方を取り入れることで、こうしたメリットをすべて活用できます。Kubernetesには多くのメリットがある一方で、通信エンジニアが慣れ親しんできた手法とはやや異質に感じられる場合があります。ネットワークを熟知している通信事業者にとっては、ネットワーク機器のIPアドレスを手動で設定し、ルーティングや負荷分散のルールを独自に定めることが一般的です。しかし、こうした設定をはじめとする各種パラメーターは、Kubernetesが抽象化するように設計されています。

しかし、このような手動設定ではKubernetes本来の目的が損なわれます。AWSやAzureなどの主要なクラウドプラットフォームの特長である、迅速なデプロイと自動スケーリングが妨げられるためです。通信事業者が4Gネットワークに導入した初期のネットワーク機能仮想化（NFV）ソリューションでは、手動スクリプトが使用される傾向にあり、その結果、最新のITアーキテクチャが備える動的な対応力と自動化が不足しています。

丸い穴に四角い杭？

5Gコアネットワークの展開にあたり、通信事業者はゼロから環境を構築できます。しかし残念ながら、標準的なKubernetesシステムをそのまま移植することはできません。大多数の通信事業者は4Gネットワークと並行して5Gネットワークを展開しているため、HTTPに加え、通信事業者の標準プロトコルであるSCTP、Diameter、GTPにも対応できるKubernetes Ingressが必要です。これは、5GサービスのフロントエンドとなるKubernetes Ingressが、HTTPを介してユーザーと直接やり取りするのではなく、他の4Gおよび5Gコア要素に接続するためです。場合によっては、HTTP/2メッセージとDiameterメッセージを相互に変換するインターワーキング機能が必要になります。

もう1つの課題は、アプリケーションクラスター内の内部通信をどのようにサポートするかです。標準的なKubernetes環境では、通常、サービスメッシュを使用して、異なるマイクロサービス間の通信を安全に管理および追跡します。このようなサービスメッシュはIT中心のトレーシング機能をサポートしていますが、通信事業者は、関連する機能が自社の要件に最適化されていないことを認識しつつあります。

3つ目の課題は、Kubernetesクラスター内の5G機能が外部とどのように通信するかです。Kubernetesによって割り当てられる動的な内部IPアドレスを外部に公開することは適切ではありません。これらのアドレスは時間の経過とともに変わるうえ、このレベルの情報を外部から見えるようにすると、重大なセキュリティリスクが生じます。通信事業者は、特定の5G機能へのIPアドレスの割り当てを完全に制御したいと考えています。これらのIPアドレスは、5G機能を構成する基盤コンテナで使用されるIPアドレスから独立している必要があります。これを実現するには、インテリジェントなKubernetesエグレス機能が必要です。

安易な妥協が禁物である理由

選択肢の1つとして、Kubernetesを使用せず、外部からアクセス可能な静的IPアドレスを持つコンテナに5G機能をデプロイする方法があります。しかし、このような近道を選べば、スケーラビリティと柔軟性が大きく損なわれます。たとえば、ボタンを押すだけで、ネットワーク内の任意の場所に5G機能をデプロイすることはできません。将来必要となるこのレベルの自動化を実現するには、Kubernetesで手を抜くことはできません。

F5は長年にわたり通信とITの両分野に携わり、通信事業者がKubernetesの幅広いメリットを活用できるよう支援する方法を確立してきました。その1つが、BIG-IP SPKソリューションです。KubernetesのイングレスでHTTPに加えて通信プロトコルもサポートできるようにします。また、ネットワークアドレス変換（NAT）とルーティングを使用することで、クラスター内部の動的な特性に影響を与えることなく、Kubernetesのエグレスから外部に対して事前定義された固定IPアドレスを提供できます。クラスター内部で何が起きても、外部のエンティティには常に同じIPアドレスを提供できます。さらに、F5のAspen Meshサービスメッシュは、「通信事業者グレード」の可観測性とトレーシングをサポートします。5Gマイクロサービス間を流れるトラフィックを通信事業者が完全に可視化して追跡できるため、セキュリティの強化につながります。

Kubernetesを適切に導入すれば、通信事業者に大きな変革をもたらす可能性があります。クラウドネイティブアーキテクチャの多くのメリットを引き出し、通信事業者と外部との連携を大幅に容易にできます。このオープンソースシステムは、通信環境に完全に適合させることで、5Gの未来に欠かせない要素となるでしょう。

本記事は2回シリーズの第1回です。次回は、異なるプラットフォーム上で稼働する多数のKubernetesクラスターにまたがるITワークロードと通信事業者向けワークロードの管理に伴う運用上の課題を、F5のテクノロジーでどのように解決できるかをご紹介します。

注目のブログ記事

F5、NVIDIA Cloud Partnerリファレンスアーキテクチャで大規模なAI推論を高速化・保護

妥協のないAIモデルとエージェントのセキュリティ：F5によるCalypsoAIの買収で実現する、エンドツーエンドのAIランタイム保護

量子時代への備え：F5でPQCを有効化するための実践ガイド