通信事業者向けに Kubernetes をカスタマイズする
IT の世界では、Kubernetes はあらゆるところに存在します。 43,000 人を超える貢献者によってサポートされているこのオープンソース システムは、クラウドで最新のapplicationsを展開するためのデフォルトの方法となっています。 なぜ？ 簡単に言えば、Kubernetes は開発者の作業を大幅に簡素化し、アプリの展開を高速化し、エンドユーザー向けの基盤プラットフォームに価値を追加します。
Kubernetes（別名k8s）は、通信事業者がウォールドガーデンからオープンプラットフォームへの移行を検討していることから、最近、通信業界で注目を集めています。 このシステムは、スタンドアロン 5G ネットワークを最大限に活用するために必要な柔軟なクラウドネイティブ アーキテクチャの不可欠な部分となる予定です。 真のクラウドネイティブ ネットワークは、サービスの迅速な導入や自動化から、回復力と効率性の大幅な向上まで、さまざまなメリットをもたらします。 一例として、Google は Kubernetes の前身である社内プラットフォーム Borgを使用して、週に 20 億を超えるコンテナをデプロイしています。
こうした柔軟性と拡張性は、5G ネットワークがサードパーティによって開発された幅広いサービスやアプリに対応する多目的プラットフォームになるという、通信事業者のクラウド ビジョンの基盤となります。 Kubernetes により、通信事業者はポータブル コンテナにアプリケーションを展開できるようになるため、たとえば、サービスをネットワークのエッジ、つまりエンド ユーザーの近くに配置して、レイテンシを削減できます。
抽象的で開発者にとって魅力的
では、Kubernetes は実際に何をするのでしょうか? 最新のapplicationは通常、さまざまなマイクロサービスから構築され、それぞれが注文管理、レポート、支払いなどの特定の機能を処理します。 マイクロサービスがコンテナにパッケージ化されると、Kubernetes によってそのデプロイメント、スケーリング、管理が自動化されます。 Kubernetes は、マイクロサービスのクラスターで障害が発生した場合の自動修復もサポートできます。
重要なのは、Kubernetes がアプリ開発者にとって基礎となる内部ネットワークの複雑さの一部を抽象化することです。 これにより、一般的なアプリ開発者の作業が大幅に楽になります。 本質的に、Kubernetes を使用すると、アプリをシンプルかつ簡単に外部からアクセスできるようになります。
Kubernetes イングレス コントローラーは、エンドユーザーが HTTP プロトコルを介して Webapplicationと対話するための経路です。 イングレス コントローラーはトラフィック管理も提供し、ユーザー リクエストが Kubernetes クラスター内の適切なマイクロサービスにルーティングされるようにします。
通信事業者は考え方を変える必要がある
これらすべての利点は、5G ネットワークのサービスベースのアーキテクチャによって実現できますが、通信事業者が新しい考え方を採用した場合に限られます。 Kubernetes には多くの利点がありますが、そのシステムは通信エンジニアが慣れているものとは多少異なるように思えるかもしれません。 通信事業者はネットワークに携わっているため、ネットワーク機器の IP アドレスを手動で構成したり、ルーティングや負荷分散に関する独自のルールや、Kubernetes が抽象化するように設計されたその他のパラメータを設定したりすることに慣れています。
ただし、このような手動構成は Kubernetes の本質を損ないます。AWS や Azure などの主要なクラウド プラットフォームの特徴である迅速な導入と自動スケーリングが妨げられるからです。 通信事業者が 4G ネットワークに導入した最初のネットワーク機能仮想化 (NFV) ソリューションは、手動のスクリプトを使用する傾向があり、その結果、最新の IT アーキテクチャのダイナミズムと自動化が欠けています。
丸い穴に四角い釘を差し込む？
5Gコアネットワークの展開により、通信事業者は白紙の状態になります。 しかし、残念ながら、標準の Kubernetes システムをそのまま移植することはできません。 通信事業者の大多数は 4G ネットワークと並行して 5G ネットワークを展開しているため、HTTP だけでなく、標準の通信プロトコル (SCTP、Diameter、GTP) もサポートできる Kubernetes イングレスが必要になります。 これは、5G サービスのフロントエンドとなる Kubernetes イングレスが、HTTP 経由でユーザーと直接インターフェースするのではなく、他の 4G および 5G コア要素に接続するためです。 場合によっては、HTTP/2 メッセージを Diameter メッセージに変換したり、その逆を行ったりする相互運用機能が必要になります。
もう 1 つの複雑な点は、applicationクラスター内で内部通信をどのようにサポートするかということです。 標準的な Kubernetes デプロイメントでは、通常、サービス メッシュを使用して、さまざまなマイクロサービス間の通信を安全に管理および追跡します。 このようなサービス メッシュは IT 中心のトレース機能をサポートしていますが、通信事業者は、関連する機能が要件に最適に適合していないことに気づき始めています。
3 番目の問題は、Kubernetes クラスター内の 5G 機能が外部とどのように通信するかです。 Kubernetes によって割り当てられた動的な内部 IP アドレスを公開するのは良い考えではありません。 アドレスは時間の経過とともに変化するため、このレベルの可視性を外部に公開すると、大きなセキュリティ リスクが生じます。 通信事業者は、特定の 5G 機能への IP アドレスの割り当てを完全に制御したいと考えています。 これらは、この 5G 機能を構成する基盤となるコンテナーによって使用される IP アドレスとは独立している必要があります。 これを実現するには、スマートな Kubernetes 出力機能が必要です。
手抜きはなぜ悪い考えなのか
1 つの選択肢としては、Kubernetes を使用せずに、外部からアクセス可能な静的 IP アドレスを持つコンテナに 5G 機能をデプロイすることが挙げられます。 しかし、このように手抜きをすると、拡張性と柔軟性の面で大きな代償を払うことになります。 たとえば、ボタンを押すだけでネットワーク内のどこにでも 5G 機能を展開することはできません。 将来的には、そのレベルの自動化が必要な場合、Kubernetes で手抜きをすることはできません。
F5 は長年にわたり通信業界と IT 業界に携わっており、通信会社が Kubernetes の幅広いメリットを活用できるように支援する方法を編み出してきました。 これには、Kubernetes イングレスが HTTP だけでなく通信プロトコルもサポートできるようにするBIG-IP SPK ソリューションが含まれます。 また、ネットワーク アドレス変換 (NAT) とルーティングを使用して、クラスターの内部ダイナミズムに影響を与えることなく、Kubernetes の出力が外部に静的な定義済み IP アドレスを提供できるようにします。 クラスター内で何が起こっても、外部エンティティには常に同じ IP アドレスを提供できます。 さらに、当社の Aspen Mesh サービス メッシュは、「通信事業者グレード」の可観測性とトレース機能をサポートしています。 これにより、通信事業者は 5G マイクロサービス間を流れるトラフィックを完全に可視化して追跡できるようになり、セキュリティが強化されます。
Kubernetes は、適切なアプローチをとれば、通信事業者にとって真の変革をもたらすことができます。クラウドネイティブ アーキテクチャの多くの利点を解き放ち、オペレーターが外部とやり取りすることをはるかに容易にすることができます。 このオープンソース システムは、通信環境に完全に適合すると、5G の未来に不可欠な要素となることは間違いありません。
この記事は 2 部構成のシリーズの第 1 部です。 次回は、さまざまなプラットフォームで実行されている多数の Kubernetes クラスター全体で IT および通信ワークロードを管理する運用上の悩みを F5 テクノロジーがどのように解決できるかについて説明します。