クラスタ内コントロール プレーンでオプション機能を有効にする

このページでは、クラスタ内コントロール プレーンでオプション機能を有効にする方法について説明します。マネージド コントロール プレーンの詳細については、マネージド Cloud Service Mesh を構成するをご覧ください。

クラスタ内 Cloud Service Mesh をインストールする際、デフォルトで有効になる機能はプラットフォームによって異なります。Cloud Service Mesh をインストール（またはアップグレード）する際に、オーバーレイ ファイルを追加することによって、デフォルト構成をオーバーライドし、オプション機能を有効にできます。オーバーレイ ファイルは IstioOperator カスタム リソース（CR）を含む YAML ファイルで、これを使用してコントロール プレーンを構成します。オーバーレイ ファイルごとに機能を 1 つずつ指定します。複数のオーバーレイを重ねることができます。各オーバーレイ ファイルは、以前のレイヤの構成をオーバーライドします。

注意: asmcli install を使用すると、既存のコントロール プレーンの構成が上書きされます。既存のインストールでオプション機能を有効にする場合は、元の構成に残すすべてのファイルと、有効にする機能のオーバーレイ ファイルを指定してください。インストールに使用するオーバーレイ ファイルをソース コントロールに保存することをおすすめします。アップグレード時または追加のオプション機能を有効にしたときに、同じ構成をコントロール プレーンに適用できます。これにより、オプション機能を有効にするときにダウンタイムが発生しません。

オーバーレイ ファイルについて

このページのオーバーレイ ファイルは、GitHub の anthos-service-mesh パッケージにあります。これらのファイルには、デフォルト構成に対する一般的なカスタマイズが含まれています。これらのファイルはそのまま使用することも、必要に応じて変更を加えることもできます。

Google が提供する asmcli スクリプトを使用して Cloud Service Mesh をインストールする場合は、--option または --custom_overlay オプションで 1 つ以上のオーバーレイ ファイルを指定できます。anthos-service-mesh リポジトリ内のファイルを変更する必要がない場合は、--option を使用します。これにより、GitHub からファイルが取得されます。それ以外の場合は、オーバーレイ ファイルを変更してから、--custom_overlay オプションを使用して asmcli に渡します。

重要: オーバーレイ ファイルでは、IstioOperator CR を複数指定しないでください。これは、istioctl install がファイル内で最初に見つかった CR のみを適用するためです。

1 つのオーバーレイ ファイルに複数の CR を含めないでください	CR ごとに別々のオーバーレイ ファイルを作成します

オプション機能を有効にする方法

次の例は、オプション機能を有効にすることを目的とした、カスタム オーバーレイの使用についてのみ示すため簡略化されています。OTHER_FLAGS は、必須のインストール フラグに置き換えます。

重要: コマンドラインでファイルを指定する順番に注意してください。デフォルト機能に必要な構成を最初に指定してから、その後、必要に応じてオーバーレイ ファイルを指定してください。

asmcli install コマンドには、オプション機能を有効にする 2 つの方法があります。使用するメソッドは、オーバーレイ ファイルに変更を加える必要があるかどうかによって異なります。

• オーバーレイ ファイルを変更する必要がない場合は、--option を使用します。--option では、asmcli は GitHub リポジトリからファイルを取得するため、インターネットに接続している必要があります。

  ./asmcli install \
    OTHER_FLAGS \
    --option OPTION_NAME
  

  OPTION_NAME は、有効にするオプションに置き換えます。拡張子の .yaml は指定せず、オーバーレイ ファイルの名前（iap-operator、attached-cluster など）のみを含めるようにしてください。オプションの一覧については、anthos-service-mesh パッケージをご覧ください。

• オーバーレイ ファイルをカスタマイズする必要がある場合は、--custom_overlay を使用します。

  ./asmcli install \
    OTHER_FLAGS \
    --custom_overlay PATH_TO_FILE
  

  PATH_TO_FILE は、使用するオーバーレイ ファイルのパスに置き換えます。

オプション機能の YAML

以降のセクションでは、オプション機能とサポートされている機能を有効にするための YAML について説明します。

mTLS STRICT モード

アップグレードでの問題を防ぎ、柔軟性の高いインストールを可能にするため、global.mtls.enabled 構成は IstioOperator CR から削除されました。STRICT mTLS を有効にするには、代わりにピア認証ポリシーを構成してください。

