ゲートウェイのインストールとアップグレード

Anthos Service Mesh では、サービス メッシュの一部としてゲートウェイをデプロイし、管理できます。ゲートウェイでは、メッシュのエッジで動作し、受信または送信 HTTP / TCP 接続を処理するロードバランサを記述します。ゲートウェイは、メッシュ内外に送信されるトラフィックをきめ細かく制御する Envoy プロキシです。ゲートウェイは、主に上り（内向き）トラフィックの管理に使用されますが、他の種類のトラフィックを管理するように構成することもできます。次に例を示します。

• Egress ゲートウェイ: Egress ゲートウェイを使用すると、メッシュから外部に送信されるトラフィック専用の Exit ノードを構成できます。これにより、外部ネットワークへのアクセスを許可するサービスを制限できます。また、下り（外向き）トラフィックを安全に制御し、メッシュのセキュリティを強化することもできます。

• East-West ゲートウェイ: East-West トラフィックのプロキシです。サービス ワークロードが異なるネットワーク上のマルチプライマリ メッシュのクラスタ境界を越えて通信できるようにします。デフォルトでは、このゲートウェイは、インターネットに公開されます。

このページでは、ゲートウェイ プロキシをデプロイしてアップグレードするためのベスト プラクティスと、独自の istio-ingressgateway および istio-egressgateway ゲートウェイ プロキシを構成する例について説明します。ゲートウェイ構成をゲートウェイ プロキシに適用することで、トラフィック分割、リダイレクト、再試行ロジックなどを実装できます。その場合、同じ API リソースにアプリケーション層トラフィック ルーティング（L7）を追加せずに、仮想サービスをゲートウェイにバインドします。これにより、サービス メッシュ内の他のデータプレーン トラフィックと同様にゲートウェイ トラフィックを管理できます。

ゲートウェイはさまざまな方法でデプロイできます。また、同じクラスタ内で複数のトポロジを使用することもできます。このトポロジの詳細については、Istio ドキュメントのゲートウェイ デプロイ トポロジをご覧ください。

ゲートウェイのデプロイに関するベスト プラクティス

ゲートウェイをデプロイするためのベスト プラクティスは、マネージド データプレーンと非マネージド データプレーンのどちらを使用するかによって異なります。

マネージド データプレーンのベスト プラクティス

1. マネージド データプレーンを有効にします。
2. マネージド リビジョン ラベルを名前空間に追加します。
3. コントロール プレーンとゲートウェイを個別にデプロイして管理します。
4. セキュリティのベスト プラクティスとして、ゲートウェイをコントロール プレーンとは異なる名前空間にデプロイすることをおすすめします。
5. 自動サイドカー インジェクション（自動インジェクション）を使用して、サービスのサイドカー プロキシを挿入する場合と同様にゲートウェイのプロキシ構成を挿入します。

ベスト プラクティスは次のとおりです。

• 最新の強化機能とセキュリティ アップデートを使用して、マネージド ゲートウェイを常に最新の状態にします。
• Anthos Service Mesh が管理するデータプレーンに、ゲートウェイ インスタンスの管理とメンテナンスをオフロードします。

非マネージド データプレーンのベスト プラクティス

1. コントロール プレーンとゲートウェイを個別にデプロイして管理します。
2. セキュリティのベスト プラクティスとして、ゲートウェイをコントロール プレーンとは異なる名前空間にデプロイすることをおすすめします。
3. 自動サイドカー インジェクション（自動インジェクション）を使用して、サービスのサイドカー プロキシを挿入する場合と同様にゲートウェイのプロキシ構成を挿入します。

ベスト プラクティスは次のとおりです。

• クラスタ全体に対する権限を持つように権限昇格を行わなくても、名前空間管理者がゲートウェイを管理できるようにします。
• 管理者が、Kubernetes アプリケーションの管理に使用しているデプロイツールやメカニズムを使用して、ゲートウェイのデプロイや管理を行えるようにします。
• 管理者にゲートウェイ Deployment に対するフルコントロールを許可し、操作を簡単に行えるようにします。新しいアップグレードが利用可能になるか、構成が変更されたときに、管理者が再起動を行うだけで、ゲートウェイ Pod が更新されるようにします。これにより、サービスでサイドカー プロキシを運用する場合と同じ方法でゲートウェイ Deployment を運用できるようになります。

