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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    管理対象

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

    kubectl -n istio-system get controlplanerevision
    

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

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

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

    クラスタ内

    クラスタ内コントロール プレーンの場合、istiod Service と Deployment には通常 istio.io/rev=asm-1232-2 のようなリビジョン ラベルがあります。ここで、asm-1232-2 は Cloud Service Mesh のバージョンを表します。リビジョンは istiod Service 名の一部になります(例: istiod-asm-1232-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
    
  4. asmcli を使用して Cloud Service Mesh をインストールした場合は、--output_dir で指定したディレクトリに移動し、次に cdsamples ディレクトリに移動します。

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

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

    Ingress

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

    下り(外向き)

    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

ゲートウェイ セレクタ

istio-ingressgatewayistio-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
    

カナリア アップグレード(高度)

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

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

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

アプリケーションが期待どおりに機能していることを確認したら、次のコマンドを実行して、古い 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 バージョンを構成する

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

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

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

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