Distroless プロキシ イメージ

コンテナ ランタイムの内容は、必要なパッケージのみに制限することをおすすめします。この方法により、セキュリティと共通脆弱性識別子（CVE）スキャナの信号対雑音比が改善されます。Istio は、distroless ベースイメージに基づくプロキシ イメージを提供します。

次の構成では、Cloud Service Mesh 全体で distroless イメージを有効にします。イメージタイプを変更するには、各 Pod を再起動して再挿入する必要があります。

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    defaultConfig:
      image:
        imageType: distroless

distroless イメージには、プロキシ以外のバイナリが含まれていません。したがって、シェルで exec を実行することはできません。また、コンテナ内で curl、ping などのデバッグ ユーティリティを使用することもできません。シェルを実行しようとすると、次のエラーが表示されます。

error: Internal error occurred: error executing command in container: failed to exec in container: failed to start exec "<container-id>"
OCI runtime exec failed: exec failed: container_linux.go:380: starting container process caused: exec: "sh": executable file not found in $PATH: unknown

特定の Pod でこれらのツールにアクセスする必要がある場合は、次の Pod アノテーションを使用して imageType をオーバーライドできます。

sidecar.istio.io/proxyImageType: debug

アノテーションを使用して Deployment のイメージタイプを変更した後、Deployment を再起動する必要があります。

kubectl rollout restart deployment -n NAMESPACE DEPLOYMENT_NAME

ほとんどの種類のプロキシ デバッグでは、デバッグ ベースイメージを必要としない istioctl proxy-cmd を使用してください。

カスタム レジストリにカスタム オーバーレイを使用する

カスタム コンテナ レジストリから Cloud Service Mesh をインストールする必要がある場合などに、カスタム レジストリにカスタム オーバーレイを使用できます。例:

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  hub: {private_registry_url}

カスタム コンテナ レジストリにミラーリングする必要がある Cloud Service Mesh のイメージは次のとおりです。

• Install-cni - gke.gcr.io/asm/install-cni:1.16.7-asm.22
• マネージド データプレーン - gke.gcr.io/asm/mdp:1.16.7-asm.22
• 試験運用 - gke.gcr.io/asm/pilot:1.16.7-asm.22
• Proxyv2 - gke.gcr.io/asm/proxyv2:1.16.7-asm.22

注: 正規サービスを使用する場合、カスタム コンテナ レジストリ gcr.io/kubebuilder/kube-rbac-proxy:v0.13.1 および gke.gcr.io/asm/canonical-service-controller:1.10.3-asm.16 のミラーリングも必要となります。

非公開レジストリにイメージを追加する

Cloud Service Mesh イメージを非公開レジストリに push するには、次の手順を完了します。

注: gcr.io から pull して非公開レジストリに push できるクライアントを使用してください。

1. Cloud Service Mesh イメージを pull します。

   docker pull gke.gcr.io/asm/install-cni:1.16.7-asm.22
   docker pull gke.gcr.io/asm/mdp:1.16.7-asm.22
   docker pull gke.gcr.io/asm/pilot:1.16.7-asm.22
   docker pull gke.gcr.io/asm/proxyv2:1.16.7-asm.22
   

2. 非公開レジストリの URL の変数を作成します。

   export PRIVATE_REGISTRY_URL=PRIVATE_REGISTRY_URL
   

   PRIVATE_REGISTRY_URL は限定公開レジストリの URL に置き換えます。
3. イメージに非公開レジストリの URL をタグ付けします。

   docker tag gke.gcr.io/asm/install-cni:1.16.7-asm.22 \
    ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/install-cni:1.16.7-asm.22
   docker tag gke.gcr.io/asm/mdp:1.16.7-asm.22 \
    ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/mdp:1.16.7-asm.22
   docker tag gke.gcr.io/asm/pilot:1.16.7-asm.22 \
    ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/pilot:1.16.7-asm.22
   docker tag gke.gcr.io/asm/proxyv2:1.16.7-asm.22 \
    ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/proxyv2:1.16.7-asm.22
   

4. タグ付きのイメージを非公開レジストリに push します。

   docker push ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/install-cni:1.16.7-asm.22
   docker push ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/mdp:1.16.7-asm.22
   docker push ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/pilot:1.16.7-asm.22
   docker push ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/proxyv2:1.16.7-asm.22
   

