クラスタ内コントロール プレーンでオプション機能を有効にする
このページでは、クラスタ内コントロール プレーンでオプション機能を有効にする方法について説明します。マネージド コントロール プレーンの詳細については、マネージド Cloud Service Mesh を構成するをご覧ください。
クラスタ内 Cloud Service Mesh をインストールする際、デフォルトで有効になる機能はプラットフォームによって異なります。Cloud Service Mesh をインストール(またはアップグレード)する際に、オーバーレイ ファイルを追加することによって、デフォルト構成をオーバーライドし、オプション機能を有効にできます。オーバーレイ ファイルは IstioOperator
カスタム リソース(CR)を含む YAML ファイルで、これを使用してコントロール プレーンを構成します。オーバーレイ ファイルごとに機能を 1 つずつ指定します。複数のオーバーレイを重ねることができます。各オーバーレイ ファイルは、以前のレイヤの構成をオーバーライドします。
オーバーレイ ファイルについて
このページのオーバーレイ ファイルは、GitHub の anthos-service-mesh
パッケージにあります。これらのファイルには、デフォルト構成に対する一般的なカスタマイズが含まれています。これらのファイルはそのまま使用することも、必要に応じて変更を加えることもできます。
Google が提供する asmcli
スクリプトを使用して Cloud Service Mesh をインストールする場合は、--option
または --custom_overlay
オプションで 1 つ以上のオーバーレイ ファイルを指定できます。anthos-service-mesh
リポジトリ内のファイルを変更する必要がない場合は、--option
を使用します。これにより、GitHub からファイルが取得されます。それ以外の場合は、オーバーレイ ファイルを変更してから、--custom_overlay
オプションを使用して asmcli
に渡します。
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
などのデバッグ ユーティリティを使用することもできません。
curl マンドを実行すると、次のエラーが表示されます。
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: unable to start container process: exec: "curl": executable file not found in $PATH: unknown
shell マンドを実行すると、次のエラーが表示されます。
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.23.2-asm.2
- マネージド データプレーン -
gke.gcr.io/asm/mdp:1.23.2-asm.2
- 試験運用 -
gke.gcr.io/asm/pilot:1.23.2-asm.2
- Proxyv2 -
gke.gcr.io/asm/proxyv2:1.23.2-asm.2
非公開レジストリにイメージを追加する
Cloud Service Mesh イメージを非公開レジストリに push するには、次の手順を完了します。
-
Cloud Service Mesh イメージを pull します。
docker pull gke.gcr.io/asm/install-cni:1.23.2-asm.2 docker pull gke.gcr.io/asm/mdp:1.23.2-asm.2 docker pull gke.gcr.io/asm/pilot:1.23.2-asm.2 docker pull gke.gcr.io/asm/proxyv2:1.23.2-asm.2
-
非公開レジストリの URL の変数を作成します。
export PRIVATE_REGISTRY_URL=PRIVATE_REGISTRY_URL
PRIVATE_REGISTRY_URL
は限定公開レジストリの URL に置き換えます。 -
イメージに非公開レジストリの URL をタグ付けします。
docker tag gke.gcr.io/asm/install-cni:1.23.2-asm.2 \ ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/install-cni:1.23.2-asm.2 docker tag gke.gcr.io/asm/mdp:1.23.2-asm.2 \ ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/mdp:1.23.2-asm.2 docker tag gke.gcr.io/asm/pilot:1.23.2-asm.2 \ ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/pilot:1.23.2-asm.2 docker tag gke.gcr.io/asm/proxyv2:1.23.2-asm.2 \ ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/proxyv2:1.23.2-asm.2
- タグ付きのイメージを非公開レジストリに push します。
docker push ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/install-cni:1.23.2-asm.2 docker push ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/mdp:1.23.2-asm.2 docker push ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/pilot:1.23.2-asm.2 docker push ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/proxyv2:1.23.2-asm.2
- (省略可)正規サービスを使用する場合は、正規サービス イメージを限定公開レジストリに追加します。
- 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
- イメージに限定公開レジストリの 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
- タグ付きのイメージを非公開レジストリに 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
- Cloud Service Mesh の正規サービス イメージを pull します。
タグ付けされたイメージを非公開レジストリから pull できれば、処理が成功しています。
終了ドレイン期間の延長
デフォルトでは、Pod の終了時に Envoy は既存の接続が完了するまでに 5 秒間(5s
)待機します。
Pod terminationGracePeriodSeconds
は terminationDrainDuration
値より大きくする必要があります。
詳細については、グローバル メッシュ オプションをご覧ください。
---
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
meshConfig:
defaultConfig:
terminationDrainDuration: 30s
アクセスログを有効にする
詳細については、Envoy のアクセス ロギングを有効にするをご覧ください。
Cloud Trace
Cloud Trace は、次のプラットフォームの Cloud Service Mesh インストールでご利用いただけます。
- Google Cloud 上の GKE
- Cloud Service Mesh 認証局を使用してインストールする場合、オンプレミスの GKE Enterprise クラスタ
詳細については、トレースへのアクセスをご覧ください。
Egress ゲートウェイ経由の下り(外向き)
ゲートウェイのインストールとアップグレードの説明に従って、挿入されたゲートウェイをインストールすることをおすすめします。
Istio Container Network Interface
Istio Container Network Interface(CNI)を有効にする方法は、Cloud Service Mesh がインストールされている環境によって異なります。
実際のプラットフォームに合ったオーバーレイ ファイルを選択します。
GKE で CNI を有効にする
オンプレミスで CNI を有効にする
Google Cloud 外のトラフィック ログを有効にする
Istio CA を使用して Google Cloud の外部に Cloud Service Mesh をインストールすると、デフォルトで Prometheus に指標が報告されます。このオプションを使用して、代わりにトラフィック ログの報告を有効にするか、または Prometheus と Stackdriver の両方への報告を有効にすると、Cloud Service Mesh ダッシュボードを使用できるようになります。
Stackdriver のみ
Stackdriver と Prometheus
内部ロードバランサを有効にする
GKE で内部ロードバランサを設定するには、ゲートウェイのインストールとアップグレードの説明に従って、挿入されたゲートウェイをインストールすることをおすすめします。ゲートウェイ Service を構成するときに、アノテーション networking.gke.io/load-balancer-type: "Internal"
を含めます。
Ingress ゲートウェイの外部証明書の管理
Envoy の SDS を使用して Ingress ゲートウェイで外部証明書の管理を有効にする方法については、セキュア ゲートウェイをご覧ください。