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

このページでは、クラスタ内コントロール プレーンでオプション機能を有効にする方法について説明します。マネージド コントロール プレーンの詳細については、マネージド 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 ごとに別々のオーバーレイ ファイルを作成します
1 つの yaml に複数の CR CR ごとに別々の yaml ファイル

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

次の例は、オプション機能を有効にすることを目的とした、カスタム オーバーレイの使用についてのみ示すため簡略化されています。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 を実行することはできません。また、コンテナ内で curlping などのデバッグ ユーティリティを使用することもできません。シェルを実行しようとすると、次のエラーが表示されます。

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.13.9-asm.10
  • マネージド データプレーン - gcr.io/gke-release/asm/mdp:1.13.9-asm.10
  • パイロット - gcr.io/gke-release/asm/pilot:1.13.9-asm.10
  • Proxyv2 - gcr.io/gke-release/asm/proxyv2:1.13.9-asm.10

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

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

  1. Anthos Service Mesh イメージを pull します。
    docker pull gcr.io/gke-release/asm/install-cni:1.13.9-asm.10
    docker pull gcr.io/gke-release/asm/mdp:1.13.9-asm.10
    docker pull gcr.io/gke-release/asm/pilot:1.13.9-asm.10
    docker pull gcr.io/gke-release/asm/proxyv2:1.13.9-asm.10
    docker pull gcr.io/gke-release/asm/vaultclient:1.13.9-asm.10
    
  2. 非公開レジストリの URL の変数を作成します。
    export PRIVATE_REGISTRY_URL=PRIVATE_REGISTRY_URL
    
    PRIVATE_REGISTRY_URL は非公開レジストリの URL に置き換えます。
  3. イメージに非公開レジストリの URL をタグ付けします。
    docker tag gcr.io/gke-release/asm/install-cni:1.13.9-asm.10 \
     ${PRIVATE_REGISTRY_URL}/gcr.io/gke-release/asm/install-cni:1.13.9-asm.10
    docker tag gcr.io/gke-release/asm/mdp:1.13.9-asm.10 \
     ${PRIVATE_REGISTRY_URL}/gcr.io/gke-release/asm/mdp:1.13.9-asm.10
    docker tag gcr.io/gke-release/asm/pilot:1.13.9-asm.10 \
     ${PRIVATE_REGISTRY_URL}/gcr.io/gke-release/asm/pilot:1.13.9-asm.10
    docker tag gcr.io/gke-release/asm/proxyv2:1.13.9-asm.10 \
     ${PRIVATE_REGISTRY_URL}/gcr.io/gke-release/asm/proxyv2:1.13.9-asm.10
    docker tag gcr.io/gke-release/asm/vaultclient:1.13.9-asm.10 \
     ${PRIVATE_REGISTRY_URL}/gcr.io/gke-release/asm/vaultclient:1.13.9-asm.10
    
  4. タグ付きのイメージを限定公開レジストリに push します。
    docker push ${PRIVATE_REGISTRY_URL}/gcr.io/gke-release/asm/install-cni:1.13.9-asm.10
    docker push ${PRIVATE_REGISTRY_URL}/gcr.io/gke-release/asm/mdp:1.13.9-asm.10
    docker push ${PRIVATE_REGISTRY_URL}/gcr.io/gke-release/asm/pilot:1.13.9-asm.10
    docker push ${PRIVATE_REGISTRY_URL}/gcr.io/gke-release/asm/proxyv2:1.13.9-asm.10
    docker push ${PRIVATE_REGISTRY_URL}/gcr.io/gke-release/asm/vaultclient:1.13.9-asm.10
    
  5. (省略可)正規サービスを使用する場合は、正規サービス イメージを限定公開レジストリに追加します。
    1. 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
              
    2. イメージに限定公開レジストリの 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
              
    3. タグ付きのイメージを限定公開レジストリに 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
              

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

Envoy を stdout に出力する

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

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

Cloud Trace

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

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

料金の詳細については、Cloud Trace の料金ページをご覧ください。

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

デフォルトのサンプリング レートは 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-traceidx-b3-spanidx-b3parentspanidx-b3-sampledx-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 がインストールされている環境によって異なります。

  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 の外部で Google Cloud Observability を有効にする

Istio CA を使用して Google Cloud の外部に Anthos Service Mesh をインストールすると、デフォルトで Prometheus に指標が報告されます。このオプションを使用して、代わりに Google Cloud Observability か、Prometheus と Stackdriver の両方への指標の報告を有効にすると、Anthos 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 ゲートウェイで外部証明書の管理を有効にする方法については、セキュア ゲートウェイをご覧ください。