Istio アンビエント・ウェイポイント・プロキシをシンプルに

シンプルさとスケーラビリティを実現する新しい宛先指向のウェイポイント・プロキシをご紹介します。

2023年3月31日 | Lin Sun - Solo.io、John Howard - Google

アンビエントはIstioの機能を、セキュアなオーバーレイ層とレイヤー7処理層の2つの異なる層に分割します。ウェイポイント・プロキシは、Envoyベースのオプションコンポーネントであり、管理するワークロードのL7処理を処理します。2022年の最初のアンビエントのローンチ以降、ウェイポイントの設定、デバッグ、スケーラビリティを簡素化するために大幅な変更を加えています。

ウェイポイント・プロキシのアーキテクチャ

サイドカーと同様に、ウェイポイント・プロキシもEnvoyベースであり、アプリケーションの設定を提供するためにIstioによって動的に構成されます。ウェイポイント・プロキシのユニークな点は、名前空間ごと（デフォルト）またはサービスアカウントごとに実行されることです。アプリケーションポッドの外で実行されるため、ウェイポイント・プロキシはアプリケーションとは独立してインストール、アップグレード、スケーリングでき、運用コストを削減できます。

ウェイポイント・プロキシは、Kubernetes Gatewayリソースまたは便利なistioctlコマンドを使用して宣言的にデプロイされます。

$ istioctl experimental waypoint generate
apiVersion: gateway.networking.k8s.io/v1beta1
kind: Gateway
metadata:
  name: namespace
spec:
  gatewayClassName: istio-waypoint
  listeners:
  - name: mesh
    port: 15008
    protocol: HBONE

Istiodはこれらのリソースを監視し、ユーザーのために対応するウェイポイントデプロイメントを自動的にデプロイおよび管理します。

ソースプロキシ設定を宛先プロキシに移行

既存のサイドカーアーキテクチャでは、ほとんどのトラフィックシェーピング（例：リクエストルーティングやトラフィックシフト、フォールトインジェクション）ポリシーはソース（クライアント）プロキシによって実装され、ほとんどのセキュリティポリシーは宛先（サーバー）プロキシによって実装されます。これにより、いくつかの問題が発生します。

スケーリング - 各ソースサイドカーは、メッシュ内の他のすべての宛先に関する情報を認識する必要があります。これは多項式スケーリングの問題です。さらに悪いことに、宛先の構成が変更されると、すべてのサイドカーに一度に通知する必要があります。
デバッグ - ポリシーの適用がクライアントとサーバーのサイドカーの間で分割されているため、トラブルシューティング時にシステムの動作を理解するのが困難になる可能性があります。
混在環境 - クライアントの一部がメッシュに含まれていないシステムがある場合、動作が不整合になります。たとえば、非メッシュクライアントはカナリアロールアウトポリシーを尊重せず、予期しないトラフィック分散につながります。
所有権と帰属 - 理想的には、1つの名前空間で記述されたポリシーは、同じ名前空間で実行されているプロキシによって実行された作業のみに影響を与える必要があります。しかし、このモデルでは、それは分散され、各サイドカーによって適用されます。Istioはこの制約に合わせて設計され、安全性を確保していますが、それでも最適ではありません。

アンビエントでは、すべてのポリシーは宛先ウェイポイントによって適用されます。多くの場合、ウェイポイントは名前空間（デフォルトスコープ）またはサービスアカウントへのゲートウェイとして機能します。Istioは、名前空間に入るすべてのトラフィックがウェイポイントを通過し、その名前空間のすべてのポリシーを適用することを強制します。このため、各ウェイポイントは、自身の名前空間の構成のみを知る必要があります。

特に、大規模クラスタで実行しているユーザーにとって、スケーラビリティの問題は厄介です。視覚化すると、新しいアーキテクチャがどれほど大きな改善であるかがわかります。

2つの名前空間があり、それぞれに2つの（色分けされた）デプロイメントがある単純なデプロイメントを検討します。サイドカーをプログラムするために必要なEnvoy（XDS）構成は、円で示されています。

