KubeCon Europe Microsoft は本日、バルセロナで開催された KubeCon のステージに登壇し、コンテナ対応テクノロジの周囲に急増しているメッシュ テクノロジに関する自社の見解を説明した。
サービスメッシュインターフェース（SMI）は、ますます分散化しているメッシュの世界に、少しの相互運用性をもたらす試みである。
メッシュは最近大流行している。The RegisterがKubeConで話を聞いた複数の人物は、メッシュ技術はかつては目新しいものだったが、ベンダーが協力してメッシュをうまく機能させる時期が来たと指摘した。
要約すると、サービスメッシュとは、分散アプリケーションの一部として構築されるコンテナとサービスのネットワークを指します。通信に必要なすべてのフック、接続、インフラストラクチャで構成されます。
高いスケーラビリティには、大きな管理上の問題が伴います。メッシュは規模が大きくなるにつれて複雑さが増していくからです。Istioなどの技術は、ネットワーク自体をよりスマートにすることでこの問題に対処するために存在します。サービスメッシュは、負荷分散やバージョン管理といった機能をコンポーネントに任せるのではなく、一連の管理APIを介してネットワークに委ねます。
これはすべて結構なことですが、サービス メッシュ テクノロジ ベンダーが登場するにつれて、通常は互換性のないさまざまな API も登場し、ユーザーは好みのテクノロジを選択しなければならなくなり、他の場所に移りたい場合にはロックインに直面することになります。
Solo.io、Hashicorp、Buoyant など、メッシュ志向の他の企業とともに Microsoft が推進している SMI が登場します。
Ingress に倣い、SMI は実装ではなく、サービスメッシュベンダーが構築する際に参照すべき共通 API のセットです。あるいは、SMI をネイティブ API に変換するレイヤーを作成することもできます。
クレーンに注意: Windows Server コンテナーが Azure Kubernetes Service にロードされる
続きを読む
理論的には、サービス メッシュが進化するにつれて、SMI によって実現される相互運用性により、ツールやユーティリティが既存のプロバイダーと統合することが、単に 1 つのテクノロジーを選択してそれが勝つと賭けるよりもかなり容易になります。
最初の SMI 仕様はトラフィックに重点を置き、ポリシーの適用、メトリックのキャプチャ、サービス間のトラフィックのシフトと重み付けを行います。
ボストンに拠点を置くSolo.ioの創業者兼CEOであるイディット・レヴィン氏は、 The Register紙のインタビューで、この技術は「おそらく今日のカンファレンスで起こる最大の出来事の一つ」と控えめに宣言しました。そして、「サービスメッシュは非常にホットな話題だから」と付け加えました。
まさにその通りです。Red Hat Open Shiftの責任者の一人であるブライアン・グレースリー氏は、「1年前はメッシュが主流でしたが、今はメッシュのパフォーマンスはどうなのか？クラウド間でメッシュをどう実現するのか？」という問題になっています。
15人のスタートアップ企業であるSolo.ioは、サービスメッシュ分野に強い知性を有しており、昨年はオープンソースのSuperGlooを発表しました。これは、異なるメッシュ間の一貫性を実現する抽象化レイヤーです。同社は先週、SuperGlooを拡張したService Mesh Hubを発表しました。これは、拡張機能カタログを介してメッシュと拡張機能をインストール・操作するためのダッシュボードを備えています。
ハブは、SMI 仕様のリファレンス実装です。
したがって、Microsoft がメッシュ メイトとしてこの企業を選んだことは、それほど驚くべきことではない。また、Windows の巨人の力を利用して、メッシュ プロバイダーにこの仕様を採用するよう奨励しても、Solo.io の Service Mesh Hub に悪影響はないだろう。
では、この標準規格の管理者は誰になるのだろうか？ Levine 氏によると、ベンダーは 1 社もない。「CNCF に委ねるつもりです。」
それで。®