ゲートウェイをデプロイする

ユーザーが既存のデプロイツールを使用できるようにするため、Anthos Service Mesh では、Istio と同じ方法（IstioOperator、Helm、Kubernetes YAML）でゲートウェイのデプロイを行うことができます。どの方法でも同じ結果になります。慣れている方法を選択することもできますが、Kubernetes YAML をおすすめします。こちらのほうが変更が簡単で、ソース制御にハイドレードされたマニフェストを保存できます。

1. ゲートウェイの名前空間をまだ作成していない場合は作成します。GATEWAY_NAMESPACE は、名前空間に置き換えます。

   kubectl create namespace GATEWAY_NAMESPACE
   

2. 自動挿入を有効にするには、デフォルトのインジェクション ラベルを使用して名前空間にラベルを付けるか（デフォルトのタグを設定した場合）、リビジョン ラベルを名前空間に追加します。追加するラベルは、マネージド Anthos Service Mesh をデプロイしたか、クラスタ内コントロール プレーンをインストールしたかによって異なります。ラベルは、サイドカー インジェクタ Webhook によって、挿入されたサイドカーを特定のコントロール プレーン リビジョンに関連付けるのに使用されます。

   インストール タイプ（マネージドまたはクラスタ内）に応じて下のタブを選択してください。

   マネージド

   利用可能なリリース チャンネルを探すには、次のコマンドを使用します。

   kubectl -n istio-system get controlplanerevision
   

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

   NAME                AGE
   asm-managed         6d7h
   asm-managed-rapid   6d7h
   

   出力で、NAME 列の値は、Anthos Service Mesh バージョンで使用可能なリリース チャンネルに対応するリビジョン ラベルです。

   クラスタ内

   クラスタ内コントロール プレーンの場合、istiod Service と Deployment には通常 istio.io/rev=asm-1167-22 のようなリビジョン ラベルがあります。ここで、asm-1167-22 は Anthos Service Mesh のバージョンを表します。リビジョンは istiod Service 名の一部になります（例: istiod-asm-1167-22.istio-system）。

   次のコマンドを使用して、クラスタ内コントロール プレーンの istiod のリビジョン ラベルを確認します。

   kubectl get deploy -n istio-system -l app=istiod \
     -o=jsonpath='{.items[*].metadata.labels.istio\.io\/rev}''{"\n"}'
   

3. インジェクションの名前空間を有効にします。REVISION は、リビジョン ラベルの値に置き換えます。

   注: デフォルトのタグが構成されている場合は、istio.io/rev を istio-injection=enabled ラベルに置き換えることができます。デフォルトのタグが存在することを確認するには、OUTPUT_DIR で istioctl を使用して istioctl tag list を実行します。

   kubectl label namespace GATEWAY_NAMESPACE istio-injection- istio.io/rev=REVISION --overwrite
   

4. asmcli を使用して Anthos Service Mesh をインストールした場合は、--output_dir で指定したディレクトリに移動し、次に cd で samples ディレクトリに移動します。

   重要: 正しい samples ディレクトリにいることを確認するには、ls コマンドを実行してディレクトリの内容を一覧表示し、gateways ディレクトリ（次のステップでアクセスします）と online-boutique ディレクトリがあることを確認します。

   asmcli を使用してインストールしなかった場合は、anthos-service-mesh リポジトリからゲートウェイの構成ファイルをコピーします。

5. samples/gateways/ ディレクトリにあるゲートウェイ構成のサンプルをそのままデプロイするか、必要に応じて変更します。

   Ingress

   kubectl apply -n GATEWAY_NAMESPACE -f samples/gateways/istio-ingressgateway
   

   Egress

   kubectl apply -n GATEWAY_NAMESPACE -f samples/gateways/istio-egressgateway
   

