ゲートウェイのインストールとアップグレード
Anthos Service Mesh では、サービス メッシュの一部としてゲートウェイをデプロイし、管理できます。ゲートウェイでは、メッシュのエッジで動作し、受信または送信 HTTP / TCP 接続を処理するロードバランサを記述します。ゲートウェイは、メッシュ内外に送信されるトラフィックをきめ細かく制御する Envoy プロキシです。ゲートウェイは、主に上り(内向き)トラフィックの管理に使用されますが、他の種類のトラフィックを管理するように構成することもできます。次に例を示します。
Egress ゲートウェイ: Egress ゲートウェイを使用すると、メッシュから外部に送信されるトラフィック専用の Exit ノードを構成できます。これにより、外部ネットワークへのアクセスを許可するサービスを制限できます。また、下り(外向き)トラフィックを安全に制御し、メッシュのセキュリティを強化することもできます。
East-West ゲートウェイ: East-West トラフィックのプロキシです。サービス ワークロードが異なるネットワーク上のマルチプライマリ メッシュのクラスタ境界を越えて通信できるようにします。デフォルトでは、このゲートウェイは、インターネットに公開されます。
このページでは、ゲートウェイ プロキシをデプロイしてアップグレードするためのベスト プラクティスと、独自の istio-ingressgateway
および istio-egressgateway
ゲートウェイ プロキシを構成する例について説明します。ゲートウェイ構成をゲートウェイ プロキシに適用することで、トラフィック分割、リダイレクト、再試行ロジックなどを実装できます。その場合、同じ API リソースにアプリケーション層トラフィック ルーティング(L7)を追加せずに、仮想サービスをゲートウェイにバインドします。これにより、サービス メッシュ内の他のデータプレーン トラフィックと同様にゲートウェイ トラフィックを管理できます。
ゲートウェイはさまざまな方法でデプロイできます。また、同じクラスタ内で複数のトポロジを使用することもできます。このトポロジの詳細については、Istio ドキュメントのゲートウェイ デプロイ トポロジをご覧ください。
ゲートウェイのデプロイに関するベスト プラクティス
ゲートウェイをデプロイするためのベスト プラクティスは、マネージド データプレーンと非マネージド データプレーンのどちらを使用するかによって異なります。
マネージド データプレーンのベスト プラクティス
- マネージド データプレーンを有効にします。
- マネージド リビジョン ラベルを名前空間に追加します。
- コントロール プレーンとゲートウェイを個別にデプロイして管理します。
- セキュリティのベスト プラクティスとして、ゲートウェイをコントロール プレーンとは異なる名前空間にデプロイすることをおすすめします。
- 自動サイドカー インジェクション(自動インジェクション)を使用して、サービスのサイドカー プロキシを挿入する場合と同様にゲートウェイのプロキシ構成を挿入します。
ベスト プラクティスは次のとおりです。
- 最新の強化機能とセキュリティ アップデートを使用して、マネージド ゲートウェイを常に最新の状態にします。
- Anthos Service Mesh が管理するデータプレーンに、ゲートウェイ インスタンスの管理とメンテナンスをオフロードします。
非マネージド データプレーンのベスト プラクティス
- コントロール プレーンとゲートウェイを個別にデプロイして管理します。
- セキュリティのベスト プラクティスとして、ゲートウェイをコントロール プレーンとは異なる名前空間にデプロイすることをおすすめします。
- 自動サイドカー インジェクション(自動インジェクション)を使用して、サービスのサイドカー プロキシを挿入する場合と同様にゲートウェイのプロキシ構成を挿入します。
ベスト プラクティスは次のとおりです。
- クラスタ全体に対する権限を持つように権限昇格を行わなくても、名前空間管理者がゲートウェイを管理できるようにします。
- 管理者が、Kubernetes アプリケーションの管理に使用しているデプロイツールやメカニズムを使用して、ゲートウェイのデプロイや管理を行えるようにします。
- 管理者にゲートウェイ Deployment に対するフルコントロールを許可し、操作を簡単に行えるようにします。新しいアップグレードが利用可能になるか、構成が変更されたときに、管理者が再起動を行うだけで、ゲートウェイ Pod が更新されるようにします。これにより、サービスでサイドカー プロキシを運用する場合と同じ方法でゲートウェイ Deployment を運用できるようになります。
ゲートウェイをデプロイする
ユーザーが既存のデプロイツールを使用できるようにするため、Anthos Service Mesh では、Istio と同じ方法(IstioOperator
、Helm、Kubernetes YAML)でゲートウェイのデプロイを行うことができます。どの方法でも同じ結果になります。慣れている方法を選択することもできますが、Kubernetes YAML をおすすめします。こちらのほうが変更が簡単で、ソース制御にハイドレードされたマニフェストを保存できます。
ゲートウェイの名前空間をまだ作成していない場合は作成します。
GATEWAY_NAMESPACE
は、名前空間に置き換えます。kubectl create namespace GATEWAY_NAMESPACE
自動挿入を有効にするには、デフォルトのインジェクション ラベルを使用して名前空間にラベルを付けるか(デフォルトのタグを設定した場合)、リビジョン ラベルを名前空間に追加します。追加するラベルは、マネージド 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-1178-20
のようなリビジョン ラベルがあります。ここで、asm-1178-20
は Anthos Service Mesh のバージョンを表します。リビジョンはistiod
Service 名の一部になります(例:istiod-asm-1178-20.istio-system
)。次のコマンドを使用して、クラスタ内コントロール プレーンの
istiod
のリビジョン ラベルを確認します。kubectl get deploy -n istio-system -l app=istiod \ -o=jsonpath='{.items[*].metadata.labels.istio\.io\/rev}''{"\n"}'
インジェクションの名前空間を有効にします。
REVISION
は、リビジョン ラベルの値に置き換えます。kubectl label namespace GATEWAY_NAMESPACE istio-injection- istio.io/rev=REVISION --overwrite
asmcli
を使用して Anthos Service Mesh をインストールした場合は、--output_dir
で指定したディレクトリに移動し、次にcd
でsamples
ディレクトリに移動します。asmcli
を使用してインストールしなかった場合は、anthos-service-mesh
リポジトリからゲートウェイの構成ファイルをコピーします。samples/gateways/
ディレクトリにあるゲートウェイ構成のサンプルをそのままデプロイするか、必要に応じて変更します。Ingress
kubectl apply -n GATEWAY_NAMESPACE -f samples/gateways/istio-ingressgateway
Egress
kubectl apply -n GATEWAY_NAMESPACE -f samples/gateways/istio-egressgateway
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-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
カナリア アップグレード(高度)
クラスタ内コントロール プレーンを使用していて、新しいコントロール プレーン リビジョンのロールアウトを段階的に行うには、カナリア アップグレード パターンを使用します。複数のバージョンのゲートウェイ 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.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
プレースホルダは残り、コンテナは検出されません。これは通常、名前空間ラベルが正しくないことが原因で発生します。正しい名前空間が構成されていることを確認してから、ゲートウェイを再度デプロイまたはアップグレードしてください。