Contents
スポンサードリンク
1. xDS API の全体像
xDS は Envoy が外部の Control Plane とやり取りするための 統一 Discovery Interface です。
リソースは独立した Service（LDS、RDS、CDS、EDS、SDS）を通じて配信され、必要なものだけを差分で更新できる点が大規模運用の鍵となります。
1.1 Listener Discovery Service (LDS)
LDS は Envoy が 受信ポートとフィルタチェーン を動的に取得するための API です。
Control Plane がListenerオブジェクトをプッシュすると、Envoy のリスナー構成が即座に反映されます。
- 主な属性:
address,filter_chains,listener_filters - 利用シーン: ポート追加・TLS 終端のオンデマンド切り替え
1.2 Route Discovery Service (RDS)
RDS は HTTP/HTTPS のルーティング規則（
RouteConfiguration）を管理します。
LDS が取得した Listener にrds設定を埋め込むことで、ルート情報は別途配信されます。
- 主な属性:
virtual_hosts,routes,request_headers_to_add - 利用シーン: ホスト名・パスベースのトラフィック分岐
1.3 Cluster Discovery Service (CDS)
CDS は 上流サービス（Cluster） のロードバランシングや接続ポリシーを提供します。
Envoy が外部へリクエストするときは必ず Cluster に紐付くため、スケールやリトライ設定はここで完結します。
- 主な属性:
type,lb_policy,load_balancing_policy - 利用シーン: ラウンドロビン／ヘルスチェック付きのバックエンドプール
1.4 Endpoint Discovery Service (EDS)
EDS は 実際の IP:Port（Endpoint） 情報を配信し、Cluster と組み合わせて動的サービスディスカバリを実現します。
Kubernetes の Service/Pod と連携させると、ポッド増減が即座に反映されます。
- 主な属性:
lb_endpoints,health_status,metadata - 利用シーン: Pod IP の自動取得・ヘルスチェック結果のリアルタイム更新
1.5 Secret Discovery Service (SDS)
SDS は TLS 証明書・鍵 といった機密情報を安全に配布する API です。
mTLS 構成時は証明書ローテーションを SDS 経由で行うことで、Envoy の再起動なしにセキュリティが保たれます。
- 主な属性:
tls_certificate,validation_context - 利用シーン: 証明書自動更新・複数ドメインの SNI 対応
ポイント：xDS は「設定単位ごとの独立 API」を提供し、必要リソースだけを差分配信できるため、大規模クラスターでも高速かつ安全に構成変更が可能です。
2. Envoy 1.30 系のインストールと Bootstrap 設定
このセクションでは 再現性のあるパッケージインストール と、正しい Bootstrap の書き方 を解説します。
特に「gRPC と REST を同一リソースで混在できない」点や、HTTP/3・TLS がデフォルトで有効かどうかといった誤認を防ぎます。
2.1 バージョン固定でのパッケージインストール
再現性が求められる本番環境では、リポジトリから特定バージョンを明示的に取得することが必須です。
以下は Ubuntu と Alpine のそれぞれで Envoy 1.30.0 を固定インストールする例です。
Ubuntu (apt)
|
1 2 3 4 5 6 7 8 9 10 |
# Envoy リポジトリのセットアップ（2026‑01‑15 時点の公開鍵・リポジトリ URL） curl -sL https://getenvoy.io/gpg | sudo apt-key add - sudo add-apt-repository "deb [arch=amd64] https://dl.bintray.com/tetrate/getenvoy-deb $(lsb_release -cs) stable" # パッケージ情報更新 sudo apt-get update # 1.30.x 系の最新安定版（例: 1.30.0-1）をインストール sudo apt-get install -y envoy=1.30.0-1 |
Alpine (apk)
|
1 2 3 4 5 6 7 8 9 |
# Envoy リポジトリ追加 echo "https://dl.bintray.com/tetrate/getenvoy-alpine/v3.15/main" | sudo tee /etc/apk/repositories # パッケージ情報更新 sudo apk update # 1.30.0-1 をインストール sudo apk add envoy=1.30.0-r0 |
注意：リポジトリ URL やパッケージ名は時期により変わる可能性があります。必ず公式ドキュメントで最新情報を確認してください。
2.2 Docker イメージの利用（バージョンタグ指定）
Docker 環境では タグでバージョン固定 が最も簡単です。
|
1 2 |
docker pull envoyproxy/envoy:v1.30.0 |
v1.30.0はビルド時に HTTP/3 と TLS のサポートはオプション であり、公式イメージではデフォルトで無効です。必要なら環境変数やコンフィグで明示的に有効化します（後述）。
2.3 正しい Bootstrap ファイルの書き方
Bootstrap は Envoy 起動時に最初に読み込む JSON/YAML 設定です。
同一リソースタイプ（例: LDS）については gRPC と REST を同時指定できません が、異なるリソースでフォールバック戦略を取ることは可能 です。
2.3.1 基本構造と TLS 設定例
|
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 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 |
# bootstrap.yaml（80〜120 行程度に収まる簡潔版） node: id: envoy-node-01 cluster: envoy-cluster static_resources: clusters: # xDS 用の gRPC クラスタ（TLS 必須推奨） - name: xds_cluster_grpc type: STRICT_DNS connect_timeout: 5s http2_protocol_options: {} # gRPC に必要 transport_socket: name: envoy.transport_sockets.tls typed_config: "@type": type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.UpstreamTlsContext common_tls_context: tls_certificates: - certificate_chain: filename: "/etc/certs/tls.crt" private_key: filename: "/etc/certs/tls.key" validation_context: trusted_ca: filename: "/etc/certs/ca.crt" load_assignment: cluster_name: xds_cluster_grpc endpoints: - lb_endpoints: - endpoint: address: socket_address: address: control-plane.default.svc.cluster.local port_value: 18000 dynamic_resources: # LDS は gRPC のみ使用（REST フォールバックは別クラスタで実装） lds_config: api_config_source: api_type: GRPC transport_api_version: V3 grpc_services: - envoy_grpc: cluster_name: xds_cluster_grpc # admin API の設定（ヘルスチェック・デバッグ用） admin: access_log_path: /tmp/admin_access.log address: socket_address: address: 0.0.0.0 port_value: 9901 |
- TLS 設定は
transport_socketに記述し、証明書は Kubernetes Secret からマウントします。 - HTTP/3 の有効化はビルドオプションが必要なので、公式イメージでは環境変数
ENVOY_ENABLE_HTTP3=1を設定するか、カスタムビルドを用意してください（別章で解説）。
2.3.2 REST フォールバック例（CDS のみ）
|
1 2 3 4 5 6 7 8 9 10 |
dynamic_resources: cds_config: api_config_source: api_type: REST # ← REST を使用 transport_api_version: V3 request_timeout: 10s rest_apis: - cluster_name: xds_cluster_rest # 別途定義した HTTP クラスタ path_prefix: "/v3/discovery/clusters" |
ポイント：
lds_configとcds_configがそれぞれ異なるapi_typeを持つことは問題ありませんが、同一リソースでGRPCとRESTを混在させると起動エラーになります。
2.4 HTTP/3 の有効化（任意）
Envoy 1.30 系では HTTP/3 はデフォルト無効 です。以下のいずれかを選択してください。
| 方法 | 手順概要 |
|---|---|
| 環境変数 | コンテナ起動時に ENVOY_ENABLE_HTTP3=1 を設定し、--define=envoy.build_http3=true が有効なイメージを使用 |
| カスタムビルド | ソースから bazel build //source:envoy --copt=-DENABLE_HTTP3 でビルドし、独自イメージを作成 |
| フィルタ設定 | http_connection_manager の http3_protocol_options を明示的に記述 |
3. Kubernetes DaemonSet によるノード単位デプロイ
この章では 安全性・可観測性・ローリングアップデート を備えた DaemonSet マニフェストを提示し、各設定項目の意図を解説します。
3.1 DaemonSet マニフェスト全体像（約150 行）
以下は Envoy v1.30.0 用に最適化した DaemonSet 定義です。
hostNetworkとsecurityContextによる権限最小化、TLS シークレットのマウント、admin API へのヘルスチェックを組み込んでいます。
|
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 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 |
apiVersion: apps/v1 kind: DaemonSet metadata: name: envoy-proxy namespace: networking labels: app.kubernetes.io/name: envoy spec: selector: matchLabels: app: envoy updateStrategy: type: RollingUpdate rollingUpdate: maxUnavailable: 1 # 同時に落ちるノードは最大1台 template: metadata: labels: app: envoy spec: hostNetwork: true # ノードのネットワークスタック直接利用 dnsPolicy: ClusterFirstWithHostNet serviceAccountName: envoy-sa securityContext: runAsUser: 10101 # 非特権ユーザー runAsGroup: 10101 readOnlyRootFilesystem: true seccompProfile: type: RuntimeDefault containers: - name: envoy image: envoyproxy/envoy:v1.30.0 args: ["-c", "/etc/envoy/bootstrap.yaml"] env: - name: ENVOY_ENABLE_HTTP3 # 必要なら HTTP/3 を有効化 value: "1" volumeMounts: - name: bootstrap mountPath: /etc/envoy - name: certs mountPath: /etc/certs ports: - containerPort: 10000 # データプレーン (Envoy のリスナー例) - containerPort: 9901 # admin API（ヘルスチェック用） readinessProbe: httpGet: path: /ready port: 9901 initialDelaySeconds: 5 periodSeconds: 10 failureThreshold: 3 livenessProbe: httpGet: path: /healthz port: 9901 initialDelaySeconds: 15 periodSeconds: 20 failureThreshold: 5 volumes: - name: bootstrap configMap: name: envoy-bootstrap # 前章の bootstrap.yaml を格納した ConfigMap - name: certs secret: secretName: envoy-tls # TLS 用 Secret（ca.crt / tls.crt / tls.key） |
3.1.1 各項目のポイント解説
- hostNetwork – ノードの IP を直接バインドすることで、Sidecar と同等の低レイテンシを実現。
- securityContext –
runAsUser/runAsGroupによる権限分離とseccompProfile: RuntimeDefaultで不要な syscall をブロック。 - readiness / liveness – Envoy の admin API (
/ready,/healthz) を利用した K8s 標準のヘルスチェック。 - TLS シークレット –
certsボリュームはSecretからマウントし、Bootstrap が自動的に参照できるように配置。
3.2 RollingUpdate と無停止アップグレード
DaemonSet の
maxUnavailable: 1により、同時に落ちているノードは最大で 1 台 です。
Envoy が/readyを true にするまで次の Pod は起動せず、段階的なロールアウトが保証されます。
4. カスタム Control Plane の実装例
以下では Go と Python で最小構成の xDS サーバーを作ります。
コードはそのまま go run / python -m uvicorn 等でコンパイル・実行でき、TLS／エラーハンドリングも含めています。
4.1 Go 言語での最小 xDS Server（完全ビルド可能版）
このサンプルは go-control-plane v0.11+ と
google.golang.org/protobuf系を利用します。
必要な依存パッケージはgo.modに明示し、anypb.Newを使って正しいany.Any型の Listener を埋め込んでいます。
4.1.1 go.mod
|
1 2 3 4 5 6 7 8 9 10 |
module example.com/envoy-xds go 1.22 require ( github.com/envoyproxy/go-control-plane v0.11.2 google.golang.org/grpc v1.62.0 google.golang.org/protobuf v1.33.0 ) |
4.1.2 main.go
|
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 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 |
package main import ( "context" "log" "net" discovery "github.com/envoyproxy/go-control-plane/pkg/server/v3" cache "github.com/envoyproxy/go-control-plane/pkg/cache/v3" envoycore "github.com/envoyproxy/go-control-plane/envoy/config/core/v3" listenerpb "github.com/envoyproxy/go-control-plane/envoy/config/listener/v3" anypb "google.golang.org/protobuf/types/known/anypb" "google.golang.org/grpc" "google.golang.org/grpc/credentials" ) // buildListener は単純な HTTP リスナーを生成し、any.Any にラップして返す func buildListener(name string, port uint32) (*anypb.Any, error) { l := &listenerpb.Listener{ Name: name, Address: &envoycore.Address{ Address: &envoycore.Address_SocketAddress{ SocketAddress: &envoycore.SocketAddress{ Protocol: envoycore.SocketAddress_TCP, Address: "0.0.0.0", PortSpecifier: &envoycore.SocketAddress_PortValue{ PortValue: port, }, }, }, }, } return anypb.New(l) } func main() { // ---------- 1️⃣ SnapshotCache の初期化 ---------- snapCache := cache.NewSnapshotCache(true, cache.IDHash{}, nil) // ---------- 2️⃣ Listener リソース作成 ---------- listenerAny, err := buildListener("listener_0", 10000) if err != nil { log.Fatalf("failed to marshal listener: %v", err) } snapshot := cache.NewSnapshot( "1", map[cache.Type]cache.Resources{ cache.ListenerType: {Version: "1", Items: map[string]*anypb.Any{ "listener_0": listenerAny, }}, }, ) if err = snapCache.SetSnapshot(context.Background(), "node-01", snapshot); err != nil { log.Fatalf("snapshot set error: %v", err) } // ---------- 3️⃣ gRPC サーバー（TLS / mTLS） ---------- creds, err := credentials.NewServerTLSFromFile( "/etc/certs/tls.crt", "/etc/certs/tls.key", ) if err != nil { log.Fatalf("failed to load TLS certs: %v", err) } grpcSrv := grpc.NewServer(grpc.Creds(creds)) srv := discovery.NewServer(context.Background(), snapCache, nil) discovery.RegisterAggregatedDiscoveryServiceServer(grpcSrv, srv) lis, err := net.Listen("tcp", ":18000") if err != nil { log.Fatalf("listen error: %v", err) } log.Println("xDS gRPC server listening on :18000 (TLS enabled)") if err = grpcSrv.Serve(lis); err != nil { log.Fatalf("gRPC serve error: %v", err) } } |
ポイント解説
| 項目 | 内容 |
|---|---|
| SnapshotCache | バージョン管理と差分配信の核。true は ADS (Aggregated Discovery Service) を使用する設定。 |
| Listener の any.Any | anypb.New で正しい型情報を保持しないと Envoy がデコードできません。 |
| TLS / mTLS | credentials.NewServerTLSFromFile に証明書と鍵を渡すだけでサーバー側 TLS が有効になる。クライアント認証は NewTLS のオプションで追加可能です。 |
| エラーハンドリング | すべてのステップで log.Fatalf を使用し、起動失敗時に即座に可視化します。 |
このサンプルをコンテナ化する場合は、
/etc/certs/*を Kubernetes Secret としてマウントしてください。
4.2 Python (grpcio) による安全な xDS Server
Python 実装でも TLS / mTLS と例外処理を組み込み、実運用に耐えうる形にします。
protobufの生成ファイルは公式リポジトリから取得し、any_pb2.Anyに Listener をシリアライズして返す点が重要です。
4.2.1 必要パッケージ
|
1 2 |
pip install grpcio protobuf envoy-control-plane==0.9.0 |
envoy-control-planeは公式の proto 定義を提供します（バージョンは Envoy 1.30 に合わせてください）。
4.2.2 server.py
|
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 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 |
import logging from concurrent import futures import grpc from google.protobuf import any_pb2, json_format # protobuf のロード from envoy.service.discovery.v3 import discovery_pb2_grpc, discovery_pb2 from envoy.config.listener.v3 import listener_pb2 from envoy.config.core.v3 import address_pb2 logging.basicConfig(level=logging.INFO) TLS_CERT = "/etc/certs/tls.crt" TLS_KEY = "/etc/certs/tls.key" def build_listener(name: str, port: int) -> any_pb2.Any: """Listener を作成し、any.Any にシリアライズして返す""" sock_addr = address_pb2.Address( socket_address=address_pb2.SocketAddress( protocol=address_pb2.SocketAddress.TCP, address="0.0.0.0", port_value=port, ) ) lst = listener_pb2.Listener(name=name, address=sock_addr) any_msg = any_pb2.Any() any_msg.Pack(lst) # 正しい type_url が自動設定される return any_msg class XdsServicer(discovery_pb2_grpc.AggregatedDiscoveryServiceServicer): """ADS の最小実装。エラーハンドリングと mTLS 対応を含む""" def __init__(self): # ここでは単純に 1 つの Listener を保持 self.listener_any = build_listener("listener_0", 10000) self.version = "1" def StreamAggregatedResources(self, request_iterator, context): for req in request_iterator: logging.info(f"Received request: type_url={req.type_url}, node_id={req.node.id}") try: resp = discovery_pb2.DiscoveryResponse( version_info=self.version, resources=[self.listener_any], type_url=req.type_url, nonce="1", ) yield resp except Exception as e: logging.error(f"Failed to build response: {e}") context.set_details(str(e)) context.set_code(grpc.StatusCode.INTERNAL) return def serve(): # TLS / mTLS 用の server credentials を作成 server_creds = grpc.ssl_server_credentials( [(open(TLS_KEY, "rb").read(), open(TLS_CERT, "rb").read())], root_certificates=None, # クライアント認証が不要な場合は None require_client_auth=False, ) server = grpc.server(futures.ThreadPoolExecutor(max_workers=10)) discovery_pb2_grpc.add_AggregatedDiscoveryServiceServicer_to_server( XdsServicer(), server ) server.add_secure_port("[::]:18000", server_creds) logging.info("Python xDS server listening on 0.0.0.0:18000 (TLS enabled)") server.start() try: server.wait_for_termination() except KeyboardInterrupt: logging.info("Shutting down server...") if __name__ == "__main__": serve() |
ポイント解説
| 項目 | 内容 |
|---|---|
any_pb2.Any().Pack |
型情報 (type_url) が自動付与され、Envoy が正しくデシリアライズできる。 |
| TLS 設定 | grpc.ssl_server_credentials に証明書・鍵を渡すだけでサーバー側 TLS が有効になる。クライアント認証が必要な場合は root_certificates と require_client_auth=True を設定。 |
| エラーハンドリング | 例外捕捉後に context.set_code/grpc.StatusCode.INTERNAL を返し、gRPC クライアント側でエラーを検知できるようにする。 |
本サンプルは Dockerfile に組み込んでコンテナ化すれば、K8s の
Secretから証明書をマウントして運用できます。
4.3 公式 envoycontrolplane リポジトリとの比較
| 項目 | 最小実装 (Go) | 最小実装 (Python) | envoycontrolplane（公式） |
|---|---|---|---|
| 言語 | Go | Python | Go |
| 完全 xDS タイプ対応 | 手動で追加可能 | 手動で追加可能 | LDS/RDS/CDS/EDS/SDS 全網羅 |
| TLS / mTLS 実装例 | 標準 grpc.Creds で完結 |
ssl_server_credentials で実装 |
同様にサポート（高度なローテーション機構あり） |
| テストフレームワーク | go test |
pytest |
ginkgo + go test |
| プラグイン拡張性 | 高（Go のインタフェース） | 中（grpc interceptors） | 非常に高（サンプルが豊富） |
| デバッグ支援 | ロガーのみ | 標準ロギング | admin API、statsd、OpenTelemetry 連携 |
結論：プロトタイプや PoC であれば上記最小実装で十分です。大規模本番環境では公式リポジトリをベースに拡張することを推奨します。
5. 動的設定・セキュリティ・運用ベストプラクティス
5.1 TLS / mTLS による xDS 通信の完全手順
- 証明書と鍵を Kubernetes Secret として作成
bash
kubectl create secret tls envoy-xds-tls \
--cert=ca.crt --key=ca.key -n networking - Bootstrap の
transport_socketにシークレットパスを参照させる（先述の例と同一） - Control Plane 側で mTLS を有効化（Go と Python それぞれコード例あり）
ベストプラクティス：証明書は自動ローテーションツール（cert-manager 等）で管理し、Secret の更新だけで Envoy が即座に新証明書へ切り替わります。
5.2 ConfigMap → xDS Server → Envoy のリアルタイム更新フロー
| フェーズ | 説明 |
|---|---|
| 1️⃣ ConfigMap 更新 | 管理者が kubectl apply -f listener-config.yaml 等でリソース定義を変更 |
| 2️⃣ Control Plane が Informer で検知 | client-go の SharedInformer が ConfigMap 変化を捕捉し、内部データ構造に反映 |
| 3️⃣ SnapshotCache に新スナップショット設定 | バージョン番号 ("2" など) をインクリメントし、SetSnapshot(nodeID, snapshot) 呼び出し |
| 4️⃣ Envoy が DeltaDiscoveryResponse を受信 | gRPC ストリーム上で差分だけが配信され、数秒以内に設定が反映 |
この流れは 「再起動不要・即時反映」 という xDS の根幹的利点です。
5.3 トラブルシューティングと可観測性
| 手段 | 実施方法 | 主な活用シーン |
|---|---|---|
| admin API | curl http://localhost:9901/servers、/stats?format=json |
現在のリスナー一覧・統計情報取得 |
| 動的ログレベル変更 | POST /logging?level=debug（admin） |
問題発生時に瞬時に詳細ログ取得 |
| pprof プロファイリング | 起動フラグ --enable-pprof + /debug/pprof/* エンドポイント |
CPU・メモリボトルネックの特定 |
| gRPC ステータス確認 | grpcurl -insecure localhost:18000 envoy.service.discovery.v3.AggregatedDiscoveryService.StreamAggregatedResources |
Control Plane との通信エラーコード取得 |
admin API はデフォルトでポート 9901 に公開されますが、外部からの直接アクセスは NetworkPolicy で制限し、内部 Pod のみから利用するようにしてください。
5.4 リソース分離・ロールバック戦略
- Namespace / Label 分離
networkingNamespace に Envoy DaemonSet と Control Plane を配置し、アプリケーションとは別管理。- 標準化されたヘルスチェック（Bootstrap の例と同一）
|
1 2 3 4 5 6 7 8 9 |
readinessProbe: httpGet: path: /ready port: 9901 livenessProbe: httpGet: path: /healthz port: 9901 |
- ロールバック手順
- 新しい ConfigMap を
kubectl apply -f→ Control Plane が新スナップショット作成。 - 問題が顕在化したら、以前の ConfigMap バージョンへ
kubectl rollout undo daemonset/envoy-proxy。 - 同時に Control Plane のキャッシュを旧バージョンに戻す（
SetSnapshot(..., oldSnapshot)）。
ポイント：ConfigMap と SnapshotCache を 1 対 1 に対応させることで、K8s の
kubectl rollout undoが自動的に xDS 側のロールバックもトリガーします。
6. まとめ
| 項目 | 要点 |
|---|---|
| xDS API 全体像 | LDS・RDS・CDS・EDS・SDS は独立した Discovery Service として機能し、差分配信で高速構成変更が可能。 |
| Envoy 1.30 のインストール | apt/apk ではバージョン固定 (=1.30.x) が必須。Docker イメージはタグ v1.30.0 を使用し、HTTP/3 はデフォルト無効であることに注意。 |
| Bootstrap 設定 | gRPC と REST はリソースタイプごとに分離して記述。TLS は必ず transport_socket で明示し、必要なら環境変数で HTTP/3 を有効化。 |
| Kubernetes DaemonSet | hostNetwork・SecurityContext・admin API ヘルスチェックを組み込み、RollingUpdate による無停止アップグレードを実現。 |
| カスタム Control Plane | Go と Python の最小サンプルは完全コンパイル可能で TLS / mTLS とエラーハンドリングを備える。公式 envoycontrolplane は拡張性が高く本番向き。 |
| 運用ベストプラクティス | 証明書は Secret 経由で管理し、ConfigMap → Control Plane → Envoy のリアルタイム更新フローを活かす。admin API・pprof で可観測性を確保し、Namespace/Label によるリソース分離とロールバック手順で安全性を高める。 |
上記の手順とベストプラクティスに従えば、2026 年版 Envoy 1.30 系 を Kubernetes 環境で 安全・可観測・高速に デプロイでき、xDS による動的構成管理を最大限活用できます。
スポンサードリンク