このドキュメントで説明されているソフトウェアは、サポートされなくなったか、拡張サポートされています。
Oracleでは、現在サポートされているリリースにアップグレードすることをお勧めします。

機械翻訳について

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

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

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

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

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

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

  • サービス・エントリ: Istioサービス・レジストリに、サービス・メッシュの外側のサービスを構成します。 それらのサービスへのトラフィックは、サービス・メッシュ内に存在しているサービスと同様に管理できるようになります。 メッシュ内のサービスは自動的にサービス・レジストリに追加されます。外部のサービスは、サービス・エントリによって取り込めるようになります。

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

これらのIstioトラフィック管理APIは、次の場所にあるアップストリームのドキュメントで詳しく説明されています。

https://istio.io/docs/concepts/traffic-management/

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

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

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

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

kubectl label namespace default istio-injection=enabled

namespace/default labeled
kubectl get namespace -L istio-injection

NAME                           STATUS   AGE   ISTIO-INJECTION
default                        Active   29h   enabled
externalip-validation-system   Active   29h   
istio-system                   Active   29h   
kube-node-lease                Active   29h   
kube-public                    Active   29h   
kube-system                    Active   29h   
kubernetes-dashboard           Active   29h

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

kubectl create deployment --image nginx hello-world

deployment.apps/hello-world created

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

kubectl get pods

NAME                           READY   STATUS    RESTARTS   AGE
hello-world-5fcdb6bc85-wph7h   2/2     Running   0          7m40s
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

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

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 7: 管理者ガイドまたはOracle® Linux 8: ロード・バランシングの設定を参照してください。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  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 -n my-namespace
    
NAME               AGE
my-nginx-gateway   33s

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

    kubectl get virtualservices.networking.istio.io -n 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: Fri, 06 Mar 2020 00:39:16 GMT
Content-Type: text/html
Content-Length: 612
Connection: keep-alive
last-modified: Tue, 03 Mar 2020 14:32:47 GMT
etag: "5e5e6a8f-264"
accept-ranges: bytes
x-envoy-upstream-service-time: 15

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

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エグレス・ゲートウェイの設定方法と使用方法を示す例が示されています。

https://istio.io/docs/tasks/traffic-management/egress/egress-gateway/

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

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

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

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

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

Copyright © 2020, 2022, Oracle and/or its affiliates.