過去 10 年間、開発者はコンテナと Docker フォーマットを活用して明らかに成長してきましたが、Kubernetes インフラストラクチャの構築と運用を担うプラットフォーム エンジニアリング チームにとっては、DIY と試行錯誤の 10 年間でした。
コンテナ黎明期には、Docker Swarm、CoreOS、Apache Mesos（Twitterで「Fail Whale」を撃破したことで有名）の三つ巴のケージマッチが行われ、クラウドとオンプレミスのクラスタをまたぐコンテナ化されたワークロードのオーケストレーションにおける覇権を巡って争いが繰り広げられました。その後、Googleが自社開発するBorgシステムの秘密が明らかになり、Kubernetes（一般ユーザーにとってはBorg！）がリリースされると、コミュニティの関心と業界からの支持が一気に高まり、Kubernetesは事実上のコンテナオーケストレーション技術の地位を奪うのに必要な勢いを増しました。
実際、Kubernetes は「クラウド ネイティブ オペレーティング システム」、つまり新しい「エンタープライズ Linux」のようなものだと私は主張しています。
しかし、本当にそうでしょうか？Kubernetesはクラスタリソース管理において強力な機能を提供する一方で、プラットフォームエンジニアリングチームは、クラウドネイティブアプリケーション同士が相互に通信し、共通のネットワーク、セキュリティ、レジリエンス機能をどのように共有するかという、最も困難な課題に依然として悩まされています。つまり、エンタープライズKubernetesには、コンテナオーケストレーション以外にも多くの機能があるということです。
名前空間、サイドカー、サービスメッシュ
プラットフォームチームがクラウドネイティブ・アプリケーション・インフラストラクチャを進化させるにつれ、新しいメトリクスの出力、トレースの作成、セキュリティチェックの追加など、さまざまな機能を継続的に追加していくことになります。Kubernetesの名前空間は、アプリケーション開発チームが互いに干渉し合うのを防ぐため、非常に役立ちます。しかし、時間が経つにつれて、プラットフォームチームはすべてのアプリケーションに同じコードを記述していることに気づき、そのコードをライブラリ化するようになりました。
参照: 採用キット: バックエンド開発者 (TechRepublic Premium)
その後、サイドカーと呼ばれる新しいモデルが登場しました。サイドカーの登場により、プラットフォームチームはこれらのライブラリをアプリケーションに物理的に組み込む必要がなくなり、アプリケーションと共存できるようになりました。IstioやLinkerdなどのサービスメッシュ実装は、サイドカーモデルを使用することで、ポッド内のアプリケーションコンテナの各インスタンスのネットワーク名前空間にアクセスできるようになります。これにより、サービスメッシュはアプリケーションに代わってネットワークトラフィックを変更したり（例えば、接続にmTLSを追加したり）、パケットをサービスの特定のインスタンスに誘導したりできるようになります。
しかし、すべてのポッドにサイドカーを導入すると追加のリソースが必要となり、プラットフォーム運用者からは運用の複雑さへの不満の声が上がっています。また、ネットワークパケットのパスが大幅に長くなり、レイテンシが大幅に増加してアプリケーションの応答速度が低下します。Googleのケルシー・ハイタワー氏は、この「サービスの混乱」を嘆いています。
クラウドネイティブ、コンテナ、そしてKubernetesの旅が始まってほぼ10年、私たちは今、抽象化をどこに位置づけるべきか、そしてネットワーク全体にわたるクラウドネイティブアプリケーションの共通要件における共有プラットフォーム機能に適したアーキテクチャとは何かという岐路に立たされています。コンテナ自体はLinuxカーネルのcgroupと名前空間から生まれました。そして、サイドカーモデルによって、ネットワーク、セキュリティ、そして可観測性ツールはKubernetesポッド内のアプリケーションコンテナと同じcgroupと名前空間を共有できるようになりました。
これまでのところ、それは規範的なアプローチでした。アプリケーションワークロードにアクセスしたり、その動作を変更したりするためのツールとして他に適切な選択肢がなかったため、プラットフォームチームはサイドカーモデルを採用せざるを得ませんでした。
カーネルへの進化
しかし、カーネル自体がTCP/IPスタックを既に実行しているのと同じように、サービスメッシュをネイティブに実行できたらどうなるでしょうか？ 金融サービスや数百万件もの同時トランザクションを扱う取引プラットフォーム、その他の一般的なエンタープライズユースケースなど、低レイテンシが本当に重要なケースにおいて、データパスからサイドカーレイテンシを取り除けたらどうなるでしょうか？ Kubernetesプラットフォームエンジニアが、新しい抽象化を学習することなく、サービスメッシュ機能のメリットを享受できたらどうなるでしょうか？
これらのインスピレーションが、IsovalentのCTO兼共同創業者であるThomas Graf氏を、サービスメッシュ分野におけるオープンソースの主要新製品となるCilium Service Meshへと導きました。Isovalentは本日、Cilium Service Meshの一般提供開始を発表しました。GoogleやLyftといったウェブスケーラーが、サイドカーサービスメッシュIstioやデファクトプロキシサービスEnvoyの推進力となっているのに対し、Cilium Service Meshは、エンタープライズネットワーク業界のLinuxカーネルメンテナーやコントリビューターによって開発されています。これは非常に重要な意味を持つ可能性があります。
Cilium Service Meshのローンチは、eBPFに遡ります。eBPFは、ユーザーがオペレーティングシステムのカーネル内でカスタムプログラムをロード・実行できるようにすることで、Linuxカーネル界に旋風を巻き起こしたフレームワークです。クラウドネイティブネットワークにおけるeBPFの可能性を認識したカーネルメンテナーによって開発され、CNCFプロジェクトのCiliumは現在、Google Kubernetes Engine、Amazon EKS Anywhere、Alibaba Cloudのデフォルトデータプレーンとして採用されています。
CiliumはeBPFを使用してカーネルのネットワーク機能をクラウドネイティブに拡張し、Kubernetesのアイデンティティを認識し、より効率的なデータパスを実現します。長年にわたり、Kubernetesネットワークインターフェースとして機能するCiliumは、負荷分散、可観測性、暗号化など、サービスメッシュの多くのコンポーネントを備えてきました。Kubernetesが分散オペレーティングシステムだとすれば、Ciliumはそのオペレーティングシステムの分散ネットワーク層です。Ciliumの機能を拡張してサービスメッシュのあらゆる機能をサポートすることは、それほど大きな飛躍ではありません。
Cilium の開発者であり、Isovalent の CTO 兼共同創設者である Thomas Graf 氏は、ブログ投稿で次のように述べています。
Cilium Service Meshの最初の安定版リリースにより、ユーザーはサイドカー機能を使用するか使用しないかを選択できるようになりました。どのモデルをいつ最適に活用するかは、オーバーヘッド、リソース管理、障害ドメイン、セキュリティ上の考慮事項など、さまざまな要因によって異なります。実際、そのトレードオフは仮想マシンとコンテナのトレードオフと非常によく似ています。仮想マシンはより厳密な分離を提供します。コンテナは軽量で、リソースを共有し、利用可能なリソースを公平に分配できます。そのため、コンテナは通常、デプロイメント密度を高めますが、そのトレードオフとして、セキュリティとリソース管理の課題が増大します。Cilium Service Meshでは、プラットフォームで両方のオプションを利用でき、さらにこれらを混在させて実行することも可能です。
クラウドネイティブインフラの未来はeBPF
Cilium プロジェクトのメンテナーの 1 人である Isovalent の最高オープンソース責任者 Liz Rice 氏は、Cilium への貢献者として Datadog、F5、Form3、Google、Isovalent、Microsoft、Seznam.cz、The New York Times などが挙げられますが、同氏はクラウド計測をカーネルに直接組み込むというこの変化がプラットフォーム エンジニアにとって画期的であると考えています。
「eBPFを使ってカーネル内にインストルメンテーションを組み込むと、仮想マシン上で起こっていることすべてを把握・制御できるため、アプリケーションのワークロードやその構成に変更を加える必要がありません」とライス氏は述べた。「クラウドネイティブの観点から見ると、セキュリティ保護と管理がはるかに容易になり、リソース効率も大幅に向上します。従来であれば、共通ライブラリやサイドカーコンテナを使って、すべてのアプリケーションを個別にインストルメンテーションする必要がありました。」
2000 年代にデータセンターを再定義した仮想化イノベーションの波は、主に VMware の単一ベンダー プラットフォームによって推進されました。
クラウドネイティブ・インフラストラクチャは、ベンダー間の競争がはるかに激しく、非常に細分化されています。しかし、eBPFにおけるIsovalentの実績は、ネットワークとセキュリティの抽象化に関する主要な懸念事項がカーネルにどのように再導入されるのかを注視する上で、非常に興味深い企業となっています。Ciliumのオリジナル開発者であるIsovalentのチームには、Linuxカーネルのメンテナーや、仮想化の決定的なネットワークプラットフォームであるNiciraの開発者として著名なAndreessen HorowitzのMartin Casado氏へのリードインベスターも含まれています。
仮想化が企業インフラを支配した10年、そしてコンテナとKubernetesが支配した10年を経て、私たちは今、新たな大きなイノベーションの波の瀬戸際にいるようです。興味深いことに、次のイノベーションの波は、私たちを再びLinuxカーネルの力へと導くかもしれません。
開示: 私は MongoDB で働いていますが、ここで表明されている意見は私自身のものです。
TechRepublic Academy のこのコースで Docker 認定を取得し、Kubernetes CKA 認定試験の勉強をしましょう。
