web-dev-qa-db-ja.com

Istioおよび（または）Nginx Ingress Controller

私はIstioをテストする旅に出ており、現在、トラフィックのルーティングの「カナリア」機能をテストしようとしています。

私のテストでは、5つのマイクロサービス（serviceA、serviceB、serviceC、serviceD、serviceE）で構成される小さなservicemeshを作成しました。それぞれが他の人を呼び出すことができます。 A、E、C、B、B、Dのようなパスを渡すだけで、リクエストはこのパスに従います。クラスターの外部からservicemeshを呼び出すために、serviceAポッドを指すIngressルールでNginx Ingress Controllerがあります

これは正常に動作しています。

私が直面している問題は、次のようなカスタムヘッダーマッチングを使用したトラフィックスイッチングに関係しています。

kind: VirtualService
metadata:
  name: ServiceA
  namespace: demo
  labels:
    app: demo
spec:
  hosts:
  - service-a
  http:
  - route:
    - destination:
        Host: service-a
        subset: v1
  - match:
    - headers:
        x-internal-request:
          exact: true
    route:
    - destination:
        Host: service-a
        subset: v2

したがって、ここでは、カスタムヘッダーx-internal-requestをtrueに設定したときに、トラフィックをServiceAのv2バージョンにルーティングしようとしています。

質問：

  • この機能を使用するために、サービスはx-internal-headerを認識している必要があり、リクエストの次のサービスに渡す必要がありますか？または、Istioが彼らのために仕事をするので、彼らはそれに対処する必要はありませんか？

  • この機能を使用するには、Nginx Ingress Controllerの代わりにIstio Ingress Controller（Istio Gatewayを使用）を使用する必要がありますか？

今日、私はNginx Ingress Controllerを使用して自分のサービスの一部を公開しています。 Nginxを選択したのは、「外部認証」のようないくつかの機能があり、多くの作業を節約できるためです。代わりにIstio Ingressコントローラを使用する必要がある場合、Nginxと同じ機能を提供しているとは思いません。

たぶん私には見えない真ん中の道がある

ご協力ありがとうございました

istionginx-ingress
4
Fred Mériot

Istioは、各ポッドにデプロイされたEnvoyをsidecarsとして使用して、サービスメッシュ内のマイクロサービス間のネットワークトラフィックをインターセプトおよびプロキシするように設計されています。

Envoyを介したリクエストとレスポンスのHTTP headersでも操作できます。公式の Documentation によると、カスタムヘッダーを次の順序で要求/応答に追加できます：加重クラスターレベルヘッダー、ルートレベルヘッダー、仮想ホストレベルヘッダー、最後にグローバルレベルヘッダー。 Envoyプロキシはsidecarとして関連する各サービスポッドにデプロイされるため、カスタムHTTP headerは各リクエストまたはレスポンスに渡す必要があります。

Istioメッシュサービスで監視およびルーティングルール機能を有効にするために一般的に使用されるコアコンポーネントIstio Gatewayで Istio Ingress Controller を使用することをお勧めします。

メッシュサービスでのNginx Ingress controllerの実装とルーティングリクエストの問題について GitHub で開かれた問題がありました。

5
mk_sta