gloo edge被选用是因为其原生支持grpc/http/1.1/websocket混合协议路由与virtualservice动态策略，且直接消费k8s service endpoints，无需额外crd；而kong配置偏重、traefik不支持原生grpc透传。
为什么不用 Kong/Traefik 而选 Gloo Edge？
不是因为 Gloo Edge 更“高级”，而是它在混合协议（gRPC + HTTP/1.1 + WebSocket）和动态路由策略上更贴近实际微服务场景。Kong 的插件生态强但配置偏重，Traefik 对 IngressRoute 依赖深、不支持原生 gRPC 流量透传；而 Gloo Edge 原生支持 VirtualService 描述多协议路由，且能直接消费 Kubernetes Service 的 endpoints，无需额外 CRD 注册服务发现。
Gloo Edge 安装后必须改的三个默认配置
刚用 helm install gloo-edge gloo-community/gloo-edge --namespace gloo-system --create-namespace 装完，别急着配路由——默认配置会让请求直接 503 或跳转到内网地址。
-
gateway-proxy的service.type默认是ClusterIP，对外暴露需手动 patch 成LoadBalancer或加NodePort； -
settings资源中disableGeneratedGateways默认为true，导致自动生成的 gateway 不生效，要设为false才能响应VirtualService； -
gateway-proxy的envoyFilter默认禁用 HTTP/2 和 gRPC 支持，需在GlooEdgeSettings中显式启用：enableHttp2: true和enableGrpc: true。
Go 微服务如何被 Gloo Edge 正确识别为上游？
Gloo Edge 不依赖注解自动发现服务，它靠 Service 的 ports.name 字段匹配协议类型。你的 Go 服务 Service YAML 必须满足：
-
spec.ports[0].name不能是http或空字符串，得明确写成http-8080（HTTP）、grpc-9000（gRPC）或ws-8081（WebSocket）； -
spec.selector必须精确匹配你 Go Deployment 的labels，Gloo Edge 不做模糊匹配； - 若 Go 服务监听
0.0.0.0:8080但容器端口映射为containerPort: 8080，而Service中targetPort写成字符串"8080"（而非整数），Gloo Edge 会静默忽略该 endpoint。
写 VirtualService 时最容易漏掉的 header 重写逻辑
Go 微服务常依赖 X-Real-IP、X-Forwarded-For 做限流或灰度判断，但 Gloo Edge 默认不透传这些 header。光靠 headers 字段添加没用——必须在 VirtualService 的 options 下启用 extauth 或 ratelimit 插件，它们才会触发 header 透传链路。
- 最简方案：在
VirtualService.spec.options加extauth: {}（即使不用认证），Gloo Edge 就会自动注入X-Real-IP； - 若用
ratelimit，需额外部署rate-limitdeployment 并配置ratelimitServerUrl，否则整个路由会卡住； -
headers字段只控制 outbound（返回给客户端），inbound header 处理必须靠插件或 EnvoyFilter，别指望headers: {x-real-ip: "true"}能生效。
真正麻烦的从来不是装上 Gloo Edge，而是它把 Envoy 的底层行为封装得太深——一个没填对的 ports.name 或漏掉的 extauth: {}，就能让流量进不来，还查不出错在哪。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