6. Deployment を作成したら、新しいサービスが正常に動作していることを確認します。

   kubectl get pod,service -n GATEWAY_NAMESPACE
   

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

   NAME                                      READY   STATUS    RESTARTS   AGE
   pod/istio-ingressgateway-856b7c77-bdb77   1/1     Running   0          3s
   
   NAME                           TYPE           CLUSTER-IP     EXTERNAL-IP      PORT(S)        AGE
   service/istio-ingressgateway   LoadBalancer   10.24.5.129    34.82.157.6      80:31904/TCP   3s

重要: ゲートウェイ リソースは、他の Kubernetes アプリケーションと同様に管理する必要があります。anthos-service-mesh-packages リポジトリのサンプルはガイダンスとクイックスタート用です。必要に応じてカスタマイズしてください。

ゲートウェイ セレクタ

istio-ingressgateway と istio-egressgateway のプロキシにゲートウェイ構成を適用して、メッシュの受信トラフィックと送信トラフィック（メッシュ内外に送受信されるトラフィック）を管理します。ゲートウェイ Deployment の Pod のラベルは、ゲートウェイの構成リソースで使用されるため、ゲートウェイ セレクタがこれらのラベルと一致している必要があります。

たとえば、上記の Deployment では、ゲートウェイ Pod に istio=ingressgateway ラベルが設定されます。ゲートウェイ構成をこれらの Deployment に適用するには、同じラベルを選択する必要があります。

apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: gateway
spec:
  selector:
    istio: ingressgateway
...

ゲートウェイ構成と仮想サービスの例については、Online Boutique サンプル アプリケーションの frontend.yaml をご覧ください。

ゲートウェイをアップグレードする

インプレース アップグレード

ほとんどの場合、インプレース アップグレード パターンに従ってゲートウェイをアップグレードする必要があります。ゲートウェイは Pod インジェクションを利用するため、新しく作成されたゲートウェイ Pod は、バージョンを含む最新の構成で自動的に挿入されます。

ゲートウェイが使用するコントロール プレーンのリビジョンを変更する場合は、ゲートウェイの Deployment に istio.io/rev ラベルを設定できます。これにより、ローリング再起動もトリガーされます。

マネージド コントロール プレーン

マネージド コントロール プレーンのアップグレードは Google が管理しているため、ゲートウェイ Deployment を再起動するだけで、新しい Pod が最新の構成とバージョンで自動的に挿入されます。

kubectl rollout restart deployment istio-ingressgateway \
  -n GATEWAY_NAMESPACE

クラスタ内コントロール プレーン

クラスタ内コントロール プレーンがある場合に同じパターンをゲートウェイに適用するには、ゲートウェイで使用されているコントロール プレーン リビジョンを変更する必要があります。ローリング再起動をトリガーするゲートウェイ Deployment に istio.io/rev ラベルを設定します。必要な手順は、名前空間またはゲートウェイ Pod のリビジョン ラベルを更新する必要があるかどうかによって異なります。

• インジェクション用の名前空間にラベルを付けた場合は、名前空間の istio.io/rev ラベルに新しいリビジョン値を設定します。

    kubectl label namespace GATEWAY_NAMESPACE \
      istio-injection- istio.io/rev=REVISION \
      --overwrite
  

• ゲートウェイ Pod に対してのみインジェクションを有効にした場合は、Deployment の istio.io/rev ラベルに新しいリビジョン値を設定します。次の Kubernetes YAML ファイルはその一例です。

  cat <<EOF > gateway-deployment.yaml
  apiVersion: apps/v1
  kind: Deployment
  metadata:
    name: istio-ingressgateway
    namespace: GATEWAY_NAMESPACE
  spec:
    selector:
      matchLabels:
        istio: ingressgateway
    template:
      metadata:
        annotations:
          # This is required to tell Anthos Service Mesh to inject the gateway with the
          # required configuration.
          inject.istio.io/templates: gateway
        labels:
          istio: ingressgateway
          istio.io/rev: REVISION
      spec:
        containers:
        - name: istio-proxy
          image: auto # The image will automatically update each time the pod starts.
  EOF
  
  kubectl apply -f gateway-deployment.yaml
  

  注: image が実際の Anthos Service Mesh プロキシ イメージで自動的に更新されない場合、コンテナは検出されず、エラーが発生します。次のステップについては、ゲートウェイのトラブルシューティングをご覧ください。

