Istioを使用したサービスメッシュアーキテクチャ

1. 序章

このチュートリアルでは、サービスメッシュアーキテクチャの基本を理解し、それが分散システムアーキテクチャをどのように補完するかを理解します。

主に、サービスメッシュの実装であるIstioに焦点を当てます。その過程で、Istioのコアアーキテクチャについて説明し、Kubernetesでそれを活用する方法を理解します。

2. サービスメッシュとは何ですか？

過去数十年にわたって、モノリシックアプリケーションがどのように小さなアプリケーションに分解され始めたかを見てきました。 クラウドネイティブコンピューティングおよびマイクロサービスアーキテクチャで前例のない人気を博しています。さらに、Dockerのようなコンテナ化テクノロジーとKubernetesのようなオーケストレーションシステムは、この点でのみ役立ちました。

Kubernetesのような分散システムにマイクロサービスアーキテクチャを採用することには多くの利点がありますが、複雑さのかなりの部分があります。分散サービスは相互に通信する必要があるため、検出、ルーティング、再試行、およびフェイルオーバーについて検討する必要があります。

セキュリティや可観測性など、他にもいくつか注意が必要な懸念事項があります。

現在、各サービス内でこれらの通信機能を構築することは非常に面倒な場合があります。サービスランドスケープが成長し、通信が複雑になると、さらに面倒になります。これはまさにサービスメッシュが私たちを助けることができるところです。基本的に、サービスメッシュは、分散ソフトウェアシステム内のすべてのサービス間通信を管理する責任を取り除きます。

サービスメッシュがそれを実行できる方法は、一連のネットワークプロキシを介したものです。基本的に、サービス間の要求は、サービスと並行して実行されるが、インフラストラクチャ層の外部にあるプロキシを介してルーティングされます。

これらのプロキシは、基本的にサービスのメッシュネットワークを作成します。そのため、サービスメッシュという名前が付けられています。これらのプロキシを介して、サービスメッシュはサービス間通信のあらゆる側面を制御できます。そのため、これを使用して、分散コンピューティングの8つの誤り、分散アプリケーションについてよくある誤った仮定を説明する一連のアサーションに対処できます。

3. サービスメッシュの機能

ここで、サービスメッシュが提供できる機能のいくつかを理解しましょう。実際の機能のリストは、サービスメッシュの実装によって異なることに注意してください。ただし、一般的に、すべての実装でこれらの機能のほとんどを期待する必要があります。

これらの機能は、トラフィック管理、セキュリティ、および可観測性の3つのカテゴリに大きく分けることができます。

3.1. 交通管理

サービスメッシュの基本的な機能の1つは、トラフィック管理です。これには、動的なサービス検出とルーティングが含まれます。また、は、トラフィックシャドウイングやトラフィック分割などのいくつかの興味深いユースケースを可能にします。これらは、カナリアリリースとA/Bテストの実行に非常に役立ちます。

すべてのサービス間通信はサービスメッシュによって処理されるため、はいくつかの信頼性機能も有効にします。たとえば、サービスメッシュは、再試行、タイムアウト、レート制限、および回路ブレーカーを提供できます。これらのすぐに使用可能な障害回復機能により、通信の信頼性が高まります。

3.2. 安全

サービスメッシュは通常、サービス間通信のセキュリティ面も処理します。これには、相互TLS（MTLS）によるトラフィック暗号化の実施、証明書検証による認証の提供、およびアクセスポリシーによる承認の保証が含まれます。

サービスメッシュには、セキュリティの興味深いユースケースもいくつかあります。たとえば、ネットワークセグメンテーションを実現して、一部のサービスが通信できるようにし、他のサービスは禁止することができます。さらに、サービスメッシュは、要件を監査するための正確な履歴情報を提供できます。

3.3. 可観測性

堅牢な可観測性は、分散システムの複雑さを処理するための基盤となる要件です。サービスメッシュはすべての通信を処理するため、可観測性機能を提供するために適切に配置されます。たとえば、分散トレースに関する情報を提供できます。

サービスメッシュは、遅延、トラフィック、エラー、飽和度などの多くのメトリックを生成できます。さらに、サービスメッシュはアクセスログを生成して、各リクエストの完全なレコードを提供することもできます。これらは、システム全体だけでなく、個々のサービスの動作を理解するのに非常に役立ちます。

