Kubernetes がインフラストラクチャを侵食
Kubernetesは、コンピューティングの歴史の中で最も重要なプラットフォームの変遷の1つです。Kubernetes は、分散型クラウド ネイティブ アプリケーションのデプロイ、スケジュール、および操作の手法です。このプラットフォームは、最新のアプリケーションがコンピューティング、ストレージ、ネットワーク、GPU、DPUリソースなどのクラウドインフラを管理するデファクトとして急速に普及しつつあります。パブリッククラウド、エッジ、プライベート環境（プライベートデータセンター、コロケーションセンター）のいずれにおいても、Kubernetesはあらゆる場所で利用されています。仮想マシンとは異なり、Kubernetesはインフラリソースを抽象化し、クラウドネイティブアプリケーションを展開する人々のために設計され、使いやすく直感的な方法で可視化します。Kubernetesは、実用的なアプリケーション・コンポーネント中心の視点からインフラを管理します。このようにインフラを抽象化することで、Kubernetesは、プライベートおよびパブリッククラウドをまたがる複数の環境においても、アプリケーションのポータビリティを可能にします。(もちろん、それぞれのクラウドが提供するプラットフォーム・サービスに直接「ハード」な依存関係がない限りはですが)。
Kubernetes の人気が高まるにつれて、すでにかなりの規模の運用ツールのエコシステムが急速に拡大しています。 Kubernetes と同様に、これらのツールはクラウドネイティブであり、同じインフラストラクチャの抽象化を活用して、プライベートまたはパブリックの任意のクラウド内の任意の環境に適応できます。複数のクラウドにわたる可観測性、展開、およびデバッグは、事実上のオープン ツールチェーンを使用して、標準的な非オーダーメイドの方法で実行されます。何十万もの開発者、SRE、および DevOps チームが、独自の行き詰まりに陥ることを恐れることなく、これらのツールを日常的に使用しています。これらのツールは、組織、企業、およびクラウド間で共有されるため、これらのツールを知ることで、どこにでも適用できる移植可能なスキル セットが作成されます。
ネットワークはもっとクラウド化すべき
ほとんどどのような場所においても - モダンなネットワーキングに当てはめることができていない。クラウドネットワーキングの管理と監視には、標準的なクラウドネイティブ運用ツールが当たり前になっていますが、パブリッククラウド以外の物理ネットワークについては、同じことは言えません。プライベートクラウド環境における物理ネットワークは、依然としてクラウド以前の時代のままです。私たちはいまだに、主にベンダーの利益のためであって、現場の実務者のためではない、ベンダー独自のツールに頼ってしまっています。管理ツールは、主要なネットワークインフラストラクチャベンダーのプラットフォームとして急速に変化しています。ネットワークベンダーはこれらのツールを、クラウドでホストされたサービスとしても提供し、顧客をより広範な製品に囲い込む手段として利用しています。このモデルのインスピレーションの一つに Cisco が成功させた Meraki プラットフォームがあります。Meraki はクラウドでホストされる管理プラットフォームを中心に、企業やキャンパスのネットワークをコンシューマ化し、ネットワークの運用を大幅に簡素化しました。しかし、その代償としてプラットフォームがサポートできるハードウェアとベンダーの選択肢を減らすことになりました。同じような製品ラインに対する変化は、Cisco の NEXUS Cloud、Arista の Cloud Vision、Juniper の 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、コントローラ、オペレーターを介して）拡張可能であるため、インフラストラクチャ・コントローラーの理想的な基盤となっています。スイッチ、スマートNIC、サービスノードのネットワークをKubernetesクラスタにすることで、ネットワークを分散アプリケーションの束として扱えるようになります。それらはルーティングプロトコル、ユーティリティ関数、オブザベイラビリティ(可観測性)プローブ、プロキシ、APIゲートウェイ、ポリシーエンフォーサー、ログ収集エージェント、またはデバッグ用のBotになることができます。今日のハードウェアは驚くべきものです。今必要なのは、より優れたソフトウェア、つまり商用、オープンソース、またはカスタム開発された実験用ソフトウェアなのです。
クラウドネイティブの運用とオブザバビリティ(可観測性)
運用面では、Kubernetesによって、一般的に使用されているクラウドネイティブツールとの統合が簡素化されます。これにより、ELK-stack、Prometheus、Jaeger、Grafanaといった観測／遠隔測定ツールのネイティブな利用が可能になります。TerraformやArgoCDなどの自動化ツールは、GitOpsやInfrastructure As Codeといった標準的なDevOpsの実践を可能にします。これらのツールとの統合により、パブリッククラウドのDevOpsチームやSREチームが享受しているのと同じ運用手法がもたらされます。
ファブリックの抽象化
クラウドで育った人たちにネットワークインフラを開放する必要があるのです。クラウドネットワークを扱う人は誰でも、VPCという概念を熟知しています。VPCはAWSにおけるネットワークの利用と分離の基本単位です。VPCにより、クラウドのネットワークに自分だけの「一区画」を持つことができ、そこでアプリケーションを実行することができます。このコンセプトは非常に抽象的で、ネットワークの基本的な実装を外部に漏らすことはありません。ユーザーにとっては、ネットワークがどのように実装されているかは重要ではありません。ユーザーは基本的なネットワークの概念やプロトコルを直接制御することはできません。ユーザーがネットワークと対話できる唯一の方法は、抽象化されたものです。
オフクラウドの物理ネットワークについても、同様の方法を採用する必要があります。この抽象化はユーザにインスツルメンテーションやプロトコルの詳細を漏らしてはならず、対応するインスツルメンテーションポリシーによって複数のネットワーキング技術に適応可能でなければなりません。例えば、VPC オブジェクトの org やユーザ、プロパティに基づき、VLAN もしくは BGP eVPNです。インストルメントポリシーは、ネットワークアーキテクチャチームが所有・管理し、VPCを割り当てるユーザが変更できるものではありません。
当初の予想をはるかに超える未来が待っています。
新しいオープンな物理ネットワークを広く普及させ、物理インフラをクラウド化してシンプルにし、最終的には物理ネットワークが妨げにならないようにしていきましょう。 私たちはこのことに懸命に取り組んでいます。 私たちの革命に参加しませんか？
