ゲートウェイのインストール

Istioはサービスメッシュの作成とともに、メッシュのエッジで動作するEnvoyプロキシであるゲートウェイを管理することもできます。これにより、メッシュに出入りするトラフィックを細かく制御できます。

Istioの組み込みの構成プロファイルの一部では、インストール時にゲートウェイがデプロイされます。たとえば、デフォルト設定でistioctl installを呼び出すと、コントロールプレーンとともにイングレスゲートウェイがデプロイされます。評価やシンプルなユースケースには適していますが、これによりゲートウェイがコントロールプレーンに結合され、管理とアップグレードが複雑になります。本番環境でのIstioデプロイメントでは、これらを分離して独立した運用を可能にすることを強く推奨します。

このガイドに従って、Istioの本番環境インストールで1つ以上のゲートウェイを個別にデプロイおよび管理してください。

前提条件

このガイドでは、進める前にIstioコントロールプレーンがインストールされている必要があります。

ゲートウェイのデプロイ

Istioサイドカーインジェクションと同じメカニズムを使用して、ゲートウェイのEnvoyプロキシ構成も同様に自動インジェクションできます。

ゲートウェイのデプロイメントに自動インジェクションを使用することをお勧めします。これにより、開発者はゲートウェイのデプロイメントを完全に制御できると同時に、運用を簡素化できます。新しいアップグレードが利用可能になったり、構成が変更されたりした場合、ゲートウェイポッドは再起動するだけで更新できます。これにより、ゲートウェイのデプロイメントを運用するエクスペリエンスがサイドカーの運用と同じになります。

既存のデプロイメントツールを使用しているユーザーをサポートするために、Istioはゲートウェイをデプロイするためのいくつかの異なる方法を提供しています。各方法で同じ結果が得られます。最も使い慣れた方法を選択してください。

以下にリストされているすべての方法は、実行時に追加のポッド設定を投入するためにインジェクションに依存しています。これをサポートするには、ゲートウェイがデプロイされている名前空間にistio-injection=disabledラベルを付けてはいけません。そうすると、ポッドが起動に失敗し、autoイメージ（ポッドが作成されたときに置き換えられることを目的としたプレースホルダー）をプルしようとします。

最初に、ingress.yamlという名前のIstioOperator構成ファイルをセットアップします

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
  name: ingress
spec:
  profile: empty # Do not install CRDs or the control plane
  components:
    ingressGateways:
    - name: istio-ingressgateway
      namespace: istio-ingress
      enabled: true
      label:
        # Set a unique label for the gateway. This is required to ensure Gateways
        # can select this workload
        istio: ingressgateway
  values:
    gateways:
      istio-ingressgateway:
        # Enable gateway injection
        injectionTemplate: gateway

次に、標準のistioctlコマンドを使用してインストールします

$ kubectl create namespace istio-ingress
$ istioctl install -f ingress.yaml

標準のhelmコマンドを使用してインストールします

$ kubectl create namespace istio-ingress
$ helm install istio-ingressgateway istio/gateway -n istio-ingress

可能な構成値を表示するには、helm show values istio/gatewayを実行します。HelmリポジトリのREADMEには、使用法に関する追加情報が含まれています。

OpenShiftクラスターにゲートウェイをデプロイするときは、デフォルト値を上書きするためにopenshiftプロファイルを使用します（例：

$ helm install istio-ingressgateway istio/gateway -n istio-ingress --set global.platform=openshift

最初に、ingress.yamlという名前のKubernetes構成をセットアップします

apiVersion: v1
kind: Service
metadata:
  name: istio-ingressgateway
  namespace: istio-ingress
spec:
  type: LoadBalancer
  selector:
    istio: ingressgateway
  ports:
  - port: 80
    name: http
  - port: 443
    name: https
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: istio-ingressgateway
  namespace: istio-ingress
spec:
  selector:
    matchLabels:
      istio: ingressgateway
  template:
    metadata:
      annotations:
        # Select the gateway injection template (rather than the default sidecar template)
        inject.istio.io/templates: gateway
      labels:
        # Set a unique label for the gateway. This is required to ensure Gateways can select this workload
        istio: ingressgateway
        # Enable gateway injection. If connecting to a revisioned control plane, replace with "istio.io/rev: revision-name"
        sidecar.istio.io/inject: "true"
    spec:
      # Allow binding to all ports (such as 80 and 443)
      securityContext:
        sysctls:
        - name: net.ipv4.ip_unprivileged_port_start
          value: "0"
      containers:
      - name: istio-proxy
        image: auto # The image will automatically update each time the pod starts.
        # Drop all privileges, allowing to run as non-root
        securityContext:
          capabilities:
            drop:
            - ALL
          runAsUser: 1337
          runAsGroup: 1337