4. Istioの紹介

Istio は、元々IBM、Google、Lyftによって開発されたサービスメッシュのオープンソース実装です。分散アプリケーションに透過的に階層化し、トラフィック管理、セキュリティ、可観測性などのサービスメッシュのすべての利点を提供できます。

オンプレミス、クラウドホスト、Kubernetesコンテナ、仮想マシンで実行されているサービサーなど、さまざまなデプロイで動作するように設計されています。 Istioはプラットフォームに依存しないですが、Kubernetesプラットフォームにデプロイされたマイクロサービスと一緒に使用されることがよくあります。

基本的に、Istioは、Envoyの拡張バージョンをプロキシとしてすべてのマイクロサービスにサイドカーとしてデプロイすることで機能します。

このプロキシのネットワークは、Istioアーキテクチャのデータプレーンを構成します。これらのプロキシの構成と管理は、コントロールプレーンから実行されます。

コントロールプレーンは、基本的にサービスメッシュの頭脳です。実行時にデータプレーン内のEnvoyプロキシに検出、構成、および証明書管理を提供します。

もちろん、相互に通信するマイクロサービスが多数ある場合にのみ、Istioのメリットを実感できます。ここで、サイドカープロキシは、専用のインフラストラクチャレイヤーで複雑なサービスメッシュを形成します。

Istioは、外部のライブラリやプラットフォームとの統合に関して非常に柔軟性があります。たとえば、Istioを外部のロギングプラットフォーム、テレメトリ、またはポリシーシステムと統合できます。

5. Istioコンポーネントを理解する

Istioアーキテクチャは、データプレーンとコントロールプレーンで構成されていることを確認しました。さらに、Istioが機能することを可能にするいくつかのコアコンポーネントがあります。

このセクションでは、これらのコアコンポーネントの詳細について説明します。

5.1. データプレーン

Istioのデータプレーンは、主にEnvoyプロキシの拡張バージョンで構成されています。 Envoyは、ネットワークの懸念を基盤となるアプリケーションから切り離すのに役立つオープンソースのエッジおよびサービスプロキシです。アプリケーションは、ネットワークトポロジの知識がなくても、localhostとの間でメッセージを送受信するだけです。

コアとなるEnvoyは、OSIモデルのL3層とL4層で動作するネットワークプロキシです。 は、プラグ可能なネットワークフィルターのチェーンを使用して接続処理を実行することで機能します。さらに、Envoyは、HTTPベースのトラフィック用に追加のL7レイヤーフィルターをサポートしています。さらに、EnvoyはHTTP/2およびgRPCトランスポートをファーストクラスでサポートしています。

Istioがサービスメッシュとして提供する機能の多くは、実際にはEnvoyプロキシの基盤となる組み込み機能によって有効になっています。

トラフィック制御：Envoyは、HTTP、gRPC、WebSocket、およびTCPトラフィックの豊富なルーティングルールを使用して、きめ細かいトラフィック制御を適用できるようにします
ネットワークの復元力：Envoyには、自動再試行、回路遮断、フォールトインジェクションのすぐに使えるサポートが含まれています
セキュリティ：Envoyは、セキュリティポリシーを適用し、基盤となるサービス間の通信にアクセス制御とレート制限を適用することもできます。

EnvoyがIstioと非常にうまく機能する他の理由の1つは、その拡張性です。 Envoy は、WebAssemblyに基づくプラグ可能な拡張モデルを提供します。これは、カスタムポリシーの適用とテレメトリの生成に非常に役立ちます。さらに、Proxy-WasmサンドボックスAPIに基づくIstio拡張機能を使用して、IstioでEnvoyプロキシを拡張することもできます。

5.2. コントロールプレーン

前に見たように、コントロールプレーンは、データプレーンのEnvoyプロキシを管理および構成する役割を果たします。コントロールプレーンでこれを担当するコンポーネントは、istiodです。ここで、 istiod は、高レベルのルーティングルールとトラフィック制御動作をEnvoy固有の構成に変換し、実行時にサイドカーに伝播する役割を果たします。

