Contents
対象範囲と導入の意義
Kubernetes環境において、Envoy Proxyをサイドカーとして導入する際には、Istio Control Plane（istiod）との連携が不可欠です。マイクロサービスアーキテクチャでは、動的な設定管理やサービスディスカバリー機能が求められるため、xDS API経由でコンフィギュレーションを自動配信する仕組みの構築が重要です。本記事では、最新版Istio（v1.20以降）と併用したEnvoy Proxyの導入・設定手順を、実務的な視点から丁寧に解説します。
Envoy Proxyの初期インストールとサイドカー設定
Kubernetesクラスターへの初期導入では、HelmチャートやDaemonSetを利用して全ノードへ注入する方法が一般的です。以下に具体的な手順を示します。
インストール手法比較
| 手法 | 特徴 | 使用ケース |
|---|---|---|
| Helmチャート | パッケージ化された設定管理が可能 | 初期導入・バージョン管理が難しい場合 |
| DaemonSet | 自動注入の柔軟性が高い | 特定ポッドに限定して注入が必要な場合 |
Helmチャートによるデプロイ手順
公式リポジトリのHelm Chartを使用するのが推奨されます。以下のコマンドで初期設定を行います。
-
Helmリポジトリの追加
bash
helm repo add envoyproxy https://envoyproxy.github.io/helm-charts -
チャートのインストール
bash
helm install envoy envoyproxy/envoy-proxy \
--set global.image.tag=latest \
--set global.sidecarInjectorWebhook.enabled=true
注意点：
sidecarInjectorWebhookは、Istioとの連携を目的とした設定です。無効にすると自動注入が機能しません。
DaemonSetで全ノードへの注入
サイドカーとしてEnvoy Proxyを注入するには、DaemonSetの構成が必須です。以下のYAMLテンプレートは、各PodにEnvoyコンテナを自動追加する例です。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 |
apiVersion: apps/v1 kind: DaemonSet metadata: name: envoy-sidecar spec: selector: matchLabels: app: envoy template: metadata: labels: app: envoy spec: containers: - name: envoy image: envoyproxy/envoy:latest ports: - containerPort: 15001 name: http volumeMounts: - name: config mountPath: /etc/envoy/config.yaml subPath: config.yaml volumes: - name: config configMap: name: envoy-config |
ポイント：
volumeMountsとconfigMapで、Envoyの設定ファイルをマウントしている点に注目してください。
xDS APIによる動的コンフィギュレーション管理
Istio Control Plane（istiod）は、Envoy Proxyに対してLDS（Listener Discovery Service）、CDS（Cluster Discovery Service）、RDS（Route Discovery Service）などのxDSデータを自動配信します。以下の手順で設定反映が確認できます。
xDS APIの基本仕組み
xDS APIは、Istio Control Plane（istiod）からEnvoy Proxyに動的な設定情報を配信するためのAPIです。これにより、リスナー・クラスタ・ルートなどの設定をリアルタイムで更新できます。
Control Planeからのリスナーコンフィグ受信
Envoy Proxyは、istiodから受け取ったLDS情報をもとに、自身のリスナー設定を動的に更新します。以下に手順を示します。
-
Envoyのコンフィギュレーション確認
bash
kubectl logs <pod-name> -c envoy -
xDS APIの動作確認
bash
istioctl proxy-status <pod-name>
補足：
kubectl execによるEnvoyコマンド実行は不正確です。代わりに、ログ出力やistioctlツールで状態を確認してください。
実行中のEnvoyに設定反映の手順
環境変数やConfigMapを更新した後、Envoy Proxyに設定反映を促すには以下を行います。
-
ConfigMapの更新
bash
kubectl set env configmap/envoy-config \
ENVOY_CONFIG=/etc/config.yaml -
Podの再起動（リカバリ処理）
bash
kubectl delete pod -l app=myapp
注意事項：
kubectl delete podでPodを削除すると、Kubernetesは自動でリカバリして新たなPodを立ち上げます。
サイドカー注入用YAMLテンプレート作成例
Envoy Proxyの注入をデプロイメントに直接組み込むには、initContainersとnetworkPolicyの定義が重要です。
イニシャライザーコンテナの定義
以下は、初期化コンテナとしてEnvoyの設定ファイルを生成する例です。
|
1 2 3 4 5 6 7 8 9 |
spec: initContainers: - name: envoy-init image: envoyproxy/envoy:latest command: ["sh", "-c", "cp /etc/config.yaml /var/www/html/"] volumeMounts: - name: config mountPath: /etc/config.yaml |
注意事項：
initContainersは、Podが起動する前に行う処理です。設定ファイルの初期生成に適しています。
Envoyとアプリケーションのネットワークポリシー
Envoy Proxyとの通信経路を制御するには、NetworkPolicyを使用します。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: envoy-policy spec: podSelector: matchLabels: app: myapp policyTypes: - Ingress - Egress ingress: - from: - namespaceSelector: matchLabels: istio-injection: enabled |
ポイント：
istio-injection: enabledラベルのノード間で通信を許可しています。
サービスディスカバリの自動同期メカニズム
Envoy Proxyは、Istio経由でサービスレジストリ情報をリアルタイムに取得します。以下に動作確認方法とテスト手順を示します。
EDS（Endpoint Discovery Service）の動作確認
Istio Control Plane（istiod）が管理するサービス一覧を確認するには、kubectl get services -n istio-systemコマンドを使用します。
|
1 2 |
kubectl get services -n istio-system | grep envoy |
出力例
|
1 2 3 |
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE istio-pilot ClusterIP 10.96.3.2 <none> 15011/TCP 5m |
サービス変更時の即時反映テスト
サービスの更新を確認するには、kubectl edit serviceでPod IPやポート情報を変更し、Envoy Proxy側に設定が反映されるかを確認します。
|
1 2 |
kubectl edit service my-service -n default |
確認方法：
istioctl proxy-status <pod-name>コマンドで再構成後の動作を監視してください。
Control Plane（istiod）との通信設定
Envoy Proxyとistiodの間でのmTLS通信は、セキュリティ確保のため必須です。以下の手順で通信設定を行うとよいでしょう。
mTLS通信の検証方法
kubectl get secret -n istio-systemコマンドで、istiodが発行する証明書を確認します。
|
1 2 |
kubectl get secrets -n istio-system | grep envoy |
出力例
|
1 2 3 |
NAME TYPE DATA AGE istio-ca-secret Opaque 3 5m |
ステートフルセッション管理の設定
Envoy Proxyは、ステートフルな通信を維持するため、xDS API経由でセッション情報をIstio Control Planeに送信します。以下の設定が必要です。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
envoy: configMap: data: envoy.yaml: | static_resources: listeners: - name: listener_0 address: socket_address: address: 0.0.0.0 port_value: 15001 filter_chains: - filters: - name: envoy.filters.network.http_connection_manager |
補足：
filtersセクションで、HTTP通信のフィルタリングを定義しています。
まとめ
本記事では、Envoy ProxyをKubernetesサイドカーとして導入し、Istio Control Planeと連携させる手順を解説しました。以下のポイントが重要です：
- 初期インストール：HelmチャートやDaemonSetで全ノードへ注入する
- xDS API経由の動的設定更新：istiodからのリスナー設定を自動受信し、再起動せずに反映させる
- YAMLテンプレート作成：initContainerとNetworkPolicyの定義により、アプリケーションとの通信を適切に管理する
- サービスディスカバリの同期：EDS経由でサービスレジストリ情報をリアルタイム取得し、即時反映テストを行う
- mTLS通信設定：istiodとの信頼関係構築とセキュリティ確保が不可欠である
最新版Istioと併用したEnvoy Proxy導入を試してみましょう。公式リポジトリのサンプルコードを活用することで、より実践的な運用が可能になります。