Envoy是CNCF生态中广泛使用的边缘和服务代理，在服务网格架构里承担数据平面的角色。它最强大的能力之一，就是通过xDS协议从控制平面动态获取监听器、集群、路由、密钥等配置，而不需要重启进程。本文将以一台云服务器为环境，完整演示Envoy的安装、静态配置验证，以及基于xDS的动态配置对接过程。
一、Envoy静态配置与动态配置的区别
刚接触Envoy时，大多数人会从静态配置文件开始。也就是在YAML或JSON文件里把监听器、集群、路由全部写死，然后用 envoy -c envoy.yaml 启动。这种方式适合本地调试和单一场景，验证Envoy基本功能没问题。
但静态配置有个致命短板：任何配置变更都要改文件、重载进程。当后端服务扩容、路由规则调整、证书轮换时，运维成本会急剧上升。Envoy的解法是xDS，即x Discovery Services，包括LDS（监听器发现）、CDS（集群发现）、RDS（路由发现）、SDS（密钥发现）和EDS（端点发现）。控制平面通过gRPC流把配置推给Envoy，Envoy热更新，全程不断连接。
简单说，静态配置像是把菜谱写在墙上，想换菜就得重新刷墙；xDS则是有个厨师长实时告诉你下一步做什么。生产环境的服务网格，几乎都采用后者。
二、云服务器环境准备与Envoy安装
推荐使用Ubuntu 22.04或CentOS 8以上版本的云主机，配置2核4G起步。以Ubuntu为例，通过官方仓库安装最省事：
先安装基础工具，执行 apt-get update 和 apt-get install -y apt-transport-https ca-certificates curl gnupg lsb-release。接着添加Envoy的官方源，导入密钥后执行 apt-get install -y envoy。安装完成后用 envoy --version 确认版本，建议使用1.26以上版本，对xDS-v3协议支持更完整。
如果云服务器无法访问外网，可以在本地下载deb包或静态二进制后上传。安装路径通常在 /usr/bin/envoy，配置文件建议统一放在 /etc/envoy/ 目录下，例如 /etc/envoy/envoy.yaml，方便后续 systemd 管理。
三、编写静态配置验证Envoy可用性
在对接xDS之前，先用一份最小静态配置确认Envoy能正常工作。配置一个监听器接收8080端口请求，转发到本机或内网的测试服务：
在envoy.yaml中定义node节点信息，包括id和cluster两个字段，这两个值在后续xDS对接时也必须存在，因为控制平面靠node.id识别不同的Envoy实例。然后定义static_resources，写一个listener监听0.0.0.0:8080，filter chains里用envoy.filters.network.http_connection_manager，路由指向一个名为backend_service的cluster，cluster的地址指向后端服务的实际IP和端口。
启动命令为 envoy -c /etc/envoy/envoy.yaml --log-level info，然后curl访问 http://127.0.0.1:8080，能拿到后端响应就说明数据平面链路通了。这一步非常重要，静态配置跑通意味着网络、端口、安全组都没问题，后面xDS排障时可以把范围缩小到配置下发环节。
四、配置dynamic_resources对接xDS控制平面
静态验证通过后，把static_resources替换为dynamic_resources。核心是两个配置项：lds_config和cds_config，它们都指向一个api_config_source，type设为GRPC，并通过envoy_grpc指定控制平面的地址，例如127.0.0.1:18000（如果控制平面部署在同一台云服务器）或内网IP。
需要在transport_api中明确指定V3，因为V2协议已废弃。配置里还要设置set_node_on_first_message_only为true，减少每次请求重复传输node信息。实际的YAML大致结构是：dynamic_resources下有lds_config和cds_config，各自的api_config_source里写grpc_services，指定envoy_grpc的cluster_name，而这个gRPC集群本身要在static_resources里定义一个指向控制平面端口的cluster，类型建议用STRICT_DNS或LOGICAL_DNS。
路由和端点同样可以动态化。RDS在LDS的http_connection_manager里通过rds配置引用，指定route_config_name；EDS则在cluster里用eds_config替代静态load_assignment。SDS用于证书热加载，在listener的tls_context或cluster的tls_context中通过sds_config引用，证书轮换时Envoy会自动收到更新，无需重启。
五、启动参数与运行管理
生产环境建议用systemd管理Envoy进程。写一个envoy.service文件，ExecStart指向 envoy -c /etc/envoy/envoy.yaml --base-id 0 --concurrency 4 --log-level warning。其中concurrency设为CPU核数，--base-id用于避免多实例共享内存冲突。
健康检查方面，Envoy默认暴露8001端口的admin接口，通过 http://127.0.0.1:8001/clusters 和 /listeners 可以实时查看当前已下发的集群与监听器状态，判断xDS是否生效。注意这个端口只应绑定本机或内网，绝不能暴露公网。云服务器安全组记得放行业务端口，同时关闭admin端口的公网访问。
日志排查时，如果看到server.main和upstream日志频繁出现connection failure，先检查控制平面gRPC端口是否放行；如果出现LDS stream closed重连，多半是控制平面未识别node.id或证书校验失败。
六、常见报错与排查思路
第一个高频问题是Envoy启动后一直打no clusters configured。这通常是dynamic_resources里的gRPC集群名字写错，或者控制平面没有返回CDS响应。用admin接口的/config_dump接口看完整配置快照，能直接确认哪些配置没下发。
第二个常见问题是证书更新不生效。检查SDS配置里证书路径权限，Envoy进程运行用户必须有读取权限。另外注意sds_config引用的secret名称要与控制平面下发的名称完全一致，包括大小写。
第三个是node字段缺失导致的握手失败。凡是启用xDS，bootstrap配置里的node.id和node.cluster都不能省，否则gRPC流建立后控制平面无法定位实例，会直接断流。掌握这几条排查路径，在云服务器上运维一套xDS驱动的Envoy数据平面就有了基本盘。后续如果要接入Istio，会发现pilot-agent本质上就是把这个bootstrap和xDS对接过程自动化了，理解底层机制后上手会非常快。