しばらく前からIstioコントロールプレーンのアーキテクチャを思い出すと、それが一緒に動作する独立したコンポーネントのセットであったことに気付くでしょう。これは、サービス検出用のPilot、構成用のGalley、証明書生成用のCitadel、拡張性用のMixerなどのコンポーネントで構成されていました。複雑さのため、これらの個々のコンポーネントはistiodと呼ばれる単一のコンポーネントにマージされました。

コアでは、 istiod は、以前の個々のコンポーネントと同じコードとAPIを引き続き使用します。たとえば、Pilotは、プラットフォーム固有のサービス検出メカニズムを抽象化し、サイドカーが使用できる標準形式にそれらを合成する責任があります。したがって、IstioはKubernetesや仮想マシンなどの複数の環境の検出をサポートできます。

さらに、 istiod はセキュリティも提供し、IDと資格情報の管理が組み込まれた強力なサービス間認証とエンドユーザー認証を可能にします。さらに、 istiod を使用すると、サービスIDに基づいてセキュリティポリシーを適用できます。プロセスistiodは、認証局（CA）としても機能し、データプレーンでの相互TLS（MTLS）通信を容易にする証明書を生成します。

6. Istioのしくみ

サービスメッシュの典型的な機能が何であるかを学びました。さらに、Istioアーキテクチャとそのコアコンポーネントの基本についても説明しました。次に、Istioがアーキテクチャのコアコンポーネントを通じてこれらの機能をどのように提供するかを理解します。

以前に経験したのと同じカテゴリの機能に焦点を当てます。

6.1. 交通管理

Istioトラフィック管理APIを使用して、サービスメッシュ内のトラフィックをきめ細かく制御できます。これらのAPIを使用して、独自のトラフィック構成をIstioに追加できます。さらに、Kubernetesカスタムリソース定義（CRD）を使用してAPIリソースを定義できます。トラフィックルーティングの制御に役立つ主要なAPIリソースは、仮想サービスと宛先ルールです。

基本的に、仮想サービスを使用すると、Istioサービスメッシュ内のサービスにリクエストをルーティングする方法を構成できます。したがって、仮想サービスは、順番に評価される1つ以上のルーティングルールで構成されます。仮想サービスのルーティングルールが評価された後、宛先ルールが適用されます。宛先ルールは、宛先へのトラフィックを制御するのに役立ちます。たとえば、バージョンごとにサービスインスタンスをグループ化します。

6.2. 安全

Istioのセキュリティは、すべてのサービスに強力なIDをプロビジョニングすることから始まります。すべてのEnvoyプロキシと一緒に実行されるIstioエージェントは、 istiod と連携して、キーと証明書のローテーションを自動化します。

Istio は、ピア認証と要求認証の2種類の認証を提供します。ピア認証は、Istioがフルスタックソリューションとして相互TLSを提供するサービス間認証に使用されます。リクエスト認証は、Istioがカスタム認証プロバイダーまたはOpenID Connect（OIDC）プロバイダーを使用したJSON Webトークン（JWT）検証を提供するエンドユーザー認証に使用されます。

Istioでは、サービスに承認ポリシーを適用するだけで、サービスへのアクセス制御を強制することもできます。承認ポリシーは、Envoyプロキシのインバウンドトラフィックへのアクセス制御を強制します。これにより、メッシュ、名前空間、サービス全体など、さまざまなレベルでアクセス制御を適用できます。

6.3. 可観測性

Istioは、メッシュ内のすべてのサービス通信について、メトリック、分散トレース、アクセスログなどの詳細なテレメトリを生成します。 Istio は、プロキシレベルのメトリック、サービス指向のメトリック、およびコントロールプレーンメトリックの豊富なセットを生成します。

以前、Istioテレメトリアーキテクチャには、中央コンポーネントとしてMixerが含まれていました。ただし、Telemetry v2以降、Mixerによって提供される機能はEnvoyプロキシプラグインに置き換えられました。

さらに、IstioはEnvoyプロキシを介して分散トレースを生成します。 Istioは、 Zipkin 、 Jaeger 、 Lightstep 、Datadogなどの多数のトレースバックエンドをサポートしています。トレース生成のサンプリングレートを制御することもできます。さらに、Istioは、構成可能な一連の形式でサービストラフィックのアクセスログも生成します。

