Kubernetesがネットワークを侵食していく

執筆者 | 2022年12月5日 | Blog

Kubernetes がインフラストラクチャを侵食

Kubernetesは、コンピューティングの歴史において最も重要なプラットフォームの変遷のひとつだ。Kubernetesは、分散クラウドネイティブ・アプリケーションのデプロイ、スケジューリング、運用の方法だ。このプラットフォームは、最新のアプリケーションがコンピュート、ストレージ、ネットワーキング、GPU、DPUリソースなどのクラウドインフラストラクチャを扱うデファクトな方法に急速になりつつある。パブリッククラウドでも、エッジでも、プライベート環境(プライベートデータセンターやコロケーションセンター)でも、Kubernetesはどこにでもある。VMとは異なり、Kubernetesはクラウドネイティブなアプリケーションをデプロイする人々のために設計された、親しみやすく直感的な方法でインフラリソースを抽象化し、定量化します。Kubernetesは、実用的なアプリケーション・コンポーネント中心の視点からインフラを捉えている。このようにインフラを抽象化することで、Kubernetesはプライベート、パブリックを問わず、複数のクラウドや環境にまたがるアプリケーションのポータビリティを可能にする。(もちろん、それぞれのクラウドが提供するプラットフォーム・サービスに直接「ハード」な依存関係がない限りはだが)。

クラウド ネイティブのランドスケープ

Kubernetesの人気が高まるにつれ、運用ツールのエコシステムも急速に拡大している。Kubernetesと同様に、これらのツールはクラウドネイティブであり、同じインフラストラクチャ・アブストラクションを活用して、プライベート、パブリックを問わず、あらゆるクラウドのあらゆる環境に適応させることができる。複数のクラウドにまたがる監視、デプロイ、デバッグは、デファクト・オープン・ツールチェーンを使用して、標準的な非特注の方法で実行される。何十万もの開発者、SRE、DevOpsチームが、プロプライエタリな行き詰まりを恐れることなく、日常的にこれらのツールを採用している。これらのツールは、組織、企業、クラウドを越えて共有されるため、これらのツールを知ることは、どこにでも適用できるポータブルなスキルセットとなる。

ネットワークはもっとクラウド化すべき

ほとんどどこでも - このどれもが現代のネットワーキングには当てはまらない。クラウドネットワーキングを管理・監視するための標準的なクラウド・ネイティブの運用管理ツールは当たり前になっているが、パブリッククラウド外の物理ネットワークについては同じことは言えない。プライベート環境の物理ネットワーキングは、クラウド以前の時代にとどまっている。私たちはいまだに、主にベンダーの利益にはなっても実務者の利益にはならない、ベンダー固有の特注ツールに頼っている。管理ツールは、主要なネットワーク・インフラ・ベンダーにとって、急速にプラットフォームとしての役割を果たすようになってきている。これらのツールは、クラウドでホスティングされたサービスとして提供されることが多く、顧客を自社の幅広い製品に囲い込む手段として利用されている。このモデルの主なインスピレーションの1つは、Ciscoの成功したMerakiプラットフォームだ。Merakiはクラウドホスティングの管理プラットフォームを中心に企業やキャンパスのネットワーキングをコンシューマー化し、ネットワーク運用を大幅に簡素化した。しかし、その代償として、プラットフォームがサポートするハードウェア・システムやベンダーの選択肢は減少した。シスコの NEXUS Cloud、アリスタの Cloud Vision、ジュニパーの Apstra など、データセンター・プラットフォームでも同様の製品ラインの移行が起きている。ネットワーク管理ツールは今や、運用面で競合を締め出す仕組みになっている。

歴史的には、ハードウェア・アプライアンスとして提供されるというフォーム・ファクターがすべてを定義してきた。私たちがネットワークを管理する方法は、まさにそのようなものです。ネットワークは分散型アプリケーションの元祖だった。ソフトウェア・ネットワーク・ファンクションの出現は、ネットワーキングの分散型アプリケーションの性質をより強くしている。新しいネットワーキング・アプリケーションやサービスは、スイッチ、スマートNIC、通常のサーバー、特別なサービス・ノード(通常のサーバーだがネットワーキング専用)など、どこでも実行できる。

ネットワークはクラウドへと変貌を遂げつつあります。

この "ボックス・アプローチ "はソフトウェアには通用しません。運用面では、ネットワーキングをコンピューティングとアプリケーションのプラットフォームに近づける必要がある。NetOpsが通常のDevOpsプロセスの一部に過ぎないクラウドで、多くの人が今日享受しているのと同じ経験を提供しなければならない。多くの若いインフラ・スペシャリストがクラウドで育っていく中で、物理的なネットワーキングを、新しいインフラ・スペシャリストが慣れ親しんでいるように感じさせ、動作させ、操作できるようにする必要がある。

ネットワークはもっとKubernetes化すべき

