使者。 1. はじめに

こんにちは！これは、「Envoy とは何ですか？」「なぜ必要なのですか？」「どこから始めればよいですか？」という質問に答える短い記事です。

これは何ですか

EnvoyはC++で書かれたL4-L7ロードバランサーで、高パフォーマンスと可用性に重点を置いています。一方で、パフォーマンス面ではnginxやhaproxyとある程度類似しており、同等の性能を備えています。一方で、マイクロサービスアーキテクチャに重点を置いており、ZuulやTraefikといったJavaやGoベースのバランサーに劣らない機能を備えています。

haproxy/nginx/envoy の比較表。絶対的な真実を主張しているわけではありませんが、概要を示しています。

nginx
ハプロキシ
特使
トレフィク

githubのスター
11.2k/ミラー
1.1k/ミラー
12.4k
27.6k

書かれた
C
C
C + +
go

API
ノー
ソケットのみ/プッシュ
データプレーン/プル
プル

アクティブヘルスチェック
ノー
はい
はい
はい

オープントレース
外部プラグイン
ノー
はい
はい

JWT
外部プラグイン
ノー
はい
ノー

拡張
ルア/C
ルア/C
ルア/C++
ノー

何のために

これはまだ若いプロジェクトであり、多くのものが欠けており、初期アルファ版のものもあります。しかし 特使は、その若さゆえに急速に発展しており、すでに多くの興味深い機能を備えています。動的な構成、多数の既製のフィルター、独自のフィルターを作成するためのシンプルなインターフェースなどです。
適用領域はこれに従いますが、まず 2 つのアンチパターンがあります。

• 静的反動。

問題は、現時点では 特使 キャッシュはサポートされていない。Googleが試している 修正する時々それを実装するというアイデアです 特使 RFC準拠のあらゆる微妙な部分（ヘッダーの山）と、特定の実装のためのインターフェースの作成。しかし、まだアルファ版にも至っておらず、アーキテクチャは議論中だ。 PR オープン（この記事を書いている間にPRがマージされましたが、この点はまだ関連しています）。

その間、静的には nginx を使用してください。

• 静的構成。

使うことはできますが、 特使 そのために作られたものではありません。静的設定の可能性は明らかにされません。多くの点があります。

yamlで設定を編集すると、ミスを犯したり、開発者の冗長さを嘆いたり、nginx/haproxyの設定は構造化されていないものの、より簡潔だと思ったりするでしょう。それがポイントです。nginxとhaproxyの設定は手動で編集できるように作成されており、 特使 コードから生成するためのものです。設定全体は プロトブフproto ファイルから生成すると、間違いが起きにくくなります。

カナリアシナリオ、ブラックボックス展開など、多くのシナリオは通常、動的構成でのみ実装されます。静的構成では不可能だと言っているわけではありません。私たちは皆、これを行っています。しかし、そのためには、バランサーや、 特使 含む

Envoy が不可欠なタスク:

• 複雑で動的なシステムにおけるトラフィックの分散。これにはサービスメッシュも含まれますが、必ずしも唯一の手段ではありません。
• 分散トレース、複雑な認証、または利用可能なその他の機能の必要性 特使 すぐに使えるものや便利に実装されているものはなく、nginx/haproxy では lua と疑わしいプラグインに取り囲まれる必要があります。

どちらも必要に応じて高いパフォーマンスを提供するために利用できます。

これはどう動かすのですか

EnvoyはDockerイメージとしてバイナリのみで配布されています。このイメージには静的設定の例が既に含まれていますが、ここでは構造を理解するためだけに使用します。

envoy.yaml 静的設定

static_resources:
  listeners:
  - name: listener_0
    address:
      socket_address:
        protocol: TCP
        address: 0.0.0.0
        port_value: 10000
    filter_chains:
    - filters:
      - name: envoy.http_connection_manager
        typed_config:
          "@type": type.googleapis.com/envoy.config.filter.network.http_connection_manager.v2.HttpConnectionManager
          stat_prefix: ingress_http
          route_config:
            name: local_route
            virtual_hosts:
            - name: local_service
              domains: ["*"]
              routes:
              - match:
                  prefix: "/"
                route:
                  host_rewrite: www.google.com
                  cluster: service_google
          http_filters:
          - name: envoy.router
  clusters:
  - name: service_google
    connect_timeout: 0.25s
    type: LOGICAL_DNS
    # Comment out the following line to test on v6 networks
    dns_lookup_family: V4_ONLY
    lb_policy: ROUND_ROBIN
    load_assignment:
      cluster_name: service_google
      endpoints:
      - lb_endpoints:
        - endpoint:
            address:
              socket_address:
                address: www.google.com
                port_value: 443
    transport_socket:
      name: envoy.transport_sockets.tls
      typed_config:
        "@type": type.googleapis.com/envoy.api.v2.auth.UpstreamTlsContext
        sni: www.google.com

動的構成

どのような問題を探しているのでしょうか? 負荷がかかっている状態でバランサー構成を再起動するだけでは不十分で、「軽微な」問題が発生します。

• 構成の検証。

構成は大きくなる可能性があり、非常に大きくなる可能性があるため、一度にすべてをオーバーロードすると、どこかでエラーが発生する可能性が高くなります。

• 長寿命の接続。