7. Istioの実践

十分な背景を経たので、Istioの動作を確認する準備が整いました。まず、Kubernetesクラスター内にIstioをインストールします。さらに、シンプルなマイクロサービスベースのアプリケーションを使用して、KubernetesでのIstioの機能をデモンストレーションします。

7.1. インストール

Istioをインストールする方法はいくつかありますが、最も簡単な方法は、Windowsなどの特定のOSの最新リリースをダウンロードして抽出することです。抽出されたパッケージには、binディレクトリにistioctlクライアントバイナリが含まれています。 はistioctlを使用して、ターゲットのKubernetesクラスターにIstioをインストールできます。

istioctl install --set profile=demo -y

これにより、デモプロファイルを使用してデフォルトのKubernetesクラスターにIstioコンポーネントがインストールされます。デモの代わりに、他のベンダー固有のプロファイルを使用することもできます。

最後に、このKubernetesクラスタにアプリケーションをデプロイするときに、IstioにEnvoyサイドカープロキシを自動的に挿入するように指示する必要があります。

kubectl label namespace default istio-injection=enabled

ここでは、MinikubeのようなKubernetesクラスターとKubernetesCLI kubectl が既にマシンで使用可能であることを前提として、kubectlを使用しています。

7.2. サンプルアプリケーション

デモンストレーションの目的で、オンライン注文を行うための非常に単純なアプリケーションを想像します。このアプリケーションは、エンドユーザーの注文要求を満たすために相互作用する3つのマイクロサービスで構成されています。

これらのマイクロサービスの詳細については説明しませんが、Spring BootとRESTAPIを使用して作成するのはかなり簡単です。最も重要なのは、これらのマイクロサービスのDockerイメージを作成して、Kubernetesにデプロイできるようにすることです。

7.3. 展開

コンテナ化されたワークロードをMinikubeのようなKubernetesクラスターにデプロイするのはかなり簡単です。 DeploymentおよびServiceリソースタイプを使用して、ワークロードを宣言およびアクセスします。通常、YAMLファイルでそれらを定義します。

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: order-service
  namespace: default
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: order-service
        version: v1
    spec:
      containers:
      - name: order-service
        image: kchandrakant/order-service:v1
        resources:
          requests:
            cpu: 0.1
            memory: 200
---
apiVersion: v1
kind: Service
metadata:
  name: order-service
spec:
  ports:
  - port: 80
    targetPort: 80
    protocol: TCP
    name: http
  selector:
    app: order-service

これは、order-serviceのDeploymentおよびServiceの非常に単純な定義です。同様に、Inventory-serviceとshipping-serviceのYAMLファイルを定義できます。

kubectl を使用してこれらのリソースをデプロイすることも、かなり簡単です。

kubectl apply -f booking-service.yaml -f inventory-service.yaml -f shipping-service.yaml

デフォルトの名前空間に対してEnvoyサイドカープロキシの自動インジェクションを有効にしているため、すべてが自動的に処理されます。または、istioctlのkube-injectコマンドを使用して、Envoyサイドカープロキシを手動で挿入することもできます。

7.4. アプリケーションへのアクセス

現在、Istioは主にすべてのメッシュトラフィックの処理を担当しています。したがって、メッシュの外部との間のトラフィックはデフォルトでは許可されていません。 Istioはゲートウェイを使用して、メッシュからのインバウンドトラフィックとアウトバウンドトラフィックを管理します。このようにして、メッシュに出入りするトラフィックを正確に制御できます。 Istioは、いくつかの事前構成されたゲートウェイプロキシ展開を提供します：istio-ingressgatewayおよびistio-egressgateway。

これを実現するために、アプリケーション用のゲートウェイと仮想サービスを作成します。

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: booking-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "*"
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: booking
spec:
  hosts:
  - "*"
  gateways:
  - booking-gateway
  http:
  - match:
    - uri:
        prefix: /api/v1/booking
    route:
    - destination:
        host: booking-service
        port:
          number: 8080

ここでは、Istioが提供するデフォルトの入力コントローラーを使用しています。さらに、リクエストをbooking-serviceにルーティングする仮想サービスを定義しました。

同様に、メッシュからのアウトバウンドトラフィックの出力ゲートウェイを定義することもできます。

