Azure Kubernetes中Envoy代理的部署与扩容可行性问询

这种架构完全支持无缝扩容，以下是具体分析和注意事项：

一、Envoy自身的扩容逻辑 #

• 你将Envoy以Deployment形式部署，直接通过kubectl scale deployment envoy-deployment --replicas=N就能快速扩容Pod实例，Kubernetes会自动将新Pod调度到集群可用节点上。
• 用于暴露Envoy的LoadBalancer Service（routing-http-new）会自动对接Azure负载均衡器，后者会基于Pod的就绪状态维护后端实例列表——只有启动完成、加载好配置的Envoy Pod才会接收外部流量，扩容过程不会出现单点故障或流量丢失。

二、与本地/Docker环境的行为一致性保障 #

• 你依赖的Kubernetes内部域名解析逻辑（CoreDNS解析ClusterIP Service域名）在Envoy扩容后完全生效：所有Envoy Pod都会通过<service-name>.<namespace>.svc.cluster.local格式的域名找到后端微服务的ClusterIP，再通过kube-proxy转发流量到后端Pod，和本地/Docker环境中基于域名路由的逻辑完全对齐。
• 只需确保Envoy路由配置中使用后端服务的ClusterIP Service域名，而非固定Pod IP——这样无论Envoy还是后端服务扩容，路由规则都无需修改，流量会自动分发到新实例。

三、扩容时的关键注意事项 #

• 配置一致性：如果用静态配置文件，建议通过ConfigMap挂载配置，更新配置时可滚动重启Envoy Deployment让所有Pod同步配置；如果使用xDS动态配置，天然支持全局配置同步，扩容更顺畅。
• 健康检查配置：给Envoy Pod添加就绪探针，避免未就绪的Pod接收流量，示例配置如下：

  readinessProbe:
    httpGet:
      path: /ready
      port: 19000 # Envoy默认管理端口
    initialDelaySeconds: 3
    periodSeconds: 5
  livenessProbe:
    httpGet:
      path: /ready
      port: 19000
    initialDelaySeconds: 5
    periodSeconds: 10
  

• 资源限制：根据Envoy实际负载（QPS、连接数等）设置CPU和内存请求/限制，避免扩容时节点资源不足导致Pod调度失败。

四、后端服务的扩容兼容性 #

• 后端微服务以Deployment+ClusterIP Service部署的方式，本身就支持无缝扩容：ClusterIP Service会自动维护后端Pod的端点列表，Envoy通过域名解析到ClusterIP后，流量会被kube-proxy负载均衡到所有后端Pod，和Envoy的扩容完全兼容。

内容的提问来源于stack exchange，提问作者KeithMac