Kubernetes がエッジ コンピューティング プラットフォームをサポートする方法

コンテナ オーケストレーション エンジンはエッジ ソリューションになる可能性がありますが、エッジ ソリューションになる前に解決する必要がある問題がまだ多くあります。

[[380200]]

おそらく、Kubernetes が従来のオンプレミス環境とクラウド環境の両方で大規模なアプリケーションの導入をいかに簡素化するかについては、すでにご存知でしょう。しかし、中央データセンターと、エンドユーザーに近いエッジロケーションでホストされるワークロードを組み合わせたエッジアーキテクチャはどうでしょうか? Kubernetes はエッジ コンピューティング プラットフォームもサポートできますか?

答えはイエスです。 Kubernetes はエッジ コンピューティング ソリューションとして潜在能力を秘めていますが、K8s がエッジに真に対応できるようになるには、Kubernetes 開発者とユーザーが克服しなければならないハードルがいくつかあります。

Kubernetes がエッジコンピューティング プラットフォームにどのように役立つか

一部の観察者は、Kubernetes はエッジ環境でアプリケーションをホストする準備ができていると考えています。たとえば、Canonical の Ammar Naqvi 氏は、Kubernetes は「エッジ コンピューティングの重要なコンポーネント」であると述べており、Cloud Native Computing Foundation も Kubernetes をエッジ ソリューションとして推進しています。また、同社は、昨年 11 月に CNCF のインキュベーション プロジェクトとなった、Kubernetes ベースのエッジ デプロイメント専用の完全なオープン ソース プラットフォームである KubeEdge のスポンサーでもあります。

もちろん、これらの組織は多少偏りがあります。 Canonical と CNCF は Kubernetes に深く投資しており、エッジ コンピューティング プラットフォームを構築するためのソリューションとして Kubernetes が普及すれば、大きな利益が得られます。

それでも、Kubernetes がエッジに自然に適合する理由については、いくつかの良い点を指摘しています。この記事の執筆時点では、Kubernetes は、基盤となるあらゆるタイプのエッジ インフラストラクチャで使用できるユニバーサル コントロール プレーンを提供しており、さまざまなエッジ環境にわたるワークロードの展開と管理を簡素化します。 Kubernetes は、エッジ ワークロードの優先事項であるトラフィックのバランス調整とレイテンシの最小化にも優れています。また、Kubernetes は DevOps CI/CD パイプラインのデプロイメント環境として機能することで、開発者がエッジ アプリケーションを継続的に更新することを容易にします。

Kubernetes の推進に明確な関心を持つベンダーや開発者に加えて、より中立的なグループも Kubernetes を将来のエッジ コンピューティング プラットフォームの重要なコンポーネントと見なしているという証拠があります。 Omdia は、クラウドおよびデータセンター業界の 12 名以上の思想的リーダーやベンダーへのインタビューに基づくレポートで、現在、半数以上が Kubernetes がエッジ ワークロードに導入されていると考えていることを明らかにしました。

Omdiaのレポートによると、「Kubernetesは、クラウドからエッジまでワークロードを管理できるテクノロジーとして登場し、ユニバーサルなアプリケーション管理プラットフォームを提供するだろう」とのことだ。

つまり、Kubernetes が今後数年間でエッジ コンピューティング プラットフォームのますます重要な部分になると信じる十分な理由があります。

Kubernetes エッジの課題

ただし、Kubernetes がエッジに展開されたアプリケーションを管理するための真にシームレスなソリューションになるためには、開発者がいくつかの課題に対処する必要があります。

おそらく最大の問題は、中央データセンターとエッジロケーション間の低遅延データ転送を確保することです。多くの点で、データを迅速に移動することがエッジ コンピューティングの最大の課題です。アプリケーション オーケストレーションは二次的な問題です。 Kubernetes 自体はデータ転送を最適化しません。データ構造はそうなりますが、Kubernetes は特定の方法でそれらと統合しません。

Kubernetes ベースのエッジ環境で低レイテンシのデータ移動を保証するには、エッジ コンピューティング プラットフォームを構築する開発者は、Kubernetes と、展開を容易にするデータ ファブリック ソリューションを組み合わせる必要があります。また、Kubernetes が内部データの移動を処理する方法を改善する必要がある場合もあります。たとえば、どの内部トラフィックを優先するかを Kubernetes が簡単に判断できるようにすることなどです。現在、Kubernetes は外部エンドポイントからの着信トラフィックのバランスをとる方法を適切に判断しますが、1 ミリ秒単位で影響が出る内部トラフィック フローの管理はあまり得意ではありません。同様に、Kubernetes はワークロードのスケジュールをより細かく制御することでメリットを得られます。 Kubernetes を使用すると、管理者はアプリケーションを個々のノードに配布できます。これは、すべてのノードが単一のデータセンター内で実行される場合に適しています。

しかし、ノードが複数のエッジロケーション、さらには中央データセンターに分散されている場合はどうなるでしょうか?この場合、独立したエッジ ロケーションでホストされているアプリケーションを管理し、それらの間のトラフィックを分散する機能が必要になる場合があります。現在の Kubernetes では、各エッジ ロケーションにノードが 1 つしかない場合を除き、これを実行するのは複雑です (これは不可能です)。したがって、Kubernetes に必要なのは、同じ物理的な場所で実行されている単一のノードではなく、地理的に異なる場所にあるノードのプールに基づいて、ワークロードの配置方法と優先順位付けを管理者が定義できる機能です。

マルチクラスターの管理は依然として課題です。もともと、Kubernetes は、各組織が 1 つのクラスターを実行し、複数の名前空間に分割されることを前提として設計されました。長年にわたって状況は変化し、現在ではほとんどの Kubernetes ベンダーがマルチクラスター管理をサポートしています。しかし、それらはうまく機能しておらず、Kubernetes 開発者にとって、複数のクラスターにわたるワークロードの管理は依然として二次的な考慮事項となっています。これはエッジ コンピューティング プラットフォームの問題であり、組織は各エッジ ロケーションで個別のクラスターを実行してワークロードを分離し、真に大規模な環境の管理を簡素化することを選択する場合があります。

結論は

Kubernetes はエッジ コンピューティング プラットフォームの基盤として多くの利点を提供しますが、この点に関してはいくつかの顕著な欠点もあります。そのため、一部のアーキテクトは、コンテナ化された通信アプリケーションなど、エッジにデプロイされる可能性のある特定のワークロードには Kubernetes は適していないと考えています。

一方、エッジ コンピューティング プラットフォームの基盤としての Kubernetes が直面している課題は、十分な開発努力をすれば解決可能です。おそらく、私たちが尋ねるべき本当の質問は、Kubernetes がエッジで機能するかどうか (現時点では、エッジ ソリューションとしてのみ機能するという答え) ではなく、開発者が Kubernetes を成熟したエッジ コンピューティング プラットフォームにするために必要な努力を払う意思があるかどうかです。