自動 Envoy インジェクションを使用した Google Kubernetes Engine の Pod の設定オプション
このガイドでは、自動 Envoy サイドカー インジェクタの追加オプションとタスクについて説明します。
既存のワークロードにサイドカー プロキシを追加する
クラスタにサイドカー インジェクタをインストールすると、有効な Namespace で新しく作成された Pod にサイドカー プロキシが自動的に挿入されます。サイドカー インジェクタを有効にする前にワークロードが稼働している場合は、ワークロードを再起動してインジェクションを有効にする必要があります。
Deployment、DaemonSet、または StatefulSet コントローラによって管理される Pod では、次のコマンドを実行できます。
# Deployment kubectl rollout restart deployment/DEPLOYMENT_NAME --namespace NAMESPACE # DaemonSet kubectl rollout restart daemonset/DAEMONSET_NAME --namespace NAMESPACE # StatefulSet kubectl rollout restart statefulset/STATEFULSET_NAME --namespace NAMESPACE
上記のコントローラで Pod をデプロイしていない場合は、Pod を個別に削除する必要があります。これらの Pod は、新しいサイドカー プロキシで自動的に再作成されます。
kubectl delete pod POD_NAME -n NAMESPACE
各 Pod にサイドカー プロキシ コンテナが挿入されていることを確認します。
kubectl get pods -n NAMESPACE
たとえば、上記で作成した busybox クライアントの場合、2 個中 2 つの Pod が実行され、1 つは busybox アプリケーション用、もう 1 つは挿入された Envoy サイドカー プロキシ用に使用されています。
NAME READY STATUS RESTARTS AGE busybox-c54f578c9-c9fk4 2/2 Running 183 7d15h
インジェクションのオーバーライド
デフォルトでは、Namespace を有効にすると、すべての常駐 Pod に対してサイドカー プロキシ インジェクションが有効になります。また、特定のニーズに合わせてインジェクションを別のスコープに構成することもできます。たとえば、プロキシレス gRPC サービスのサイドカー プロキシ インジェクションを防ぐ場合は、オーバーライドが必要になります。
インジェクションのオーバーライドは、Namespace が有効な場合にのみ、Pod Annotations > NeverInjectSelector > AlwaysInjectSelector > Default Policy の順序で適用されます。
特定の Pod に対してインジェクションを有効または無効にする
次の Pod アノテーションを使用して、有効な Namespace 内の特定の Pod でインジェクションを有効または無効にします。
...
metadata:
annotations:
sidecar.istio.io/inject: "true" / "false"
Pod の特定のグループに対してインジェクションを有効または無効にする
サイドカー インジェクタ自体は、Kubernetes ラベルセレクタの配列に従って、有効な Namespace での Pod の挿入を常に許可または禁止するように構成できます。たとえば、次のコマンドを使用すると、Pod に "run=client" というラベルが付いている場合にサイドカー プロキシを挿入しないように、サイドカー インジェクタを構成できます。
kubectl edit configmap -n istio-control istio-sidecar-injector
...
config: |-
policy: enabled
alwaysInjectSelector:
[]
neverInjectSelector:
- matchLabels:
run: client
...
この構成を有効にするには、既存のサイドカー インジェクタ デプロイを再起動する必要があります。
トラフィック インターセプトの動作のカスタマイズ
デフォルトでは、アプリケーションからの送信トラフィックはすべてインターセプトされ、Envoy サイドカー プロキシにリダイレクトされます。これにより、Envoy プロキシは、Cloud Service Mesh から受信した指示に従ってトラフィックを処理できます。しかし、サイドカー プロキシをバイパスするように動作を変更したい場合があるかもしれません。
インターセプトやリダイレクトからトラフィックを除外するには、次の Pod アノテーションを使用します。
送信 IP アドレス範囲でインターセプトから除外する
IP アドレス範囲でインターセプトからトラフィックを除外できます。
...
metadata:
annotations:
cloud.google.com/excludeOutboundCIDRs: "10.0.0.1/32,169.254.169.254/32"
この cloud.google.com/excludeOutboundCIDRs Pod アノテーションは、CIDR 形式で記述した送信 IP アドレス範囲のカンマ区切りのリストです。これらの IP アドレス範囲への宛先である下り（外向き）トラフィックは、Envoy サイドカーにリダイレクトされません。
アプリケーションがメタデータ サーバーと通信できるようにするには、Pod アノテーションで 169.254.169.254/32 を指定する必要があります。cloud.google.com/excludeOutboundCIDRs Pod アノテーションを指定しない場合、トラフィック インターセプトは、送信 CIDR 範囲 "169.254.169.254/32" を除外するように構成されます。
送信 IP アドレス範囲でインターセプトに含める
IP アドレス範囲でインターセプトにトラフィックを含めることができます。
...
metadata:
annotations:
cloud.google.com/includeOutboundCIDRs: "10.0.0.1/32,169.254.169.254/32"
この cloud.google.com/includeOutboundCIDRs Pod アノテーションは、CIDR 形式で記述した送信 IP アドレス範囲のカンマ区切りのリストです。これらの IP アドレス範囲が宛先である下り（外向き）トラフィックは、Envoy サイドカーにリダイレクトされます。
ワイルドカード文字 * を使用すると、すべての送信トラフィックをリダイレクトできます。空のリストを使用すると、すべての送信トラフィックが無効になります。アノテーションのデフォルトは * です。
送信ポート番号によりインターセプトから除外する
送信ポート番号でインターセプトとリダイレクトからトラフィックを除外できます。
...
metadata:
annotations:
cloud.google.com/excludeOutboundPorts: "10001, 10002"
この cloud.google.com/excludeOutboundPorts Pod アノテーションは、送信ポートのカンマ区切りのリストです。これらのポートへの宛先である下り（外向き）トラフィックは、インターセプトと Envoy サイドカーへのリダイレクトから除外されます。
cloud.google.com/excludeOutboundPorts アノテーションを指定しない場合、あらゆる宛先ポートへの送信トラフィックがインターセプトされ、Envoy サイドカーにリダイレクトされます。これは、cloud.google.com/excludeOutboundPorts アノテーションを空の（""）リストで渡すことと同じになります。
受信ポート番号によりインターセプトに含める
受信ポート番号でインターセプトにトラフィックを含めることができます。
...
metadata:
annotations:
cloud.google.com/includeInboundPorts: "10001, 10002"
cloud.google.com/includeInboundPorts Pod アノテーションは、Envoy サイドカーにリダイレクトされる受信ポートのカンマ区切りリストです。ワイルドカード文字 * を使用すると、すべてのポートにリダイレクトを構成できます。空の値を指定すると、すべての受信リダイレクトが無効になります。値はデフォルトで空の文字列（""）になります。
受信ポート番号によりインターセプトから除外する
受信ポート番号でインターセプトからトラフィックを除外できます。
...
metadata:
annotations:
cloud.google.com/excludeInboundPorts: "10001, 10002"
cloud.google.com/excludeInboundPorts Pod アノテーションは、Envoy サイドカーへのリダイレクトから除外する受信ポートのカンマ区切りリストです。アノテーションは、すべての受信トラフィック（*）がリダイレクトされている場合にのみ適用されます。値のデフォルトは空の文字列（""）です。
マネージド証明書を有効にする
マネージド ワークロード証明書を有効にできます。
...
metadata:
annotations:
cloud.google.com/enableManagedCerts: "true"
Pod アノテーション cloud.google.com/enableManagedCerts が true に設定されている場合、Certificate Authority Service によって署名された GKE マネージド ワークロード証明書がサイドカー コンテナに挿入され、マウントされます。アノテーションの値はデフォルトで false になります。
サイドカー プロキシのメタデータの構成
Cloud Service Mesh の追加機能をサポートするために、サイドカー プロキシはカプセル化された Pod から特定のメタデータを継承できます。これを行うには、次の 2 つの方法があります。どちらのオプションでも、サイドカー プロキシが Cloud Service Mesh に接続したときにメタデータが付加され、Cloud Service Mesh と共有されます。これらのオプションは相互排他的です。
最初のオプションでは、個々のメタデータの Key-Value ペアを指定できます。たとえば、挿入されたサイドカー プロキシに "version": "dev" ラベルを適用するには、次のアノテーションを Pod テンプレート仕様に含めます。
...
metadata:
annotations:
cloud.google.com/proxyMetadata: '{"version": "dev"}'
2 番目のオプションでは、Pod のすべてのラベルを、Pod の挿入されたサイドカー プロキシに付加します。
...
metadata:
annotations:
cloud.google.com/forwardPodLabels: "true"
cloud.google.com/forwardPodLabels アノテーションを指定しない場合、Pod ラベルはサイドカー プロキシに追加されません。cloud.google.com/proxyMetadata アノテーションと cloud.google.com/forwardPodLabels アノテーションは相互排他的です。両方を設定した場合は、cloud.google.com/forwardPodLabels が優先され、cloud.google.com/proxyMetadata は無視されます。
次に、構成フィルタリングにより、Cloud Service Mesh は、この "version": "dev" ラベルと一致するプロキシとのみ構成のサブセットを共有します。
この構成を有効にするには、既存のデプロイを再起動する必要があります。
サポートされている Pod アノテーション
Cloud Service Mesh は、サイドカー インジェクション用に次の Pod アノテーションをサポートしています。サイドカー インジェクタの別のアノテーションも機能する可能性はありますが、Cloud Service Mesh がサポートするアノテーションは次のとおりです。破損や不安定を防ぐため、本番環境デプロイでは他のアノテーションに依存関係を作成しないでください。
| アノテーション名 | 値 | 説明 |
|---|---|---|
| sidecar.istio.io/inject | 文字列で表現されるブール値。例: "true" |
Envoy サイドカーをワークロードに自動的に挿入するかどうかを指定します。 |
| cloud.google.com/proxyMetadata | Key-Value ペアの JSON マップ。例: "'{"version":
"dev"}'" |
Envoy メタデータに付加する必要がある JSON マップ内の Key-Value ペアを指定します。 |
| cloud.google.com/forwardPodLabels | "true" または "false" | "true" に設定すると、すべての Pod ラベルが Envoy メタデータに付加され、"cloud.google.com/proxyMetadata" アノテーションは無視されます。デフォルトは "false" です。 |
| cloud.google.com/excludeOutboundPorts | 送信ポートのカンマ区切りのリスト | これらの宛先ポートのいずれかを示す下り（外向き）トラフィックは、インターセプトと Envoy サイドカーへのリダイレクトから除外されます。このトラフィックは Envoy プロキシをバイパスします。また、Cloud Service Mesh の構成に従って処理されることはありません。デフォルトは空の文字列（""）です。 |
| cloud.google.com/includeInboundPorts | 受信ポートのカンマ区切りのリスト | トラフィックが Envoy サイドカーにリダイレクトされる受信ポートのカンマ区切りリスト。すべてのポートのリダイレクトを構成するには、ワイルドカード文字「*」を使用します。空の値を指定すると、すべての受信リダイレクトが無効になります。値はデフォルトで空の文字列（""）になります。 |
| cloud.google.com/excludeInboundPorts | 受信ポートのカンマ区切りのリスト | トラフィックが Envoy サイドカーにリダイレクトされない受信ポートのカンマ区切りリスト。アノテーションは、すべての受信トラフィック（*）がリダイレクトされる場合にのみ適用されます。値はデフォルトで空の文字列（""）になります。 |
| cloud.google.com/excludeOutboundCIDRs | CIDR 形式の送信 IP 範囲のカンマ区切りのリスト。 | これらの宛先 IP のいずれかを示す下り（外向き）トラフィックは、インターセプトと Envoy サイドカーへのリダイレクトから除外されます。このトラフィックは Envoy プロキシをバイパスします。また、Cloud Service Mesh の構成に従って処理されることはありません。デフォルトは "169.254.169.254/32" で、これはメタデータ サーバーとの通信に必要な範囲です。この範囲は必須であるため、excludeOutboundCIDRs アノテーションを指定する場合は、他の CIDR に加えて "169.254.169.254/32" も含めるようにしてください。カンマ区切りのリストにスペースを含めないでください。 |
| cloud.google.com/includeOutboundCIDRs | CIDR 形式の送信 IP 範囲のカンマ区切りのリスト。 | これらの宛先 IP のいずれかを示す下り（外向き）トラフィックは、Envoy サイドカーへのインターセプト / リダイレクトに含まれます。このトラフィックは Envoy プロキシに送信され、Cloud Service Mesh の構成に従って処理されます。デフォルトは "169.254.169.254/32" で、これはメタデータ サーバーとの通信に必要な範囲です。この範囲は必須であるため、includeOutboundCIDRs アノテーションを指定する場合は、他の CIDR に加えて "169.254.169.254/32" も含めるようにしてください。カンマ区切りのリストにスペースを含めないでください。 |
| cloud.google.com/enableManagedCerts | 文字列で表現されるブール値。例: "true" |
「true」に設定すると、Certificate Authority Service によって署名された GKE マネージド ワークロード証明書がサイドカー コンテナに挿入され、マウントされます。デフォルト値は「false」です。 |
サイドカー インジェクタのアンインストール
サイドカー インジェクタをアンインストールするには、次のコマンドを使用します。
kubectl delete -f specs/ kubectl label namespace default istio-injection-