機械翻訳について
  1. Istioモジュールforリリース1.7
  2. サービス・メッシュの使用

3 サービス・メッシュの使用

サービス・メッシュ内に作成したすべてのサービスは、Istioによってサービス・レジストリに自動的に移入されるため、可能性のあるサービス・エンドポイントはすべて認識されます。 デフォルトでは、Envoyプロキシ・サイドカーが、ラウンドロビン方式で各サービス・インスタンスに順番にリクエストを送信することでトラフィックを管理します。 このトラフィックの管理は、Istioトラフィック管理APIを使用して構成できます。 このAPIにアクセスするには、Kubernetesのカスタム・リソース定義(CRD)を使用します。これは、YAMLファイルを使用して設定およびデプロイします。

使用可能なIstio APIトラフィック管理機能は次のとおりです。

  • 仮想サービス: サービス・メッシュ内でサービスへのリクエスト・ルーティングを構成します。 各仮想サービスには、一連のルーティング・ルールを含めることができます。このルールは順序どおりに評価されます。

  • 宛先ルール: 仮想サービス内でルーティング・ルールの宛先を構成します。 宛先ルールは、仮想サービスのルーティング・ルールの後に評価および処理されます。 たとえば、特定のバージョンのサービスに向けてトラフィックをルーティングします。

  • ゲートウェイ: メッシュ内のサービスの着信および発信トラフィックを構成します。 ゲートウェイは、メッシュのエッジで実行されるスタンドアロンのEnvoyプロキシとして構成されます。 イングレスおよびエグレス・ゲートウェイは、Istioモジュールのインストール時に自動的にデプロイされます。

  • サービス・エントリ: Istioサービス・レジストリに、サービス・メッシュの外側のサービスを構成します。 サービスへのトラフィックをサービス・メッシュ内にあるかのように管理できます。 メッシュ内のサービスは自動的にサービス・レジストリに追加され、サービス・エントリは外部サービスを取り込むことができます。

  • サイドカー: サイドカー・プロキシを構成して、マイクロサービスが接続できるポート、プロトコル、およびサービスを設定します。

これらのIstioトラフィック管理APIについては、アップストリームの「Istioドキュメント」に記載されています。

 プロキシ・サイドカーの有効化

Istioは、サービス自体から抽象化され、代わりにプロキシによって処理されるサービス間のネットワーク通信を提供します。 Istioには、サイドカー設計が使用されています。このデザインでは、通信プロキシがすべてのサービス・コンテナごとに専用のコンテナ内で実行されます。

Kubernetesアプリケーションでサービス・メッシュの使用を有効にするには、自動プロキシ・サイドカー・インジェクションを有効にする必要があります。 これにより、作成したポッドにプロキシ・サイドカー・コンテナをインジェクトします。

サイドカーの自動インジェクションを有効にするには、アプリケーションで使用するネームスペースに、istio-injection=enabledのラベルが付いている必要があります。 たとえば、defaultネームスペースに対してサイドカーの自動インジェクションを有効にするには、次のようにします。 

kubectl label namespace default istio-injection=enabled

defaultネームスペースにラベルが設定されていることを確認するには、次を使用します: 

kubectl get namespace -L istio-injection

出力は次のようになります:

NAME                           STATUS   AGE   ISTIO-INJECTION
default                        Active   29h   enabled
externalip-validation-system   Active   29h   
istio-system                   Active   29h   
...

このデフォルト・ネームスペースにデプロイされたアプリケーションは、サイドカーの自動インジェクションが有効化され、サイドカーがポッドと並行して実行されます。 たとえば、NGINXデプロイメントを作成します: 

kubectl create deployment --image nginx hello-world

ポッドの詳細を表示して、このアプリケーションによってistio-proxyコンテナもデプロイされていることを確認します。 

kubectl get pods

出力は次のようになります:

NAME                           READY   STATUS    RESTARTS   AGE
hello-world-5fcdb6bc85-wph7h   2/2     Running   0          7m40s

ポッドを記述することで、nginxコンテナとともに作成されたistio-proxyサイドカーを表示できます: 

kubectl describe pods hello-world-5fcdb6bc85-wph7h

出力は次のようになります:

...
  Normal  Started    13s   kubelet, worker1.example.com  Started container nginx
  Normal  Started    12s   kubelet, worker1.example.com  Started container istio-proxy

イングレス・ゲートウェイのロード・バランサの設定

Istioモジュールをデプロイする場合は、Istioイングレス・ゲートウェイ・トラフィックを処理するようにロード・バランサを設定することもできます。 この項では、Istioイングレス・ゲートウェイを使用してクラスタ外部からサービスへのアクセスを管理するようにロード・バランサを設定する方法に関する情報を示します。