新しいリスナーを初期化する際は、古いリスナーで実行されている接続に注意する必要があります。頻繁に変更が発生し、長時間接続されている場合、妥協点を見つける必要があります。こんにちは、nginx 上の Kubernetes Ingress です。

• アクティブなヘルスチェック。

アクティブなヘルスチェックがある場合は、トラフィックを送信する前に、新しい設定ですべてを再チェックする必要があります。アップストリームが多数ある場合は、この処理に時間がかかります。haproxyさん、こんにちは。

これはどのように解決されるのでしょうか 特使モデルプールに基づいて構成を動的にロードすることで、構成を複数の部分に分割し、変更されていない部分は再初期化せずに済みます。例えば、リスナーは再初期化にコストがかかり、変更頻度も低いため、このような処理が不要になります。

設定 特使 (上記のファイルから) 次のエンティティがあります。

• リスナー — 特定の IP/ポートでハングしているリスナー
• 仮想ホスト - ドメイン名による仮想ホスト
• route — バランスルール
• — バランスパラメータを持つアップストリームのグループ
• 終点 — アップストリームインスタンスアドレス

これらのエンティティとその他のエンティティは動的に入力できます。このため、設定を受け取るサービスのアドレスを設定で指定します。サービスはRESTまたはgRPCですが、gRPCの使用をお勧めします。

サービスはそれぞれLDS、VHDS、RDS、CDS、EDSと命名されています。静的構成と動的構成を組み合わせることは可能ですが、動的リソースを静的リソースに指定できないという制限があります。

ほとんどのタスクでは、最後の3つのサービスを実装するだけで十分です。これらはADS（Aggregated Discovery Service）と呼ばれ、 ジャワ Go には gRPC データプレーンの既成の実装があり、ソースからオブジェクトを入力するだけで済みます。

構成は次の形式になります。

envoy.yaml 動的構成

dynamic_resources:
  ads_config:
    api_type: GRPC
    grpc_services:
      envoy_grpc:
        cluster_name: xds_clr
  cds_config:
    ads: {}
static_resources:
  listeners:
  - name: listener_0
    address:
      socket_address:
        protocol: TCP
        address: 0.0.0.0
        port_value: 10000
    filter_chains:
    - filters:
      - name: envoy.http_connection_manager
        typed_config:
          "@type": type.googleapis.com/envoy.config.filter.network.http_connection_manager.v2.HttpConnectionManager
          stat_prefix: ingress_http
          rds:
            route_config_name: local_route
            config_source:
              ads: {}
          http_filters:
          - name: envoy.router
  clusters:
  - name: xds_clr
    connect_timeout: 0.25s
    type: LOGICAL_DNS
    dns_lookup_family: V4_ONLY
    lb_policy: ROUND_ROBIN
    load_assignment:
      cluster_name: xds_clr
      endpoints:
      - lb_endpoints:
        - endpoint:
            address:
              socket_address:
                address: xds
                port_value: 6565

実行時 特使 この設定により、コントロールプレーンに接続し、RDS、CDS、EDSの設定を要求しようとします。この相互作用プロセスがどのように発生するかについて説明します。 ここで.

要するに、 特使 要求されたリソースのタイプ、ノードのバージョン、パラメータを示すリクエストを送信します。レスポンスとして、リソースとバージョンを受信します。コントロールプレーン上のバージョンが変更されていない場合は、応答しません。
インタラクションには 4 つのオプションがあります。

• すべてのリソース タイプに対して 1 つの gRPC ストリームで、リソースの完全な状態が送信されます。
• 別々のストリーム、完全な状態。
• 1 つのストリーム、増分状態。
• 個別のストリーム、増分状態。

インクリメンタルxDSは、コントロールプレーンと 特使これは大規模な構成に関係します。ただし、リクエストは購読解除と購読のためのリソースのリストを送信するため、やり取りが複雑になります。

この例ではADSを使用します。これはRDS、CDS、EDS、非増分モードのそれぞれに1つのストリームです。増分モードを有効にするには、以下を指定する必要があります。 api_type: DELTA_GRPC

リクエストにはノード パラメータが含まれているため、インスタンスごとに異なるリソースをコントロール プレーンに送信できます。 特使これは、サービス メッシュの構築に便利です。

準備し始める

На 特使 起動時、またはコントロールプレーンから新しい設定を受信した際に、リソースウォームアッププロセスが開始されます。これは、リスナーウォームアップとクラスタウォームアップに分かれています。前者はRDS/LDSに変更があった場合に、後者はCDS/EDSに変更があった場合に起動されます。つまり、アップストリームのみが変更された場合、リスナーは再作成されません。

ウォームアップ中、コントロールプレーンからの依存リソースはタイムアウトまで待機されます。タイムアウトに達すると初期化は失敗し、新しいリスナーはポートのリッスンを開始しません。
初期化順序：EDS、CDS、アクティブヘルスチェック、RDS、LDS。アクティブヘルスチェックを有効にすると、1回のヘルスチェックが成功した場合にのみトラフィックがアップストリームに送信されます。

リスナーが再作成されると、古いリスナーは DRAIN 状態になり、すべての接続が閉じられるかタイムアウトが経過すると削除されます。 --drain-time-sデフォルトは10分です。

継続するために。

出所： habr.com