Admiral を使用したマルチクラスタ Istio の構成とサービスディスカバリ

単一メッシュとして動作する Istio デプロイメント（クラスタ）の Istio 構成の自動化。

2020年1月5日 | 執筆者: Anil Attuluri - Intuit、Jason Webb - Intuit

Intuit では、ブログ記事「分離と境界保護のためのマルチメッシュデプロイメント」を読み、そこで言及されている問題のいくつかにすぐに関連付けました。ブログ記事で説明されている複数のメッシュの連合ではなく、単一のマルチクラスタメッシュを構成したいと考えていましたが、同じ不均一な命名の問題が私たちの環境にも当てはまることに気付きました。このブログ記事では、GitHub の istio-ecosystem にあるオープンソースプロジェクトである Admiral を使用して、これらの問題をどのように解決したかを説明します。

背景

Istio を使用して、マルチクラスタの構成が複雑で、時間の経過とともに維持するのが難しいことに気付きました。その結果、スケーラビリティとその他の運用上の理由から、「複製されたコントロールプレーンを使用したマルチクラスタ Istio サービスメッシュ」で説明されているモデルを選択しました。このモデルに従うことで、Istio サービスメッシュを広く採用する前に、これらの重要な要件を解決する必要がありました。

すべてのクラスタでグローバルに一意の名前空間名を持つ 160 を超える Kubernetes クラスタがあります。この構成では、異なる名前の名前空間で実行されている異なるリージョンに同じサービスワークロードをデプロイできます。その結果、「マルチクラスタバージョンルーティング」で言及されているルーティング戦略に従うと、例の名前 foo.namespace.global はクラスタ全体で機能しません。それぞれ独自の Kubernetes FQDN で実行/アドレス指定可能な複数のクラスタ内のサービスインスタンスを解決する、グローバルに一意で検出可能なサービス DNS が必要でした。たとえば、foo が異なる名前の 2 つの Kubernetes クラスタで実行されている場合、foo.global は foo.uswest2.svc.cluster.local と foo.useast2.svc.cluster.local の両方を解決する必要があります。また、サービスには、異なる解決とグローバルルーティングプロパティを持つ追加の DNS 名が必要です。たとえば、foo.global は最初にローカルで解決してから、トポロジルーティングを使用してリモートインスタンスにルーティングする必要がありますが、foo-west.global と foo-east.global（テストに使用される名前）は常にそれぞれのリージョンに解決する必要があります。

コンテキスト構成

さらに調査した結果、構成はコンテキストに応じたものである必要があることが明らかになりました。各クラスタには、世界のビューに合わせて調整された構成が必要です。

たとえば、注文とレポートによって消費される支払いサービスがあるとします。支払いサービスは、us-east（クラスタ 3）と us-west（クラスタ 2）にわたって HA/DR デプロイメントされています。支払いサービスは、各リージョンで異なる名前の名前空間にデプロイされています。注文サービスは、us-west（クラスタ 1）の支払いとは異なるクラスタにデプロイされています。レポートサービスは、us-west（クラスタ 2）の支払いと同じクラスタにデプロイされています。

Example of calling a workload in Istio multicluster
Istio を使用したクラスタ間のワークロード通信

以下のクラスタ 1 とクラスタ 2 の支払いサービスの Istio ServiceEntry yaml は、他のサービスが支払いサービスを使用するために必要なコンテキスト構成を示しています。

クラスタ 1 のサービスエントリ

apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: payments.global-se
spec:
  addresses:
  - 240.0.0.10
  endpoints:
  - address: ef394f...us-east-2.elb.amazonaws.com
    locality: us-east-2
    ports:
      http: 15443
  - address: ad38bc...us-west-2.elb.amazonaws.com
    locality: us-west-2
    ports:
      http: 15443
  hosts:
  - payments.global
  location: MESH_INTERNAL
  ports:
  - name: http
    number: 80
    protocol: http
  resolution: DNS

クラスタ 2 のサービスエントリ

apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: payments.global-se
spec:
  addresses:
  - 240.0.0.10
  endpoints:
  - address: ef39xf...us-east-2.elb.amazonaws.com
    locality: us-east-2
    ports:
      http: 15443
  - address: payments.default.svc.cluster.local
    locality: us-west-2
    ports:
      http: 80
  hosts:
  - payments.global
  location: MESH_INTERNAL
  ports:
  - name: http
    number: 80
    protocol: http
  resolution: DNS

