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

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

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

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

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

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

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

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. ゲートウェイの名前空間にリビジョン ラベルを適用することで、ゲートウェイで自動インジェクションを有効にします。リビジョン ラベルは、サイドカー インジェクタ Webhook によって使用され、挿入されたプロキシを特定のコントロール プレーン リビジョンに関連付けます。使用するリビジョン ラベルは、Google 管理のコントロール プレーンまたはクラスタ内コントロール プレーンのどちらをデプロイしたかによって異なります。

   Google マネージド

   Google 管理のコントロール プレーンの場合、リビジョン ラベルはリリース チャンネルに対応します。

   リビジョン ラベル	チャネル
   istio.io/rev=asm-managed	標準
   istio.io/rev=asm-managed-rapid	迅速
   istio.io/rev=asm-managed-stable	Stable

   ゲートウェイの名前空間は、サービスと同じリリース チャンネルにすることも、別のリリース チャンネルにすることもできます。1 つのクラスタでは同じリリース チャンネルを使用することをおすすめします。名前空間で使用されているリリース チャンネルを確認するには:

   kubectl get namespace NAMESPACE -L istio.io/rev
   

   クラスタ内

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

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

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

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

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

   出力中のメッセージ "istio-injection not found" は無視します。これは、今までは名前空間に istio-injection ラベルが付いていなかったことを意味します。Anthos Service Mesh の新規インストールや新規デプロイでは、こうなって当然です。名前空間に istio-injection とリビジョン ラベルの両方があると自動インジェクションが失敗するため、Anthos Service Mesh ドキュメント内のすべての kubectl label コマンドには istio-injection ラベルの削除が含まれています。

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 gateways/istio-ingressgateway
   

   Egress

   kubectl apply -n GATEWAY_NAMESPACE -f 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 管理のコントロール プレーン
Google 管理のコントロール プレーンのアップグレードは Google が管理しているため、ゲートウェイ Deployment を再起動するだけで、新しい Pod が最新の構成とバージョンで自動的に挿入されます。

kubectl rollout restart deployment istio-ingressgateway \
  -n GATEWAY_NAMESPACE

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

1. 名前空間またはゲートウェイ 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

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

クラスタ内コントロール プレーンを使用していて、新しいコントロール プレーン リビジョンのロールアウトを段階的に行うには、カナリア アップグレード パターンを使用します。複数のバージョンのゲートウェイ 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

この 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