大手ネットワーク機器ベンダーの考えとは裏腹に、ネットワーク管理ツールはプラットフォームではない。物理的なネットワークは、インフラストラクチャーのほんの一部だが、必要不可欠なものだ。物理ネットワークは、アプリケーション同士、インターネット、そして他のクラウドや環境と接続する役割を担っている。どのような環境においても、物理ネットワークはアプリケーションに不可欠な部分だ。しかし、この部分だけは、インフラやアプリケーション・スタックの残りの部分の運用と互換性がないことが多い、特注の特殊な方法で管理されている。そしてスタックのその部分は、パブリッククラウドと同じように、Kubernetesによって完全に支配されることになる。Kubernetesは、急速に台頭しつつある事実上のインフラ消費プラットフォームであり、最新の分散アプリケーションを管理する優れた方法である。Kubernetesは幅広いデファクト運用ツールにうまく統合され、GitOps、Infrastructure as Code/Data、継続的デプロイメントなどの最新の運用アプローチとうまく連携する。 Kubernetesを利用することで、物理的なネットワーキングは標準的なオープンインフラスタックの単なるコンポーネントになる。

どうすればいいのか?

Network OS

まず、モダンな分散アプリケーションに対してネットワークを提供するために、オープンなネットワーク・オペレーティング・システム(NOS)が必要です。NOS はモジュール化され、コンテナ化されている必要があります。その各コンポーネントやサービスを、シンプルにアプリケーションとして扱えるようにする必要があります。少し (いや、かなり) 手入れをすることで、これらの特性を実現することができます。 SONiC はすでに多くのコミュニティから支持を得ており、ほとんどのホワイトボックスやブランドのシステムベンダーからサポートを受けています。しかし、必要な作業もあります。かなりの数の初期化スクリプトやハウスキーピング処理用のスクリプトを切り離し、ひもづけを解除し、モジュール化する必要があります。その目標は、各サービスを独立して管理し、他のサービスに影響を与える広範なリブートを必要とせずに更新可能にすることです。  コンテナランタイムは、Kubernetesや他の最新のクラウドネイティブツールとの相互運用性を確保するために、Dockerからcontainerdへの移行が必要になるかもしれません。 

Kubernetes コントロール プレーン

Kubernetesはソフトウェアをデプロイし、コンフィギュレーションを配布するための優れたツールだ。高度にモジュール化され、(CRD、コントローラ、オペレータを介して)拡張可能であるため、インフラストラクチャ・コントローラの理想的な基盤となっている。スイッチ、smartNIC、サービスノードのネットワークをKubernetesクラスタにすることで、ネットワークを分散アプリケーションの束として扱うことができる。それらは、ルーティングプロトコル、ユーティリティ機能、観測プローブ、プロキシ、APIゲートウェイ、ポリシーエンフォーサー、ログ収集エージェント、またはデバッグボットであることができる。今日のハードウェアは素晴らしい。今必要なのは、より優れたソフトウェアであり、商用、オープンソース、あるいはカスタム開発された実験用ソフトウェアである。

クラウドネイティブの運用とオブザバビリティ(可観測性)

運用面では、Kubernetesによって、一般的に使用されているクラウドネイティブツールとの統合が簡素化されます。これにより、ELK-stack、Prometheus、Jaeger、Grafanaといった観測/遠隔測定ツールのネイティブな利用が可能になります。TerraformやArgoCDなどの自動化ツールは、GitOpsやInfrastructure As Codeといった標準的なDevOpsの実践を可能にします。これらのツールとの統合により、パブリッククラウドのDevOpsチームやSREチームが享受しているのと同じ運用手法がもたらされます。

ファブリックの抽象化

クラウドで育った人々にネットワーク・インフラを開放する必要がある。クラウド・ネットワーキングを扱う人なら誰でも、VPCの概念に精通している。VPCはAWSにおけるネットワーク消費と分離の基本単位だ。クラウドのネットワークの "スライス "を持つことができ、そこでアプリケーションを実行することができる。このコンセプトは非常に抽象的で、ネットワーキングの基本的な実装を漏らすことはない。ユーザーにとっては、ネットワークがどのように実装されているかは関係ない。ユーザーは、基本的なネットワーキングの概念やプロトコルを直接コントロールすることはできない。ユーザーがネットワークと相互作用できる唯一の方法は抽象化です。

オフクラウドの物理ネットワークについても、同様の方法を採用する必要があります。この抽象化はユーザにインスツルメンテーションやプロトコルの詳細を漏らしてはならず、対応するインスツルメンテーションポリシーによって複数のネットワーキング技術に適応可能でなければなりません。例えば、VPC オブジェクトの org やユーザ、プロパティに基づき、VLAN もしくは BGP eVPNです。インストルメントポリシーは、ネットワークアーキテクチャチームが所有・管理し、VPCを割り当てるユーザが変更できるものではありません。

当初の予想をはるかに超える未来が待っています。

新しいオープンな物理ネットワーキングを大衆に提供し、クラウド化することで物理インフラを簡素化し、最終的に物理ネットワーキングの邪魔をしないようにしよう。 私たちはそのために懸命に取り組んでいます、 私たちの革命に参加しませんか?