この項のロード・バランサ・ポート・マッピングでは、HTTPおよびHTTPSのポートを設定します。 ロード・バランサは、ポート80でHTTPトラフィックをリスニングし、それをhttp2のIstioイングレス・ゲートウェイNodePort番号にリダイレクトします。 コントロール・プレーン・ノードで次のように入力して、http2に設定するポート番号を問い合せます: 

kubectl describe svc istio-ingressgateway -n istio-system |grep http2

出力は次のようになります:

Port:                     http2  80/TCP
NodePort:                 http2  32681/TCP

この例では、NodePortは32681です。 したがって、ロード・バランサは、ポート80でHTTPトラフィックをリスニングし、それをポート32681のistio-ingressgatewayサービスにリダイレクトするように構成する必要があります。

HTTPSトラフィックの場合、ロード・バランサはポート443でリスニングし、httpsのIstioイングレス・ゲートウェイNodePort番号にリダイレクトします。 httpsに設定するポート番号を検索するには、次のように入力します: 

kubectl describe svc istio-ingressgateway -n istio-system |grep https

出力は次のようになります:

Port:                     https  443/TCP
NodePort:                 https  31941/TCP

この例では、NodePortは31941です。 そのため、ポート443でHTTPSトラフィックをリスニングし、それをポート31941のistio-ingressgatewayサービスにリダイレクトするようにロード・バランサを構成する必要があります。

ロード・バランサは、HTTPトラフィックに対して次の構成で設定する必要があります:

  • TCPポート80でリスニングしているリスナー。

  • 配布はラウンドロビンに設定されます。

  • ワーカー・ノードのhttp2のTCPポートに設定されたターゲット。 この例では、32681です。

  • ヘルス・チェックはTCPに設定されています。

HTTPSトラフィックの場合:

  • TCPポート443でリスニングしているリスナー。

  • 配布はラウンドロビンに設定されます。

  • ワーカー・ノードのhttpsのTCPポートに設定されたターゲット。 この例では、31941です。

  • ヘルス・チェックはTCPに設定されています。

ロード・バランサの設定の詳細は、「Oracle Linux 9: ロード・バランシングの設定」または「Oracle Linux 8: ロード・バランシングの設定」を参照してください。

Oracle Cloud Infrastructureにデプロイする場合は、新しいロード・バランサを設定するか、Kubernetesモジュールに設定したロード・バランサを使用できます(ロード・バランサがある場合)。

HTTPトラフィック用にロード・バランサをOracle Cloud Infrastructureに設定するには:

  1. 重み付けラウンド・ロビンを使用して、バックエンド・セットをロード・バランサに追加します。

  2. ワーカー・ノードをバックエンド・セットに追加します。 ワーカー・ノードのポートをhttp2のTCPポートに設定します。 この例では、32681です。

  3. TCPポート80を使用してバックエンド・セットのリスナーを作成します。

HTTPSトラフィック用にロード・バランサをOracle Cloud Infrastructureに設定するには:

  1. 重み付けラウンド・ロビンを使用して、バックエンド・セットをロード・バランサに追加します。

  2. ワーカー・ノードをバックエンド・セットに追加します。 ワーカー・ノードのポートをhttpsのTCPポートに設定します。 この例では、31941です。

  3. TCPポート443を使用してバックエンド・セットのリスナーを作成します。

Oracle Cloud Infrastructureでのロード・バランサの設定の詳細は、「Oracle Cloud Infrastructureのドキュメント」を参照してください。

 イングレス・ゲートウェイの設定

Istioのイングレス・ゲートウェイによって、すべての着信トラフィックが通過するサービス・メッシュへのエントリ・ポイントを定義できます。 イングレス・ゲートウェイを使用すると、外部クラスタからのサービスへのアクセスを管理できます。 クラスタに進入するトラフィックについて、ルーティングのルールをモニターおよび設定できます。

この項では、イングレス・ゲートウェイの自動作成をNGINX webサーバー・アプリケーションに構成する例を示します。 この例では、ロード・バランサがlb.example.comで使用可能になっていて、TCPポート32681のistio-ingressgatewayサービスに接続していることを前提とします。 ロード・バランサ・リスナーは、この例の仮想サービスで使用されるNGINX webサーバー・アプリケーションのポートであるHTTPポート80でリスニングするように設定されています。

イングレス・ゲートウェイを設定するには:

  1. NGINX Webサーバー・アプリケーションを作成するためのデプロイメント・ファイルを作成します。 my-nginx.ymlというファイルを作成します。このファイルには、次の内容を含めます。 

    apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: my-webserver
  name: my-nginx
  namespace: my-namespace
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-webserver
  template:
    metadata:
      labels:
        app: my-webserver
    spec:
      containers:
      - image: nginx
        name: my-nginx
        ports:
        - containerPort: 80

  2. デプロイメントのためのサービスを作成します。 my-nginx-service.ymlという名前のファイルを作成します。このファイルには、次の内容を含めます。 

    apiVersion: v1