Every sidecar has configuration about all other sidecars — 各サイドカーには、他のすべてのサイドカーに関する構成があります。

サイドカーモデルでは、4つのワークロードがあり、それぞれに4つの構成セットがあります。これらの構成のいずれかが変更された場合、すべてを更新する必要があります。合計で16個の構成が分散されています。

しかし、ウェイポイントアーキテクチャでは、構成が劇的に簡素化されます。

Each waypoint only has configuration for its own namespace — 各ウェイポイントには、自身の名前空間の構成のみがあります。

ここでは、まったく異なる状況が見られます。各ウェイポイントは名前空間全体を提供できるため、ウェイポイントプロキシは2つだけです。それぞれが自身の名前空間の構成のみを必要とするためです。単純な例でも、送信される構成の量は25％です。

各名前空間を25個のデプロイメント（それぞれ10個のポッド）にスケールアップし、高可用性のために各ウェイポイントデプロイメントに2個のポッドを使用すると、その数値はさらに印象的です。下表に示すように、ウェイポイント構成の分散は、サイドカーの構成分散のわずか0.8％しか必要ありません！

構成分散	名前空間1	名前空間2	合計
サイドカー	25個の構成 * 250個のサイドカー	25個の構成 * 250個のサイドカー	12500
ウェイポイント	25個の構成 * 2個のウェイポイント	25個の構成 * 2個のウェイポイント	100
ウェイポイント / サイドカー	0.8%	0.8%	0.8%

上記の簡素化を説明するために名前空間スコープのウェイポイントプロキシを使用していますが、サービスアカウントウェイポイントプロキシに適用した場合も、簡素化は同様です。

この構成の削減は、コントロールプレーンとデータプレーンの両方で、リソースの使用量（CPU、RAM、およびネットワーク帯域幅）の削減を意味します。今日のユーザーは、IstioネットワーキングリソースのexportToまたはSidecarAPIを注意深く使用することで同様の改善を見ることができますが、アンビエントモードではこれ以上必要なくなり、スケーリングが容易になります。

宛先にウェイポイントプロキシがない場合はどうなりますか？

アンビエントモードの設計は、ほとんどの構成はサービスコンシューマーではなくサービスプロデューサーによって実装するのが最適であるという仮定に基づいています。ただし、常にそうとは限りません。制御できない宛先のトラフィック管理を構成する必要がある場合があります。一般的な例としては、時折の接続の問題に対処するために回復性を向上させた外部サービスへの接続があります（例：example.comへの呼び出しにタイムアウトを追加します）。

これはコミュニティで積極的に開発されている分野であり、トラフィックをエグレスゲートウェイにルーティングする方法と、目的のポリシーを使用してエグレスゲートウェイを構成する方法を設計しています。この分野の今後のブログ投稿にご期待ください！

ウェイポイント設定の詳細

アンビエント入門ガイドをトラフィック制御セクションまで完了した場合、bookinfo-reviewsサービスアカウントのウェイポイントプロキシをデプロイして、90％のトラフィックをreviews v1に、10％のトラフィックをreviews v2にリダイレクトしています。

istioctlを使用して、reviewsウェイポイントプロキシのリッスナを取得します。

$ istioctl proxy-config listener deploy/bookinfo-reviews-istio-waypoint --waypoint
LISTENER              CHAIN                                                 MATCH                                         DESTINATION
envoy://connect_originate                                                       ALL                                           Cluster: connect_originate
envoy://main_internal inbound-vip|9080||reviews.default.svc.cluster.local-http  ip=10.96.104.108 -> port=9080                 Inline Route: /*
envoy://main_internal direct-tcp                                            ip=10.244.2.14 -> ANY                         Cluster: encap
envoy://main_internal direct-tcp                                            ip=10.244.1.6 -> ANY                          Cluster: encap
envoy://main_internal direct-tcp                                            ip=10.244.2.11 -> ANY                         Cluster: encap
envoy://main_internal direct-http                                           ip=10.244.2.11 -> application-protocol='h2c'  Cluster: encap
envoy://main_internal direct-http                                           ip=10.244.2.11 -> application-protocol='http/1.1' Cluster: encap
envoy://main_internal direct-http                                           ip=10.244.2.14 -> application-protocol='http/1.1' Cluster: encap
envoy://main_internal direct-http                                           ip=10.244.2.14 -> application-protocol='h2c'  Cluster: encap
envoy://main_internal direct-http                                           ip=10.244.1.6 -> application-protocol='h2c'   Cluster: encap
envoy://main_internal direct-http                                           ip=10.244.1.6 -> application-protocol='http/1.1'  Cluster: encap
envoy://connect_terminate default                                               ALL                                           Inline Route:

デフォルトではIstioのインバウンドHBONEポートであるポート15008に到着するリクエストに対して、ウェイポイントプロキシはHBONE接続を終了し、リクエストをmain_internalリッスナに転送して、AuthorizationPolicyなどのワークロードポリシーを適用します。内部リッスナに慣れていない場合、それらはシステムネットワークAPIを使用せずにユーザー空間接続を受け入れるEnvoyリッスナです。上記のistioctl proxy-configコマンドに追加された--waypointフラグは、main_internalリッスナの詳細、そのフィルタチェーン、チェーンマッチ、および宛先を表示するように指示します。

10.96.104.108はreviewsのサービスVIPであり、10.244.x.xはreviewsのv1/v2/v3ポッドIPです。kubectl get svc,pod -o wideコマンドを使用してクラスタで確認できます。プレーンテキストまたはHBONE終了インバウンドトラフィックの場合、reviewsの場合はサービスVIPとポート9080で、またはポッドIPアドレスとアプリケーションプロトコル（ANY、h2c、またはhttp/1.1）でマッチングされます。

reviewsウェイポイントプロキシのクラスタを確認すると、いくつかのインバウンドクラスタとともにmain_internalクラスタが取得されます。インフラストラクチャのクラスタを除いて、作成されるEnvoyクラスタは、同じサービスアカウントで実行されているサービスとポッド用だけです。他の場所で実行されているサービスまたはポッドのクラスタは作成されません。

$ istioctl proxy-config clusters deploy/bookinfo-reviews-istio-waypoint
SERVICE FQDN                         PORT SUBSET  DIRECTION   TYPE         DESTINATION RULE
agent                                -    -       -           STATIC
connect_originate                    -    -       -           ORIGINAL_DST
encap                                -    -       -           STATIC
kubernetes.default.svc.cluster.local 443  tcp     inbound-vip EDS
main_internal                        -    -       -           STATIC
prometheus_stats                     -    -       -           STATIC
reviews.default.svc.cluster.local    9080 http    inbound-vip EDS
reviews.default.svc.cluster.local    9080 http/v1 inbound-vip EDS
reviews.default.svc.cluster.local    9080 http/v2 inbound-vip EDS
reviews.default.svc.cluster.local    9080 http/v3 inbound-vip EDS
sds-grpc                             -    -       -           STATIC
xds-grpc                             -    -       -           STATIC
zipkin                               -    -       -           STRICT_DNS

istioctl proxy-config cluster deploy/bookinfo-reviews-istio-waypoint --direction outboundを使用して確認できる、リストにoutboundクラスタがないことに注意してください！良い点は、他のbookinfoサービス（例：productpageまたはratingsサービス）でexportToを構成する必要がなかったことです。つまり、reviewsウェイポイントは、ユーザーからの追加の手動構成なしに、不要なクラスタを認識しません。

reviewsウェイポイントプロキシのルートのリストを表示します。