クラスタ 2 のレポートサービスの観点からの支払い ServiceEntry（Istio CRD）は、ローカル Kubernetes FQDN を指す地域 us-west と、クラスタ 3 の istio-ingressgateway（ロードバランサ）を指す地域 us-east を設定します。クラスタ 1 の注文サービスの観点からの支払い ServiceEntry は、クラスタ 2 の istio-ingressgateway を指す地域 us-west と、クラスタ 3 の istio-ingressgateway を指す地域 us-east を設定します。

しかし、さらに複雑な場合があります。us-west での計画メンテナンスのために、支払いサービスがトラフィックを us-east リージョンに移動したい場合はどうでしょうか？これには、支払いサービスがすべてのクライアントのクラスタで Istio 構成を変更する必要があります。これは、自動化なしではほぼ不可能です。

Admiral の救済：Admiral はその自動化です

Admiral は、Istio コントロールプレーンのコントローラです。

Example of calling a workload in Istio multicluster with Admiral
Istio と Admiral を使用したクラスタ間のワークロード通信

Admiral は、複数のクラスタにまたがる Istio メッシュが単一メッシュとして動作するように、複数のクラスタで実行されているワークロードをサービスに関連付ける一意のサービス識別子に基づいて自動構成を提供します。また、クラスタ間での Istio 構成の自動プロビジョニングと同期も提供します。これにより、開発者とメッシュオペレータの負担が軽減され、少数のクラスタを超えてスケールアップできます。

Admiral CRD

グローバルトラフィックルーティング

Admiral のグローバルトラフィックポリシー CRD を使用すると、支払いサービスはリージョントラフィックの重みを更新でき、Admiral は支払いサービスを消費するすべてのクラスタの Istio 構成を更新します。

apiVersion: admiral.io/v1alpha1
kind: GlobalTrafficPolicy
metadata:
  name: payments-gtp
spec:
  selector:
    identity: payments
  policy:
  - dns: default.payments.global
    lbType: 1
    target:
    - region: us-west-2/*
      weight: 10
    - region: us-east-2/*
      weight: 90

上記の例では、支払いサービストラフィックの 90% が us-east リージョンにルーティングされます。このグローバルトラフィック構成は、Istio 構成に自動的に変換され、Kubernetes クラスタにコンテキストに応じてマッピングされて、メッシュ内のクライアントの支払いサービスのマルチクラスタグローバルルーティングを有効にします。

このグローバルトラフィックルーティング機能は、Istio 1.5 以降で使用可能なサービスごとの Istio の地域ロードバランシングに依存しています。

依存関係

Admiral Dependency CRD を使用すると、サービス識別子に基づいてサービスの依存関係を指定できます。これにより、Admiral で生成された構成の配信が、サービスの依存クライアントが実行されている必要なクラスタのみに最適化されます（すべてのクラスタに書き込む代わりに）。Admiral は、クライアントのワークロード名前空間で Sidecar Istio CRD を構成および/または更新して、Istio 構成をその依存関係のみに制限します。他の場所に記録されたサービス間の承認情報を使用して、Admiral が使用するこの dependency レコードを生成します。

orders サービスの dependency の例

apiVersion: admiral.io/v1alpha1
kind: Dependency
metadata:
  name: dependency
  namespace: admiral
spec:
  source: orders
  identityLabel: identity
  destinations:
  - payments

Dependency はオプションであり、サービスの依存関係がない場合、そのサービスの Istio 構成がすべてのクラスタにプッシュされます。

まとめ

Admiral は、新しいグローバルトラフィックルーティングと一意のサービス命名機能を提供し、「複製されたコントロールプレーンを使用したマルチクラスタデプロイメント」で説明されている Istio モデルによってもたらされるいくつかの課題に対処します。クラスタ間の 手動構成同期 の必要性をなくし、各クラスタのコンテキスト構成を生成します。これにより、多数の Kubernetes クラスタで構成されるサービスメッシュを運用することが可能になります。

Istio/サービスメッシュコミュニティはこのアプローチから利益を得られると考えているため、Admiral をオープンソース化しました。皆様からのフィードバックとサポートをお待ちしております！

この記事を共有する