クラスタ内コントロール プレーンでオプション機能を有効にする
このページでは、クラスタ内コントロール プレーンでオプション機能を有効にする方法について説明します。マネージド コントロール プレーンの詳細については、マネージド Anthos Service Mesh の構成をご覧ください。
Anthos Service Mesh をインストールする際、デフォルトで有効になる機能はプラットフォームによって異なります。オプション機能を有効にするには、Anthos Service Mesh をインストール(またはアップグレード)する際に、オーバーレイ ファイルを追加します。オーバーレイ ファイルは IstioOperator
カスタム リソース(CR)を含む YAML ファイルで、これを使用してコントロール プレーンを構成します。オーバーレイ ファイルでデフォルトの構成をオーバーライドして、オプション機能を有効にする、またはデフォルトの機能を無効にすることができます。オーバーレイ ファイルごとに機能を 1 つずつ指定します。複数のオーバーレイを重ねることができます。各オーバーレイ ファイルは、以前のレイヤの構成をオーバーライドします。
オーバーレイ ファイルについて
このページのオーバーレイ ファイルは、GitHub の anthos-service-mesh
パッケージにあります。これらのファイルには、デフォルト構成に対する一般的なカスタマイズが含まれています。これらのファイルはそのまま使用することも、必要に応じて変更を加えることもできます。
Google が提供する asmcli
スクリプトを使用して Anthos 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
は、有効にするオプションに置き換えます。オプションの一覧については、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 ベースイメージに基づくプロキシ イメージを提供します。
次の構成では、Anthos 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
を使用してください。
カスタム レジストリにカスタム オーバーレイを使用する
カスタム コンテナ レジストリから Anthos Service Mesh をインストールする必要がある場合などに、カスタム レジストリにカスタム オーバーレイを使用できます。次に例を示します。
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
hub: {private_registry_url}
カスタム コンテナ レジストリにミラーリングする必要がある Anthos Service Mesh のイメージは次のとおりです。
- Install-cni -
gcr.io/gke-release/asm/install-cni:1.14.6-asm.16
- マネージド データプレーン -
gcr.io/gke-release/asm/mdp:1.14.6-asm.16
- パイロット -
gcr.io/gke-release/asm/pilot:1.14.6-asm.16
- Proxyv2 -
gcr.io/gke-release/asm/proxyv2:1.14.6-asm.16
限定公開レジストリにイメージを追加する
Anthos Service Mesh イメージを非公開レジストリに push するには、次の手順を完了します。
-
Anthos Service Mesh イメージを pull します。
docker pull gcr.io/gke-release/asm/install-cni:1.14.6-asm.16 docker pull gcr.io/gke-release/asm/mdp:1.14.6-asm.16 docker pull gcr.io/gke-release/asm/pilot:1.14.6-asm.16 docker pull gcr.io/gke-release/asm/proxyv2:1.14.6-asm.16
-
非公開レジストリの URL の変数を作成します。
export PRIVATE_REGISTRY_URL=PRIVATE_REGISTRY_URL
PRIVATE_REGISTRY_URL
は非公開レジストリの URL に置き換えます。 -
イメージに非公開レジストリの URL をタグ付けします。
docker tag gcr.io/gke-release/asm/install-cni:1.14.6-asm.16 \ ${PRIVATE_REGISTRY_URL}/gcr.io/gke-release/asm/install-cni:1.14.6-asm.16 docker tag gcr.io/gke-release/asm/mdp:1.14.6-asm.16 \ ${PRIVATE_REGISTRY_URL}/gcr.io/gke-release/asm/mdp:1.14.6-asm.16 docker tag gcr.io/gke-release/asm/pilot:1.14.6-asm.16 \ ${PRIVATE_REGISTRY_URL}/gcr.io/gke-release/asm/pilot:1.14.6-asm.16 docker tag gcr.io/gke-release/asm/proxyv2:1.14.6-asm.16 \ ${PRIVATE_REGISTRY_URL}/gcr.io/gke-release/asm/proxyv2:1.14.6-asm.16
- タグ付きのイメージを限定公開レジストリに push します。
docker push ${PRIVATE_REGISTRY_URL}/gcr.io/gke-release/asm/install-cni:1.14.6-asm.16 docker push ${PRIVATE_REGISTRY_URL}/gcr.io/gke-release/asm/mdp:1.14.6-asm.16 docker push ${PRIVATE_REGISTRY_URL}/gcr.io/gke-release/asm/pilot:1.14.6-asm.16 docker push ${PRIVATE_REGISTRY_URL}/gcr.io/gke-release/asm/proxyv2:1.14.6-asm.16
- (省略可)正規サービスを使用する場合は、正規サービス イメージを限定公開レジストリに追加します。
- Anthos Service Mesh の正規サービス イメージを pull します。
docker pull gcr.io/kubebuilder/kube-rbac-proxy:v0.5.0 docker pull gcr.io/gke-release/asm/canonical-service-controller:1.10.3-asm.16
- イメージに限定公開レジストリの URL をタグ付けします。
docker tag gcr.io/kubebuilder/kube-rbac-proxy:v0.5.0 \ ${PRIVATE_REGISTRY_URL}/gcr.io/kubebuilder/kube-rbac-proxy:v0.5.0 docker tag gcr.io/gke-release/asm/canonical-service-controller:1.10.3-asm.16 \ ${PRIVATE_REGISTRY_URL}/gcr.io/gke-release/asm/canonical-service-controller:1.10.3-asm.16
- タグ付きのイメージを限定公開レジストリに push します。
docker push ${PRIVATE_REGISTRY_URL}/gcr.io/gke-release/asm/kube-rbac-proxy:v0.5.0 docker push ${PRIVATE_REGISTRY_URL}/gcr.io/gke-release/asm/canonical-service-controller:1.10.3-asm.16
- Anthos Service Mesh の正規サービス イメージを pull します。
タグ付けされたイメージを限定公開レジストリから pull できれば、処理が成功しています。
Envoy を stdout に出力する
詳細については、Envoy のアクセス ロギングを有効にするをご覧ください。
Cloud Trace
Cloud Trace は、次のプラットフォームの Anthos Service Mesh インストールでご利用いただけます。
- Google Cloud 上の GKE
- Anthos Service Mesh 認証局(Mesh CA)を使用してインストールする場合、オンプレミスの GKE Enterprise クラスタ
料金の詳細については、Cloud Trace の料金ページをご覧ください。
デフォルトのサンプリング レートは 1% ですが、tracing.sampling
値を指定してデフォルトをオーバーライドできます。値は 0.01 単位で、0.0~100.0 の範囲から設定してください。たとえば、10,000 件ごとに 5 件のリクエストをトレースするには、0.05 を使用します。
次の例は、100& のサンプリング レートを示しています(この操作は、デモまたはトラブルシューティングの目的でのみ行います)。
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
meshConfig:
enableTracing: true
defaultConfig:
tracing:
sampling: 100
values:
global:
proxy:
tracer: stackdriver
現在、トレーサー構成はプロキシ ブートストラップ構成の一部になっているため、トレーサーの更新を取得するためには、Pod を再起動して、再挿入する必要があります。たとえば、次のコマンドを使用すると、再起動 Pod をデプロイメントに入れることができます。
kubectl rollout restart deployment -n NAMESPACE DEPLOYMENT_NAME
トレース コンテキストの伝播
サイドカー プロキシは、トレーススパンを自動的に送信できますが、トレース全体を関連付けるにはなんらかの情報が必要になります。このため、プロキシがスパン情報の送信時にスパンを 1 つのトレースに正しく関連付けられるように、適切な HTTP ヘッダーを伝播する必要があります。
これを行うには、受信リクエストから適切なヘッダーを収集し、発信リクエストに反映する必要があります。Anthos Service Mesh Stackdriver のトレース構成は、次のいずれかのヘッダー形式を受け入れ、次のすべての形式を伝播します。
- B3(
x-b3-traceid
、x-b3-spanid
、x-b3parentspanid
、x-b3-sampled
、x-b3-flags
) - W3C TraceContext(
traceparent
) - Google Cloud Trace(
x-cloud-trace-context
) - gRPC TraceBin(
grpc-trace-bin
)
アプリケーションは、これらの形式のいずれかを使用してトレース コンテキストを伝播できます。これにより、トレースを適切に生成して Stackdriver に設定できます。
例
元のリクエストの traceparent
ヘッダーを使用した HTTP-Get リクエストの例を次に示します。プロキシによって追加されたトレース コンテキストのヘッダーに注意してください。
$ kubectl exec -it sleep-557747455f-n6flv -- curl "httpbin:8000/anything?freeform=" -H "accept: application/json" -H "Traceparent: 00-7543d15e09e5d61801d4f74cde1269b8-604ef051d35c5b3f-01" -vv
* Trying 10.12.3.52:8000...
* Connected to httpbin (10.12.3.52) port 8000 (#0)
> GET /anything?freeform= HTTP/1.1
> Host: httpbin:8000
> User-Agent: curl/7.80.0-DEV
> accept: application/json
> Traceparent: 00-7543d15e09e5d61801d4f74cde1269b8-604ef051d35c5b3f-01
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< server: envoy
< date: Wed, 10 Nov 2021 20:36:04 GMT
< content-type: application/json
< content-length: 1032
< access-control-allow-origin: *
< access-control-allow-credentials: true
< x-envoy-upstream-service-time: 5
<
{
"args": {
"freeform": ""
},
"data": "",
"files": {},
"form": {},
"headers": {
"Accept": "application/json",
"Grpc-Trace-Bin": "AAB1Q9FeCeXWGAHU90zeEmm4AaDHmGRtdM7wAgE",
"Host": "httpbin:8000",
"Traceparent": "00-7543d15e09e5d61801d4f74cde1269b8-a0c798646d74cef0-01",
"User-Agent": "curl/7.80.0-DEV",
"X-B3-Sampled": "1",
"X-B3-Spanid": "a0c798646d74cef0",
"X-B3-Traceid": "7543d15e09e5d61801d4f74cde1269b8",
"X-Cloud-Trace-Context": "7543d15e09e5d61801d4f74cde1269b8/11585396123534413552;o=1",
"X-Envoy-Attempt-Count": "1",
"X-Forwarded-Client-Cert": "<REDACTED>"
},
"json": null,
"method": "GET",
"origin": "127.0.0.6",
"url": "http://httpbin:8000/anything?freeform="
}
返されたリクエスト ヘッダーのセットには、トレース コンテキスト ヘッダーの完全なセットが含まれています。
ヘッダーの伝播例については、トレース コンテキストの伝播をご覧ください。
カスタム ID を使用してクライアントからトレースを作成する
カスタム ID を使用してクライアントからトレースを作成するには、curl
コマンドを使用して外部クライアントを含むリクエストを作成し、強制的にトレースを表示します。次に例を示します。
curl $URL --header "x-client-trace-id: 105445aa7843bc8bf206b12000100000"
x-client-trace-id
の詳細については、Envoy のドキュメントをご覧ください。
Egress ゲートウェイ経由の下り(外向き)
ゲートウェイのインストールとアップグレードの説明に従って、挿入されたゲートウェイをインストールすることをおすすめします。
Istio Container Network Interface
Istio Container Network Interface(CNI)を有効にする方法は、Anthos Service Mesh がインストールされている環境によって異なります。
実際のプラットフォームに合ったオーバーレイ ファイルを選択します。
GKE で CNI を有効にする
オンプレミスで CNI を有効にする
Google Cloud の外部で Google Cloud Observability を有効にする
Istio CA を使用して Google Cloud の外部に Anthos Service Mesh をインストールすると、デフォルトで Prometheus に指標が報告されます。このオプションを使用して、代わりに Google Cloud Observability か、Prometheus と Stackdriver の両方への指標の報告を有効にすると、Anthos Service Mesh ダッシュボードを使用できるようになります。
Stackdriver のみ
Stackdriver と Prometheus
内部ロードバランサを有効にする
GKE で内部ロードバランサを設定するには、ゲートウェイのインストールとアップグレードの説明に従って、挿入されたゲートウェイをインストールすることをおすすめします。ゲートウェイ Service を構成するときに、アノテーション networking.gke.io/load-balancer-type: "Internal"
を含めます。
Ingress ゲートウェイの外部証明書の管理
Envoy の SDS を使用して Ingress ゲートウェイで外部証明書の管理を有効にする方法については、セキュア ゲートウェイをご覧ください。