$ istioctl proxy-config routes deploy/bookinfo-reviews-istio-waypoint
NAME                                                    DOMAINS MATCH              VIRTUAL SERVICE
encap                                                   *       /*
inbound-vip|9080|http|reviews.default.svc.cluster.local *       /*                 reviews.default
default

IstioネットワーキングリソースでSidecarリソースやexportTo構成を構成していないことを思い出してください。ただし、bookinfo-productpageルートをデプロイしてイングレスゲートウェイをproductpageにルーティングするように構成しましたが、reviewsウェイポイントは、そのような無関係なルートを認識していません。

inbound-vip|9080|http|reviews.default.svc.cluster.localルートの詳細情報を表示すると、トラフィックの90％をreviews v1に、10％をreviews v2にリダイレクトする重み付けベースのルーティング構成と、Istioのデフォルトの再試行とタイムアウト構成の一部が表示されます。これは、前に説明したように、トラフィックと回復力に関するポリシーがソースから宛先指向のウェイポイントに移行されたことを確認します。

$ istioctl proxy-config routes deploy/bookinfo-reviews-istio-waypoint --name "inbound-vip|9080|http|reviews.default.svc.cluster.local" -o yaml
- name: inbound-vip|9080|http|reviews.default.svc.cluster.local
 validateClusters: false
 virtualHosts:
 - domains:
   - '*'
   name: inbound|http|9080
   routes:
   - decorator:
       operation: reviews:9080/*
     match:
       prefix: /
     metadata:
       filterMetadata:
         istio:
           config: /apis/networking.istio.io/v1alpha3/namespaces/default/virtual-service/reviews
     route:
       maxGrpcTimeout: 0s
       retryPolicy:
         hostSelectionRetryMaxAttempts: "5"
         numRetries: 2
         retriableStatusCodes:
         - 503
         retryHostPredicate:
         - name: envoy.retry_host_predicates.previous_hosts
           typedConfig:
             '@type': type.googleapis.com/envoy.extensions.retry.host.previous_hosts.v3.PreviousHostsPredicate
         retryOn: connect-failure,refused-stream,unavailable,cancelled,retriable-status-codes
       timeout: 0s
       weightedClusters:
         clusters:
         - name: inbound-vip|9080|http/v1|reviews.default.svc.cluster.local
           weight: 90
         - name: inbound-vip|9080|http/v2|reviews.default.svc.cluster.local
           weight: 10

reviewsウェイポイントプロキシのエンドポイントを確認します。

$ istioctl proxy-config endpoints deploy/bookinfo-reviews-istio-waypoint
ENDPOINT                                            STATUS  OUTLIER CHECK CLUSTER
127.0.0.1:15000                                     HEALTHY OK            prometheus_stats
127.0.0.1:15020                                     HEALTHY OK            agent
envoy://connect_originate/                          HEALTHY OK            encap
envoy://connect_originate/10.244.1.6:9080           HEALTHY OK            inbound-vip|9080|http/v2|reviews.default.svc.cluster.local
envoy://connect_originate/10.244.1.6:9080           HEALTHY OK            inbound-vip|9080|http|reviews.default.svc.cluster.local
envoy://connect_originate/10.244.2.11:9080          HEALTHY OK            inbound-vip|9080|http/v1|reviews.default.svc.cluster.local
envoy://connect_originate/10.244.2.11:9080          HEALTHY OK            inbound-vip|9080|http|reviews.default.svc.cluster.local
envoy://connect_originate/10.244.2.14:9080          HEALTHY OK            inbound-vip|9080|http/v3|reviews.default.svc.cluster.local
envoy://connect_originate/10.244.2.14:9080          HEALTHY OK            inbound-vip|9080|http|reviews.default.svc.cluster.local
envoy://main_internal/                              HEALTHY OK            main_internal
unix://./etc/istio/proxy/XDS                        HEALTHY OK            xds-grpc
unix://./var/run/secrets/workload-spiffe-uds/socket HEALTHY OK            sds-grpc

defaultおよびistio-system名前空間に他のサービスがいくつかあるにもかかわらず、reviews以外のサービスに関連するエンドポイントは取得されません。

まとめ

宛先指向のウェイポイントプロキシに焦点を当てたウェイポイントの簡素化に非常に興奮しています。これは、Istioの使いやすさ、スケーラビリティ、デバッグ可能性（Istioのロードマップの最優先事項）を簡素化するための、もう1つの重要なステップです。入門ガイドに従って、今日のアンビエントアルファビルドを試して、簡素化されたウェイポイントプロキシを体験してください！