kind: Service
metadata:
  name: my-http-ingress-service
  namespace: my-namespace
spec:
  ports:
  - name: http
    port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: my-webserver
  type: ClusterIP

  3. このサービス用のイングレス・ゲートウェイを作成します。 my-nginx-gateway.ymlというファイルを作成します。このファイルには、次の内容を含めます。 

    apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: my-nginx-gateway
  namespace: my-namespace
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
      - "mynginx.example.com"

  4. このイングレス・ゲートウェイ用の仮想サービスを作成します。 my-nginx-virtualservice.ymlというファイルを作成します。このファイルには、次の内容を含めます。 

    apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: my-nginx-virtualservice
  namespace: my-namespace
spec:
  hosts:
  - "mynginx.example.com"
  gateways:
  - my-nginx-gateway
  http:
  - match:
    - uri:
        prefix: /
    route:
    - destination:
        port:
          number: 80
        host: my-http-ingress-service

  5. このアプリケーション用にmy-namespaceというネームスペースを設定して、プロキシ・サイドカーの自動インジェクションを有効にします。 

    kubectl create namespace my-namespace
kubectl label namespaces my-namespace istio-injection=enabled

  6. デプロイメント、サービス、イングレス・ゲートウェイおよび仮想サービスを実行します: 

    kubectl apply -f my-nginx.yml 
kubectl apply -f my-nginx-service.yml 
kubectl apply -f my-nginx-gateway.yml 
kubectl apply -f my-nginx-virtualservice.yml

  7. イングレス・ゲートウェイが実行中になっていることは、次のコマンドを使用して確認できます 

    kubectl get gateways.networking.istio.io --namespace my-namespace

    出力は次のようになります:

    NAME               AGE
my-nginx-gateway   33s

  8. 仮想サービスが実行中になっていることは、次のコマンドを使用して確認できます 

    kubectl get virtualservices.networking.istio.io --namespace my-namespace

    出力は次のようになります:

    NAME                      GATEWAYS             HOSTS                   AGE
my-nginx-virtualservice   [my-nginx-gateway]   [mynginx.example.com]   107s

  9. イングレス・ゲートウェイがアプリケーションをロード・バランサに渡していることを確認するには、次のコマンドを使用します。 

    curl -I -HHost:mynginx.example.com lb.example.com:80/

    出力は次のようになります:

    HTTP/1.1 200 OK
Date: <date> 00:39:16 GMT
Content-Type: text/html
Content-Length: 612
Connection: keep-alive
last-modified: <date> 14:32:47 GMT
etag: "5e5e6a8f-264"
accept-ranges: bytes
x-envoy-upstream-service-time: 15

 エグレス・ゲートウェイの設定

Istioエグレス・ゲートウェイを使用すると、サービス・メッシュ内のアプリケーションから外部のHTTPおよびHTTPSサービスへのアクセスを設定できます。 外部のサービスは、サイドカー・コンテナを使用して呼び出されます。

Istioのエグレス・ゲートウェイは、自動的にデプロイされます。 手動でデプロイする必要はありません。 次のコマンドを使用すると、Istioエグレス・ゲートウェイ・サービスが実行中になっていることを確認できます。 

kubectl get svc istio-egressgateway -n istio-system

出力は次のようになります:

NAME                  TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)                    AGE
istio-egressgateway   ClusterIP   10.111.233.121   <none>        80/TCP,443/TCP,15443/TCP   9m26s

Istioエグレス・ゲートウェイを使用する設定方法を示す例は、アップストリームの「Istioドキュメント」にあります。

 ネットワーク自己回復性のテスト

Istioネットワーク自己回復性およびテスト機能を使用すると、障害リカバリを設定およびテストし、自己回復性のテストのためにフォルトを注入できます。 サービス・メッシュ内のアプリケーションの信頼性を向上させるために、これらの機能を動的に実行時に設定します。 このリリースで使用可能な、ネットワーク自己回復性およびテストの機能は次のとおりです。

  • タイムアウト: サイドカー・プロキシがサービスからの応答を待機する時間。 仮想サービスを設定して、サービスごとに特定のタイムアウトを構成できます。 HTTPリクエストに対するデフォルトのタイムアウトは15秒です。

  • 再試行: サイドカー・プロキシがサービスに接続するまでに許容される最初の接続失敗からの再試行の回数。 仮想サービスを設定することで、サービスごとに再試行の回数を有効化して構成できます。 デフォルトでは、再試行は許可されません。

  • 障害注入: 障害注入メカニズムを設定して、アプリケーションの障害リカバリをテストします。 仮想サービスを設定することで、サービスへの障害注入を設定して障害を注入できます。 遅延を設定することで、ネットワーク・レイテンシや過負荷状態のアップストリーム・サービスを模倣できます。 また、中断を設定して、アップストリーム・サービスの障害を模倣することもできます。