5. （省略可）正規サービスを使用する場合は、正規サービス イメージを限定公開レジストリに追加します。
   1. Cloud Service Mesh の正規サービス イメージを pull します。

              docker pull gcr.io/kubebuilder/kube-rbac-proxy:v0.13.1
              docker pull gke.gcr.io/asm/canonical-service-controller:1.10.3-asm.16
              

   2. イメージに限定公開レジストリの URL をタグ付けします。

              docker tag gcr.io/kubebuilder/kube-rbac-proxy:v0.13.1 \
              ${PRIVATE_REGISTRY_URL}/gcr.io/kubebuilder/kube-rbac-proxy:v0.13.1
              docker tag gke.gcr.io/asm/canonical-service-controller:1.10.3-asm.16 \
              ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/canonical-service-controller:1.10.3-asm.16
              

   3. タグ付きのイメージを非公開レジストリに push します。

              docker push ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/kube-rbac-proxy:v0.13.1
              docker push ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/canonical-service-controller:1.10.3-asm.16
              

タグ付けされたイメージを非公開レジストリから pull できれば、処理が成功しています。

終了ドレイン期間の延長

デフォルトでは、Pod の終了時に Envoy は既存の接続が完了するまでに 5 秒間（5s）待機します。

Pod terminationGracePeriodSeconds は terminationDrainDuration 値より大きくする必要があります。

詳細については、グローバル メッシュ オプションをご覧ください。

---
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    defaultConfig:
      terminationDrainDuration: 30s

アクセスログを有効にする

---
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    accessLogFile: "/dev/stdout"

詳細については、Envoy のアクセス ロギングを有効にするをご覧ください。

Cloud Trace

Cloud Trace は、次のプラットフォームの Cloud Service Mesh インストールでご利用いただけます。

• Google Cloud 上の GKE
• Cloud Service Mesh 認証局を使用してインストールする場合、オンプレミスの GKE Enterprise クラスタ

---
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    enableTracing: true
  values:
    global:
      proxy:
        tracer: stackdriver

詳細については、トレースへのアクセスをご覧ください。

Egress ゲートウェイ経由の下り（外向き）

ゲートウェイのインストールとアップグレードの説明に従って、挿入されたゲートウェイをインストールすることをおすすめします。

Istio Container Network Interface

Istio Container Network Interface（CNI）を有効にする方法は、Cloud Service Mesh がインストールされている環境によって異なります。

1. ネットワーク ポリシーを有効にします。

2. 実際のプラットフォームに合ったオーバーレイ ファイルを選択します。

GKE で CNI を有効にする

---
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  components:
    cni:
      enabled: true
      namespace: kube-system
  values:
    cni:
      cniBinDir: /home/kubernetes/bin
      excludeNamespaces:
        - istio-system
        - kube-system

オンプレミスで CNI を有効にする

---
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  components:
    cni:
      enabled: true
      namespace: kube-system
  values:
    cni:
      cniBinDir: /opt/cni/bin
      excludeNamespaces:
        - istio-system
        - kube-system
        - gke-system

Google Cloud 外のトラフィック ログを有効にする

Istio CA を使用して Google Cloud の外部に Cloud Service Mesh をインストールすると、デフォルトで Prometheus に指標が報告されます。このオプションを使用して、代わりにトラフィック ログの報告を有効にするか、または Prometheus と Stackdriver の両方への報告を有効にすると、Cloud Service Mesh ダッシュボードを使用できるようになります。

Stackdriver のみ

---
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  values:
    telemetry:
      enabled: true
      v2:
        enabled: true
        prometheus:
          enabled: false
        stackdriver:
          enabled: true

Stackdriver と Prometheus

---
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  values:
    telemetry:
      enabled: true
      v2:
        enabled: true
        prometheus:
          enabled: true
        stackdriver:
          enabled: true

内部ロードバランサを有効にする

GKE で内部ロードバランサを設定するには、ゲートウェイのインストールとアップグレードの説明に従って、挿入されたゲートウェイをインストールすることをおすすめします。ゲートウェイ Service を構成するときに、アノテーション networking.gke.io/load-balancer-type: "Internal" を含めます。

Ingress ゲートウェイの外部証明書の管理

Envoy の SDS を使用して Ingress ゲートウェイで外部証明書の管理を有効にする方法については、セキュア ゲートウェイをご覧ください。