要約: 今年 9 月、Istio コミュニティは Ambient Mesh のオープン ソースを発表しました。これにより、国内外の多くの開発者の間で激しい議論が巻き起こりました。
この記事は、HUAWEI CLOUD コミュニティ「Deep Analysis! 」から共有されています。HUAWEI CLOUD クラウド ネイティブ チームによる、Istio 共有プロキシの新しいモードであるアンビエント メッシュ。
今年の 9 月、Istio コミュニティは Ambient Mesh のオープン ソースを発表し、国内外の多くの開発者の間で激しい議論が巻き起こりました。実際、 Istio TOC メンバーの linsun ( https://github.com/linsun )とのコミュニケーションを通じて、2021 年にはhttp://Solo.ioがエージェントの研究と設計の共有を開始したことを知りました。 2021 年には、Google も共有プロキシ モデルを社内で検討しています。そこで、両社は意気投合し、今年4月から5月にかけて共同開発により、シェアードエージェンシーモデルの開発を加速させた。
現在、Ambient Mesh はプレビュー バージョンをリリースしており、関心のある読者はオンデマンドで体験できます。スペースの制限により、この記事では主にアンビエント メッシュ アーキテクチャと 4 層のトラフィック管理プロセスの詳細な分析を行います.7 層のトラフィック管理の詳細な説明については、後続の記事を参照してください.
1.アンビエントメッシュとは
簡単に言うと、Ambient Mesh は、Istio サービス メッシュの共有プロキシの新しいモードです。これは、 Google と http://Solo.io が共同で開発した新しいデータ プレーンスキーマであり、操作を簡素化し、アプリケーションの互換性を向上させ、インフラストラクチャのコストを削減します。アンビエント モードでは、サイドカーを導入しなくても、Istio のコア機能であるゼロトラスト セキュリティ、トラフィック管理、テレメトリが維持されます。
2. アンビエント メッシュ アーキテクチャ分析
Ambient のアーキテクチャを始める前に、Istio のアーキテクチャを簡単に確認しましょう。主に、コントロール プレーンとデータ プレーンの 2 つの部分で構成されます。コントロール プレーン Istiod は、基本的な構成の生成とプッシュを実行し、すべてのデータ プレーンを管理します。サイドカー プロキシがデータ プレーンに導入され、アプリケーションのイングレス トラフィックとエグレス トラフィックを引き継ぎます。
図 1 Istio アーキテクチャ
Sidecar と比較して、Ambient Mesh は、より簡単なアップグレード管理を備えた、邪魔にならないオプションを提供します。Ambient は、Istio の機能を、セキュリティ オーバーレイ (4 層のガバナンス) と 7 層の処理層 (7 層のガバナンス) という 2 つの異なる層に分割します。
図 2 レイヤーに分割されたアンビエント メッシュ
•セキュリティ オーバーレイ レイヤ: TCP ルーティング、モニタリング インジケータ、アクセス ログ、mTLS トンネル、簡易認証を処理します •7 レイヤの処理レイヤ:セキュリティ オーバーレイ レイヤの機能に加えて、HTTP プロトコル ルーティング、モニタリング、アクセス ログ、呼び出しを提供しますchain、load バランシング、フュージング、電流制限、リトライなどのトラフィック管理機能と、豊富な 7 層の承認ポリシー
アンビエント メッシュのロードは、サイドカー モードのロードとシームレスに相互運用できるため、ユーザーは必要に応じて 2 つのモードを組み合わせて使用できます。
• 4 層のガバナンス アーキテクチャ:サイドカー モードでは、Istio は InitContainer または Istio-CNI を介してトラフィック インターセプトを実装します。Istio-CNI は、Ambient Mesh の下で必要なコンポーネントです. 次の図は、Ambient Mesh の基本的な 4 層のガバナンス構造を示しています。
図 3 アンビエント メッシュの 4 層ガバナンス アーキテクチャ
Istio-CNI では、Ambient 用の新しい処理モジュール が追加されました。これは、名前空間と Pod の変更を監視し、ノード上のアプリケーションのルーティングと iptables ルールを設定します。
• ルーティング:このノードのアプリケーションによって送信されたトラフィックを ztunnel にルーティングし、このノードによって受信されたトラフィックを ztunnel にルーティングするようにルーティング テーブルを設定します。
• iptables: ztunnel コンテナに iptables ルールを設定して、ztunnel に対応するポートへのトラフィックを透過的にインターセプトします。
ztunnel は、Ambient の新しく導入されたコンポーネントであり、Daemonset の形式で各ノードにデプロイされます。ztunnel は、メッシュ内のアプリケーション通信に mTLS、テレメトリ、認証、および L4 認可を提供し、レイヤー 7 プロトコル関連の処理は実行しません。コントロール プレーンは、ztunnel が同じワークロードを持つノードで実行されている場合にのみ、ワークロード証明書を ztunnel に発行します。したがって、ztunnel が攻撃された場合、ノードで実行されている負荷の証明書のみが盗まれる可能性があり、セキュリティ リスクは比較的制御可能です。これは、他の適切に実装されたノード共有インフラストラクチャと同様です。
• 7 層のトラフィック ガバナンス アーキテクチャ:現在、Ambient Mesh では、ゲートウェイ API リソースを定義することにより、サービスの 7 層処理を明示的に有効にする必要があります。次の図は、Ambient の 7 層のガバナンスのアーキテクチャを示しています。
図 4 アンビエント メッシュ 7 層のガバナンス アーキテクチャ
Ambient の 4 層のガバナンスと比較すると、7 層のガバナンス アーキテクチャにウェイポイント コンポーネントが追加されています。新しいウェイポイント処理モジュール が Pilotに追加されました。このモジュールは、ServiceAccount、Deployment、および Gateway API オブジェクトの変更を監視し、関連するウェイポイント オブジェクトを調整します。
• ServiceAccount が変更されると、Pilot は現在のネームスペース内のすべてのウェイポイントを更新しようとします.
• Deployment が変更されると、OwnerReference に関連付けられたゲートウェイ オブジェクトを介してウェイポイントのメンテナンスがトリガーされます.
• ゲートウェイが変更されると、関連付けられたウェイポイントプロキシが更新されました。
現在、Ambient は、ウェイポイント プロキシを作成するために、次のような Gateway API リソースに依存する必要があります。
apiVersion: gateway.networking.k8s.io/v1alpha2
kind: Gateway
metadata:
name: productpage
annotations:
istio.io/service-account: bookinfo-productpage
spec:
gatewayClassName: istio-meshgatewayClassName 値は istio-mesh に設定する必要があります。そうしないと、無視される可能性があります。各 ServiceAccount には、Sidecar モデルと同様に専用のウェイポイント プロキシがあります。追加のセキュリティ リスクを回避するために、各サービスは独自の個別の ID を使用することをお勧めします。
パイロットはレイヤー 7 およびレイヤー 7 トラフィック ルールを xDS を介してウェイポイント プロキシに更新し、レイヤー 7 関連のトラフィック ガバナンス機能を実装します。ウェイポイント プロキシは、サービスを提供しているワークロードと同じノード上にあるとは限りません。これにより、特定のパフォーマンスの問題が発生するようです。しかし、Istio の場合、遅延は複雑な 7 レイヤーの処理によるものであり、最終的なアンビエント モードの 7 レイヤー ガバナンスの遅延は、サイドカー モードの遅延に近いと予想されます。ウェイポイント エージェントは個別の展開を通じて展開されるため、必要な CPU とメモリを使用して個別に構成し、関連する HPA エラスティック スケーリング戦略を設定し、アプリケーションと結合しなくなり、より柔軟なスケーラビリティを提供し、リソースの使用を改善して、ある程度レート。
3. アンビエント メッシュの 4 層トラフィック管理
ztunnel は 4 層のトラフィック管理、4 層の負荷分散、TLS トラフィックの暗号化、基本的な認証と認証などしか実行できず、より高度な 7 層のルーティングと認証は実行できないことがわかっています。ここでは、スリープ アプリケーションを介して bookinfo にアクセスする例を使用して、アンビエント メッシュの 4 層のトラフィックがどのようにルーティングされるかを詳しく理解します。この例の実際の環境の背景は次のとおりです.sleep アプリケーションと productpage アプリケーションは、2 つの異なるノードで実行されています。
図 5 アンビエント メッシュの 4 層トラフィック プロキシ プロセス
• スリープ コンテナ内の productpage サービスにアクセスするには、リクエストは最初に同じノードの ztunnel にインターセプトされ、ztunnel は基本的な 4 層の負荷分散と TLS 暗号化と復号化を実行し、最後にターゲット インスタンス (の IP) を選択します。 productpage コンテナー) を使用してリクエストを転送します。
• このリクエストが productpage コンテナがあるノードに入ると、最初に TLS トラフィックの復号化を担当する ztunnel によって傍受され、次にユーザーが指定した認証ポリシーを実行し、最後にリクエストを productpage コンテナに送信します。
上記はアンビエント メッシュ トラフィック転送の基本的なプロセスです.特定の xDS 構成と組み合わせて、完全な通信プロセスを深く理解しましょう.
3.1 スリープ送信側のトラフィック処理
(1) sleep から productpage にアクセスするまでのトラフィックは、TPROXY (透過プロキシ) モードの同じノードのトンネルによって傍受され、ztunnel (127.0.0.1:15001 を監視) に転送されます. TPROXY を使用する利点は、元の宛先を保持することです.アドレスであり、ztunnel は転送のためにそれに依存する必要があります。元の宛先アドレス。
-A PREROUTING -i pistioout -p tcp -j TPROXY --on-port 15001 --on-ip 127.0.0.1 --tproxy-mark 0x400/0xfff(2) ztunnel は、「ztunnel_outbound」リスナーを介してポート 15001 でリッスンします。ztunnel_outbound リスナーは、Istio サイドカー モードのリスナーとはまったく異なり、このノード上のすべてのサービスからメッシュ全体の他のサービスへのフィルター チェーンが含まれています。
図 6 ztunnel_outbound リスナー
すべてのフィルタ チェーンに一致条件が設定されていないことがわかります (デフォルトではすべて一致)。では、ztunnel はトラフィックの特性に応じて対象のフィルタ チェーンをどのように選択するのでしょうか。また、リスナールートにフィルターのマッチング条件を設定する方法もあることがわかり、以下のマッチングにより、送信元アドレス10.244.1.4、宛先アドレス10.96.179.71、宛先ポート9080となります。 「spiffe://cluster.local/ns/default/sa/sleep_to_http_productpage.default.svc.cluster.local_outbound_internal」フィルター処理に引き継がれ、
図 7 ztunnel_outbound フィルター チェーンの一致
(3) 「spiffe://cluster.local/ns/default/sa/sleep_to_http_productpage.default.svc.cluster.local_outbound_internal」フィルターは、同じ名前のクラスターに関連付けられています。クラスタには合計 2 つのエンドポイント インスタンスが含まれています。エンドポイントは負荷分散アルゴリズムに従って選択されます。最も重要なことは、メタデータ (トンネルの宛先とアドレス) を名前 "outbound_tunnel_lis_spiffe://cluster.local" に渡すことです。 /ns/default/sa" /bookinfo-productpage のリスナー処理".
図 8 outbound_internal 内部クラスター構成
図 9 outbound_internal 内部クラスター エンドポイント
(4) 「outbound_tunnel_lis_spiffe://cluster.local/ns/default/sa/sleep」リスナーは、「set_dst_address」フィルターを使用して、前のステップで選択したエンドポイントのメタデータに従ってデータの宛先アドレスを設定します。前の outbound_internal クラスターがエンドポイント 10.244.2.8:9080 を選択した場合、ここのトンネル リスナーは宛先アドレスとして 10.244.2.8:15008 を設定します。さらに、リスナーには「outbound_tunnel_clus_spiffe://cluster.local/ns/default/sa/sleep」という名前のクラスターに関連付けられている TcpProxy が 1 つしかないため、トラフィックは自然にクラスターに引き渡されます。HTTP 接続トンネル (10.244.2.8:9080 に送信されるトラフィックを運ぶ) も、製品ページがあるノードの ztunnel で使用するために TCP フィルターに設定されます。HTTP トンネリングは、アンビエント メッシュ コンポーネント間の安全な通信のためのベアラー プロトコルです。
図 10 outbound_tunnel リスナーの構成
outbound_tunnel Cluster のタイプは「ORIGINAL_DST」であり、UpstreamTlsContext で構成されているため、トラフィックの TLS 暗号化を担当し、宛先アドレス 10.244.2.8:15008 に直接送信されます。
図 11 outbound_tunnel クラスター構成
3.2 商品ページ受信側トラフィック処理
(1) productpage(宛先アドレスは「10.244.2.8:15008」)にアクセスするsleepのトラフィックがproductpageのあるノードに到達し、TPROXY(透過プロキシ)によってztunnel(127.0.0.1:15008を監視)に傍受され、 TPROXY を使用する利点 元の宛先アドレスを保持し、ztunnel は転送時に元の宛先アドレスに依存する必要があります。
10.244.2.8 via 192.168.126.2 dev istioin table 100 src 10.244.2.1
-A PREROUTING -i pistioin -p tcp -m tcp --dport 15008 -j TPROXY --on-port 15008 --on-ip 127.0.0.1 --tproxy-mark 0x400/0xfff(2) ztunnel の「ztunnel_inbound」リスナーはポート 15008 でリッスンするため、トラフィックは最初に ztunnel_inbound リスナーによって処理されます。TLS は ztunnel_inbound リスナーで設定され、すべての ztunnel が相互 TLS 暗号化に基づいて通信するように、設定に従ってダウンストリームと TLS ハンドシェイクが実行されます。さらに、以下の構成からわかるように、CONNECT アップグレードが設定されているため、Envoy は HTTP Connect 要求をプロキシします。さらに、connectMatcher は RouteMatch で設定されます。これは、HTTP 接続要求が処理のために「virtual_inbound」クラスターに渡されることを意味します。
図 12 ztunnel_inbound リスナーの構成
(3) virtual_inbound クラスター タイプは ORIGINAL_DST であり、x-envoy-original-dst-host HTTP ヘッダーは元の宛先アドレスを書き換えるように設定されており、このヘッダーは送信側によって正確に定義されています "outbound_tunnel_lis_spiffe://cluster.local /ns/default/sa/sleep" リスナー設定を 10.244.2.8:9080 の値で設定します。したがって、このリクエストは、virtual_inbound を介して、productpage コンテナーに最終的に正常に送信されます。
図 13 virtual_inbound クラスター構成
3.3 アンビエント メッシュの 4 層トラフィック管理の概要
図 14 完全なサービス アクセスの 4 層プロキシ
製品ページにアクセスするスリープのインスタンスでは、HTTP プロトコルを使用しますが、すべてのアンビエント コンポーネントの観点からは、プロキシは TCP トラフィックです。先ほど、ztunnel の各リスナーと各クラスターの動作原理を深く分析しましたが、これは複雑に見えるかもしれません。したがって、ここで図 14 の簡単な要約を示します。通信のプロセスでは、実際に作業に参加するモジュールは多くないことがわかります。
- 送信側のルーティングと iptables: ztunnel のポート 15001 へのトラフィックを傍受する
- 送信側 ztunnel: 2 つのリスナーと 2 つの対応するクラスター
- 受信側のルーティングと iptables: ztunnel のポート 15008 へのトラフィックを傍受する
- ztunnel の受信: virtual_inbound リスナーと関連するクラスター
4. 今後の展望
Sidecar は Istio の機能の 1 つです。Sidecar を使用すると、サービス メッシュの利点を享受し、アプリケーションに非常に小さな変更を加えるだけで、運用と保守の負担を軽減できます。ただし、Sidecar モードにはいくつかの制限もあります。
- Intrusive: サイドカー コンテナーは、Admission Webhook の途中で注入され、アプリケーション コンテナーと同じ Pod に属しているため、サイドカーのアップグレードはビジネス コンテナーの再構築を伴う必要があります。アプリケーションの負荷を混乱させる可能性があります (たとえば、ローリング アップグレードは、長時間の接続シナリオでサージを引き起こす可能性があります)。
- 低いリソース使用率: サイドカーはアプリケーションに 1 対 1 で対応し、十分な CPU とメモリを予約する必要があるため、クラスター全体のリソース使用率が低くなる可能性があります。エラスティック スケーリングはワークロード全体に対してのみ実行でき、実行することはできません。サイドカーだけで。
- トラフィックの中断: トラフィックのキャプチャと HTTP 処理は Sidecar によって行われます。これはコストが高く、互換性のない HTTP 実装が壊れる可能性があります。
現在、Ambient Mesh は、サイドカー モードでのアプリケーションとサイドカーのデプロイ依存性の問題をうまく解決しており、サイドカーを挿入する必要がなくなりました。サービス メッシュの機能は、ztunnel とウェイポイント プロキシを介して提供され、アプリケーションとメッシュのデプロイとアップグレードが可能です。コンポーネントは簡単ではありません。
さらに、アンビエント共有モードは、グリッド コンポーネント自体のリソース オーバーヘッドを大幅に削減できます。これは、リソースに敏感なユーザーにとって大きなメリットです。
Ambient はまだプレビュー段階にあり、多くの機能はまだ開発中であり、多くの制限が公式ドキュメントに記載されています. さらに、コミュニティ ユーザーは、使用中に次のような新しい発見があります。
• IPV6 をサポートしていません
• Ambient によって作成された iptables が Calico と競合するため、Calico CNI と互換性がありません。
同時に、現在の envoy ベースの ztunnel は、xDS の効率性、マルチテナンシー、およびテレメトリのパフォーマンスに問題がある可能性があります. 将来的には、より軽量で高性能な ztunnel が錆に基づいて書き直される可能性があります.
長期的には、Sidecar モデルが Istio の主流モデルであり続けるでしょう。Ambient 共有モデルは、Istio コミュニティやサービス メッシュ業界に十分な刺激をもたらしました. コミュニティ内のすべての開発者の共同の努力に基づいて、Ambient 共有モデルは Istio の 2 番目の選択肢になると考えられています.
フォローをクリックして、HUAWEI CLOUDの新技術について初めて学びましょう〜