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に設定するには:
-
重み付けラウンド・ロビンを使用して、バックエンド・セットをロード・バランサに追加します。
-
ワーカー・ノードをバックエンド・セットに追加します。 ワーカー・ノードのポートを
http2
のTCPポートに設定します。 この例では、32681
です。 -
TCPポート
80
を使用してバックエンド・セットのリスナーを作成します。
HTTPSトラフィック用にロード・バランサをOracle Cloud Infrastructureに設定するには:
-
重み付けラウンド・ロビンを使用して、バックエンド・セットをロード・バランサに追加します。
-
ワーカー・ノードをバックエンド・セットに追加します。 ワーカー・ノードのポートを
https
のTCPポートに設定します。 この例では、31941
です。 -
TCPポート
443
を使用してバックエンド・セットのリスナーを作成します。
Oracle Cloud Infrastructureでのロード・バランサの設定の詳細は、「Oracle Cloud Infrastructureのドキュメント」を参照してください。
イングレス・ゲートウェイの設定
Istioのイングレス・ゲートウェイによって、すべての着信トラフィックが通過するサービス・メッシュへのエントリ・ポイントを定義できます。 イングレス・ゲートウェイを使用すると、外部クラスタからのサービスへのアクセスを管理できます。 クラスタに進入するトラフィックについて、ルーティングのルールをモニターおよび設定できます。
この項では、イングレス・ゲートウェイの自動作成をNGINX webサーバー・アプリケーションに構成する例を示します。 この例では、ロード・バランサがlb.example.com
で使用可能になっていて、TCP
ポート32681
のistio-ingressgateway
サービスに接続していることを前提とします。 ロード・バランサ・リスナーは、この例の仮想サービスで使用されるNGINX webサーバー・アプリケーションのポートであるHTTP
ポート80
でリスニングするように設定されています。
イングレス・ゲートウェイを設定するには:
-
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
-
デプロイメントのためのサービスを作成します。
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
-
このサービス用のイングレス・ゲートウェイを作成します。
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"
-
このイングレス・ゲートウェイ用の仮想サービスを作成します。
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
-
このアプリケーション用に
my-namespace
というネームスペースを設定して、プロキシ・サイドカーの自動インジェクションを有効にします。kubectl create namespace my-namespace kubectl label namespaces my-namespace istio-injection=enabled
-
デプロイメント、サービス、イングレス・ゲートウェイおよび仮想サービスを実行します:
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
-
イングレス・ゲートウェイが実行中になっていることは、次のコマンドを使用して確認できます
kubectl get gateways.networking.istio.io --namespace my-namespace
出力は次のようになります:
NAME AGE my-nginx-gateway 33s
-
仮想サービスが実行中になっていることは、次のコマンドを使用して確認できます
kubectl get virtualservices.networking.istio.io --namespace my-namespace
出力は次のようになります:
NAME GATEWAYS HOSTS AGE my-nginx-virtualservice [my-nginx-gateway] [mynginx.example.com] 107s
-
イングレス・ゲートウェイがアプリケーションをロード・バランサに渡していることを確認するには、次のコマンドを使用します。
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秒です。
-
再試行: サイドカー・プロキシがサービスに接続するまでに許容される最初の接続失敗からの再試行の回数。 仮想サービスを設定することで、サービスごとに再試行の回数を有効化して構成できます。 デフォルトでは、再試行は許可されません。
-
障害注入: 障害注入メカニズムを設定して、アプリケーションの障害リカバリをテストします。 仮想サービスを設定することで、サービスへの障害注入を設定して障害を注入できます。 遅延を設定することで、ネットワーク・レイテンシや過負荷状態のアップストリーム・サービスを模倣できます。 また、中断を設定して、アップストリーム・サービスの障害を模倣することもできます。