カナリア アップグレード（高度）

クラスタ内コントロール プレーンを使用していて、新しいコントロール プレーン リビジョンのロールアウトを段階的に行うには、カナリア アップグレード パターンを使用します。複数のバージョンのゲートウェイ Deployment を実行し、トラフィックのサブセットですべてが想定どおりに機能することを確認できます。たとえば、新しいリビジョンであるカナリアをロールアウトする場合は、ゲートウェイ Deployment のコピーを作成し、istio.io/rev=REVISION ラベルを新しいリビジョンと新しい名前に設定します（例: istio-ingressgateway-canary）。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: istio-ingressgateway-canary
  namespace: GATEWAY_NAMESPACE
spec:
  selector:
    matchLabels:
      istio: ingressgateway
  template:
    metadata:
      annotations:
        inject.istio.io/templates: gateway
      labels:
        istio: ingressgateway
        istio.io/rev: REVISION # Set to the control plane revision you want to deploy
    spec:
      containers:
      - name: istio-proxy
        image: auto

注: image が実際の Anthos Service Mesh プロキシ イメージで自動的に更新されない場合、コンテナは検出されず、エラーが発生します。次のステップについては、ゲートウェイのトラブルシューティングをご覧ください。

この Deployment が作成されると、同じ Service で選択された 2 つのバージョンのゲートウェイが作成されます。

kubectl get endpoints -o "custom-columns=NAME:.metadata.name,PODS:.subsets[*].addresses[*].targetRef.name"

NAME                   PODS
istio-ingressgateway   istio-ingressgateway-788854c955-8gv96,istio-ingressgateway-canary-b78944cbd-mq2qf

注: メッシュ内にデプロイされたアプリケーション サービスとは異なり、Istio で制御されない外部クライアントから直接トラフィックが送信されるため、Istio トラフィック シフトを使用してゲートウェイのバージョン間でトラフィックを分散させることはできません。代わりに、各 Deployment のレプリカの数でトラフィックの分散を制御できます。Istio の前に別のロードバランサを使用する場合は、それを使用してトラフィック分散を制御することもできます。

アプリケーションが期待どおりに機能していることを確認したら、次のコマンドを実行して、古い istio.io/rev ラベルが設定された Deployment を削除し、新しいバージョンに移行します。

kubectl delete deploy/istio-ingressgateway -n GATEWAY_NAMESPACE

新しいバージョンのゲートウェイでアプリケーションをテストするときに問題が発生した場合は、次のコマンドを実行して、新しい istio.io/rev ラベルが設定された Deployment を削除し、以前のバージョンに戻してください。

kubectl delete deploy/istio-ingressgateway-canary -n GATEWAY_NAMESPACE

詳細構成

ゲートウェイの最小 TLS バージョンを構成する

Anthos Service Mesh バージョン 1.14 以降の場合、ゲートウェイ サーバーのデフォルトの最小 TLS バージョンは 1.2 です。最小 TLS バージョンは、minProtocolVersion フィールドを使用して構成できます。詳細については、ServerTLSSettings をご覧ください。

ゲートウェイのトラブルシューティング

auto からゲートウェイ イメージを更新できない

ゲートウェイをデプロイまたはアップグレードすると、Anthos Service Mesh が image フィールドにプレースホルダとして auto を挿入します。変更用 Webhook を呼び出すと、Anthos Service Mesh でこのプレースホルダが自動的に実際の Anthos Service Mesh プロキシ イメージに置き換えられます。変更用 Webhook の呼び出しが失敗した場合、auto プレースホルダは残り、コンテナは検出されません。これは通常、名前空間ラベルが正しくないことが原因で発生します。正しい名前空間が構成されていることを確認してから、ゲートウェイを再度デプロイまたはアップグレードしてください。