8. Istioの一般的なユースケース

これで、Istioを使用してKubernetesに簡単なアプリケーションをデプロイする方法を確認しました。しかし、Istioが可能にする興味深い機能はまだ利用していません。このセクションでは、サービスメッシュの一般的なユースケースをいくつか見ていき、Istioを使用して単純なアプリケーションでそれらを実現する方法を理解します。

8.1. ルーティングを要求する

特定の方法でリクエストルーティングを処理したい理由はいくつかあります。たとえば、はshipping-service のようなマイクロサービスの複数のバージョンをデプロイし、リクエストのごく一部のみを新しいバージョンにルーティングしたい場合があります。

仮想サービスのルーティングルールを使用して、これを実現できます。

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: shipping-service
spec:
  hosts:
    - shipping-service
  http:
  - route:
    - destination:
        host: shipping-service
        subset: v1
      weight: 90
    - destination:
        host: shipping-service
        subset: v2
      weight: 10
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: shipping-service
spec:
  host: shipping-service
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2

ルーティングルールを使用すると、ヘッダーパラメータなどの属性に基づいて一致条件を定義することもできます。さらに、宛先フィールドは、条件に一致するトラフィックの実際の宛先を指定します。

8.2. 回路遮断

サーキットブレーカは基本的にソフトウェアのデザインパターンであり、障害を検出し、障害がさらにカスケードするのを防ぐロジックをカプセル化します。これは、障害や遅延の急増の影響を制限する復元力のあるマイクロサービスアプリケーションの作成に役立ちます。

Istioでは、DestinationRuleのtrafficPolicy構成を使用して、Inventory-serviceなどのサービスを呼び出すときに回線遮断を適用できます。

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: inventory-service
spec:
  host: inventory-service
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 1
      http:
        http1MaxPendingRequests: 1
        maxRequestsPerConnection: 1
    outlierDetection:
      consecutive5xxErrors: 1
      interval: 1s
      baseEjectionTime: 3m
      maxEjectionPercent: 100

ここでは、 DestinationRuleをmaxConnections を1、 httpMaxPendingRequests を1、maxRequestsPerConnectionを1として構成しました。これは事実上、同時リクエストの数を1を超えると、サーキットブレーカーが一部のリクエストのトラップを開始することを意味します。

8.3. 相互TLSの有効化

相互認証とは、TLSのような認証プロトコルで2つのパーティが同時に相互に認証する状況を指します。デフォルトでは、プロキシを使用するサービス間のすべてのトラフィックは、Istioで相互TLSを使用します。ただし、プロキシのないサービスは引き続きプレーンテキストでトラフィックを受信します。

Istioは、プロキシを使用するサービス間のすべてのトラフィックを相互TLSに自動的にアップグレードしますが、これらのサービスは引き続きプレーンテキストトラフィックを受信できます。 PeerAuthentication ポリシーを使用して、メッシュ全体で相互TLSを適用するオプションがあります。

apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
  name: "default"
  namespace: "istio-system"
spec:
  mtls:
    mode: STRICT

メッシュ全体ではなく、名前空間またはサービスごとに相互TLSを適用するオプションもあります。ただし、サービス固有のPeerAuthenticationポリシーは、名前空間全体のポリシーよりも優先されます。

8.4. JWTによるアクセス制御

JSON Web Token（JWT）は、ペイロードが多数のクレームをアサートするJSONを保持するデータを作成するための標準です。これは、IDプロバイダーとサービスプロバイダーの間で認証されたユーザーのIDと標準またはカスタムクレームを渡すために広く受け入れられるようになりました。

Istioで承認ポリシーを有効にして、JWTに基づくbooking-serviceなどのサービスへのアクセスを許可できます。

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: require-jwt
  namespace: default
spec:
  selector:
    matchLabels:
      app: booking-service
  action: ALLOW
  rules:
  - from:
    - source:
       requestPrincipals: ["testing@baeldung.com/testing@baeldung.io"]

ここで、 AuthorizationPolicy は、requestPrincipalが特定の値に設定された有効なJWTを持つようにすべてのリクエストを強制します。 Istioは、JWTのクレームissとsubを組み合わせて、requestPrincipal属性を作成します。