---
# Set up roles to allow reading credentials for TLS
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: istio-ingressgateway-sds
  namespace: istio-ingress
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: istio-ingressgateway-sds
  namespace: istio-ingress
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: istio-ingressgateway-sds
subjects:
- kind: ServiceAccount
  name: default

次に、クラスターに適用します

$ kubectl create namespace istio-ingress
$ kubectl apply -f ingress.yaml

ゲートウェイの管理

以下では、インストール後のゲートウェイの管理方法について説明します。使用方法の詳細については、イングレスおよびエグレスタスクに従ってください。

ゲートウェイセレクター

ゲートウェイデプロイメントのポッドのラベルは、Gateway構成リソースで使用されるため、Gatewayセレクターがこれらのラベルと一致していることが重要です。

たとえば、上記のデプロイメントでは、istio=ingressgatewayラベルがゲートウェイポッドに設定されています。これらのデプロイメントにGatewayを適用するには、同じラベルを選択する必要があります

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

ゲートウェイのデプロイメントトポロジー

メッシュ構成とユースケースに応じて、さまざまな方法でゲートウェイをデプロイできます。以下に、いくつかの異なるゲートウェイデプロイメントパターンを示します。これらのパターンのうち複数を同じクラスター内で使用できることに注意してください。

共有ゲートウェイ

このモデルでは、単一の集中ゲートウェイが多くのアプリケーション（おそらく多くの名前空間にわたって）で使用されます。ingress名前空間のゲートウェイは、ルートの所有権をアプリケーション名前空間に委譲しますが、TLS構成の制御は保持します。

このモデルは、外部に公開したいアプリケーションが多数あり、それらが共有インフラストラクチャを使用できる場合に適しています。また、多くのアプリケーションで同じドメインまたはTLS証明書が共有されているユースケースにも適しています。

専用アプリケーションゲートウェイ

このモデルでは、アプリケーションの名前空間に独自の専用ゲートウェイインストールがあります。これにより、単一の名前空間に完全な制御と所有権を与えることができます。このレベルの分離は、厳格なパフォーマンスまたはセキュリティ要件を持つ重要なアプリケーションに役立ちます。

Dedicated application gateway — 専用アプリケーションゲートウェイ

Istioの前に別のロードバランサーがない限り、これは通常、各アプリケーションに独自のIPアドレスがあることを意味します。これにより、DNS構成が複雑になる可能性があります。

ゲートウェイのアップグレード

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

ゲートウェイはポッドインジェクションを利用するため、作成された新しいゲートウェイポッドには、バージョンを含む最新の構成が自動的にインジェクションされます。

ゲートウェイ構成の変更を適用するには、kubectl rollout restart deploymentなどのコマンドを使用してポッドを再起動するだけで済みます。

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

In place upgrade in progress — インプレースアップグレードの進行状況

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

新しいコントロールプレーンリビジョンのロールアウトをよりゆっくり制御したい場合は、ゲートウェイデプロイメントの複数のバージョンを実行できます。たとえば、新しいリビジョンcanaryをロールアウトする場合は、istio.io/rev=canaryラベルを設定してゲートウェイデプロイメントのコピーを作成します

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

このデプロイメントが作成されると、同じサービスによって選択された2つのバージョンのゲートウェイが存在することになります

$ kubectl get endpoints -n istio-ingress -o "custom-columns=NAME:.metadata.name,PODS:.subsets[*].addresses[*].targetRef.name"
NAME                   PODS
istio-ingressgateway   istio-ingressgateway-...,istio-ingressgateway-canary-...

Canary upgrade in progress — カナリアアップグレードの進行状況

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

外部トラフィックシフトによるカナリアアップグレード（高度）

カナリアアップグレードアプローチのバリアントは、外部ロードバランサーやDNSなど、Istio外部の高レベル構造を使用してバージョン間でトラフィックをシフトすることです。

Canary upgrade in progress with external traffic shifting — 外部トラフィックシフトによるカナリアアップグレードの進行状況

これにより、詳細な制御が可能になりますが、一部の環境では設定が不適切または過度に複雑になる可能性があります。

クリーンアップ

Istioイングレスゲートウェイのクリーンアップ

$ istioctl uninstall --istioNamespace istio-ingress -y --purge
$ kubectl delete ns istio-ingress