Using Istio

外部にサービスを公開するために APIRule をすでに使用しています。サービスを保護、接続、および監視するには、Istio を使用し、その機能およびメカニズムの詳細を確認する必要があります。

トラフィック管理とは、簡単に言うと、サービスメッシュのトラフィックのフローを制御する機能です。トラフィック管理を使用しない場合、要求は使用可能なサービスインスタンスにルーティングされます。多くの場合、これは望ましくありません。たとえば、トラフィックの一定の割合のみを新しいバージョンのサービス (カナリアデプロイメント) に転送するなど、ルールに基づいてトラフィックをリダイレクトするとします。または、新しいバージョンのサービスをカスタマが使用できるようにする前に、サービスを内部でテストする必要があります。そのため、トラフィックは内部ユーザー向けの最新サービスバージョン (別名: ドッグフード) にのみルーティングできます。トラフィック管理を使用すると、これらのシナリオを実装することができます。

この図は、トラフィックの一部のみを新しいバージョンのバックエンドサービスにルーティングするシナリオを示しています。トラフィックは、サービスの以前のバージョンと新しいバージョンの間で分割されます。このような設定では、ユーザのサブセットでのみ本稼働でサービスの新規バージョンをテストし、問題が発生した場合に迅速にロールバックすることができます。

新しいバージョンのサービスが想定どおりに動作する場合は、新しいバージョンのサービスにルーティングされるトラフィックの割合を増やすことができます。

しかし、これはどのように機能しますか。Istio には、トラフィックルールの定義に使用できる一連の CustomResourceDefinitions (CRD) があります。

Istio には、トラフィック管理に使用できる以下の複数のリソースがあります。

ゲートウェイ

メッシュの端で動作するロードバランサーだ。ゲートウェイは、受信または送信 HTTP/TCP 接続を処理します。

VirtualService

トラフィックルーティングに影響する設定について説明します。これを使用して、1 つのエントリポイントの背後にある複数のサービスを公開することができます (ゲートウェイ)。

DestinationRule

ルーティング後のサービス用のトラフィックに適用されるルールを指定します。

Istio のトラフィック管理リソースの完全な一覧については、トラフィック管理を参照してください。

1234567891011121314
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: foo-gateway
spec:
    selector:
        istio: ingressgateway 
    servers:
        - port:
            number: 80
            name: http
            protocol: HTTP
          hosts:
          - "*.foo.com"

12345678910111213141516171819
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: shop-route
spec:
  gateways:
    - foo-namespace/foo-gateway
  hosts:
    - shop.foo.com
  http:
  - route:
    - destination:
        host: shop
        subset: v1
      weight: 90
    - destination:
        host: shop
        subset: v2
      weight: 10     

12345678910111213
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: shop-route
spec:
    host: shop
    subsets:
    - name: v1
      labels:
        version: v1
    - name: v2
      labels:
        version: v2

Istio のセキュリティ機能により、サービスメッシュのセキュリティを制御することができます。Istio では、自分でトラフィック暗号化などのセキュリティ機能を実装する必要はありません。Istio では、トラフィックを暗号化することで、サービスメッシュでサービス間通信を保護することができます。これらのセキュリティ機能は、中間者攻撃から自身を防ぎ、発信者の ID をチェックすることでサービスへの不正アクセスを防ぐために不可欠です。

クラスタ内のサービス間の通信を保護することは、Istio の主な使用ケースの 1 つです。Istio では、相互 TLS (mTLS) によるトラフィック暗号化が提供され、呼出元の ID を認証することができます。相互 TLS は、クライアントとサーバが相互に認証できるようにするプロトコルです。相互 TLS は、クライアントとサーバが相互に認証できるようにするプロトコルです。サーバのみがクライアントを認証できる TLS とは異なり、mTLS は相互に証明書を提示することで相互認証を可能にするプロトコルです。

Istio のセキュリティ機能の詳細については、セキュリティを参照してください。

Istio はサービスメッシュ内のすべてのトラフィックを傍受するため、すべてのサービス通信に関する詳細な遠隔測定データを提供できます。この遠隔測定により、サービスメッシュに可観測性が提供されます。収集された遠隔測定データに基づいて可観測性を提供するために、Istio では以下のタイプが提供されています。

メトリクス

メトリックは、システムのステータスの追跡に使用される数値測定値です。Istio では、遅延、トラフィック、エラーなど、メッシュのヘルスを監視するために使用される一連のメトリクスが提供されます。

分散トレース

クラウドネイティブのマイクロサービスアーキテクチャでは、ユーザ要求が数十種類のマイクロサービスを経由することがよくあります。分散トレースでは、サービスメッシュ全体を通して要求のパスをトレースできます。分散トレースにより、サービスのパフォーマンスを監視し、ボトルネックを特定することができます。

アクセスログ

Istio では、サービスメッシュを通過するすべてのトラフィックのアクセスログを提供することもできます。アクセスログには、要求のソースや宛先、応答コードなど、トラフィックに関する詳細情報が表示されます。

SAP BTP, Kyma ランタイムでは、遠隔測定モジュールにより、Kyma クラスタ内の関連するすべてのデータ (Istio サービスメッシュによって提供されるデータなど) の収集に役立つ可観測性機能が提供されます。また、遠隔測定モジュールによってデータが強化され、追加分析のためにバックエンドに送信されます。詳細については、Kyma での可観測性の説明を参照してください。