9. 後付け

そのため、Istioのようなサービスメッシュによって、マイクロサービスのような分散アーキテクチャで一般的な多くの懸念事項を処理しやすくなることがわかりました。しかし、すべてにもかかわらず、 Istioは複雑なシステムであり、結果として生じる展開の複雑さを増します。他のすべてのテクノロジーと同様に、Istioは特効薬ではないため、十分な考慮を払って使用する必要があります。

9.1. 常にサービスメッシュを使用する必要がありますか？

サービスメッシュを使用する十分な理由を見てきましたが、それを使用しないように促す可能性のあるいくつかの理由を挙げましょう。

サービスメッシュは、サービスメッシュの展開と運用の追加コストで、すべてのサービス間通信を処理します。より単純なアプリケーションの場合、これは正当化されない可能性があります
アプリケーションコードでの回路の破損など、これらの懸念事項の一部を処理することに慣れているため、サービスメッシュでの処理が重複する可能性があります。
サービスメッシュなどの外部システムへの依存度が高まると、特にサービスメッシュの業界標準がないため、アプリケーションの移植性に悪影響を与える可能性があります。
サービスメッシュは通常、プロキシを介してメッシュトラフィックをインターセプトすることで機能するため、リクエストに望ましくないレイテンシが追加される可能性があります
サービスメッシュは、正確な処理を必要とする多くの追加コンポーネントと構成を追加します。これには専門知識が必要であり、学習曲線に追加されます
最後に、サービスメッシュにあるはずの運用ロジックとサービスメッシュにないはずのビジネスロジックを混ぜ合わせてしまう可能性があります。

したがって、ご覧のとおり、サービスメッシュの話はすべてメリットに関するものではありませんが、それが真実ではないという意味ではありません。私たちにとって重要なことは、要件とアプリケーションの複雑さを注意深く評価し、サービスメッシュの利点と追加された複雑さを比較検討することです。

9.2. Istioの代替手段は何ですか？

Istioは非常に人気があり、業界のリーダーの一部に支えられていますが、利用できるオプションは確かにそれだけではありません。ここでは完全な比較はできませんが、LinkerdとConsulという2つのオプションを見てみましょう。

Linkerd は、Kubernetesプラットフォーム用に作成されたオープンソースのサービスメッシュです。また、非常に人気があり、現在CNCFでのインキュベーションプロジェクトのステータスがあります。その動作原理は、Istioのような他のサービスメッシュと同様です。また、TCPプロキシを使用してメッシュトラフィックを処理します。 Linkerdは、Rustで記述され、Linkerdプロキシとして知られているマイクロプロキシを使用します。

全体として、LinkerdはKubernetesのみをサポートしていることを考えると、Istioほど複雑ではありません。ただし、それを除けば、Linkerdで使用できる機能のリストは、Istioで使用できる機能と非常によく似ています。 Linkerdのコアアーキテクチャも、Istioのアーキテクチャとよく似ています。基本的に、Linkerdは、ユーザーインターフェイス、データプレーン、およびコントロールプレーンの3つの主要コンポーネントで構成されています。

Consul は、HashiCorpのサービスメッシュのオープンソース実装です。 HashiCorpの他のインフラストラクチャ管理製品スイートとうまく統合して、より幅広い機能を提供できるという利点があります。 Consulのデータプレーンには、プロキシとネイティブ統合モデルをサポートする柔軟性があります。プロキシが組み込まれていますが、Envoyでもうまく機能します。

Kubernetesとは別に、ConsulはNomadなどの他のプラットフォームと連携するように設計されています。 Consulは、すべてのノードでConsulエージェントを実行して、ヘルスチェックを実行することで機能します。これらのエージェントは、データを保存および複製する1つ以上のConsulサーバーと通信します。 Istioのようなサービスメッシュのすべての標準機能を提供しますが、展開および管理するためのより複雑なシステムです。

10. 結論

要約すると、このチュートリアルでは、サービスメッシュパターンの基本的な概念とそれが提供する機能について説明しました。特に、Istioの詳細を確認しました。これは、Istioのコアアーキテクチャとその基本コンポーネントをカバーしていました。さらに、いくつかの一般的なユースケースでのIstioのインストールと使用の詳細についても説明しました。