CentOS搭建的K8s集群中Ambassador提示no healthy upstream求助

刚踩过类似的坑，给你梳理几个最接地气的排查方向，一步步来应该能定位到问题：

1. 先确认后端服务的Pod是否真的健康 #

• 用命令查看目标服务的Pod状态：kubectl get pods -n <你的服务命名空间>，必须保证Pod处于Running状态，且READY列是1/1（或对应你的容器数量）
• 如果Pod状态异常，先解决Pod启动问题：通过kubectl logs <pod-name> -n <服务命名空间>查看日志，排查是否有启动报错、依赖缺失、配置错误等
• 重点检查Pod的就绪探针（readiness probe）：如果探针失败，Kubernetes会自动把Pod从服务的端点列表中移除，Ambassador自然找不到健康实例

2. 核对Kubernetes Service与Pod的关联关系 #

• 查看Service的端点信息：kubectl describe service <service-name> -n <服务命名空间>，在Endpoints部分必须能看到正常运行的Pod IP
• 如果Endpoints为空，90%是标签选择器不匹配：仔细核对Service的spec.selector和Pod的metadata.labels，确保键值对完全一致
• 也可以用简化命令快速查看端点：kubectl get endpoints <service-name> -n <服务命名空间>

3. 验证Ambassador的映射配置是否正确 #

• 检查你的Ambassador Mapping资源（可能是Ingress或专属Mapping CRD），重点确认：
  • service字段是否正确：跨命名空间必须写全域名<服务名>.<命名空间>.svc.cluster.local，同命名空间建议也写全避免歧义
  • 路由规则是否匹配：比如你用http://gateway-ip/api访问，映射的prefix要对应/api，如果是根路径则写/
  • 有没有错误的rewrite规则：如果路径重写后后端服务无法识别，也会导致上游标记为不健康
• 查看所有映射资源：kubectl get mappings -n <ambassador命名空间>，再用kubectl describe mapping <mapping-name> -n <ambassador命名空间>看详细配置细节

4. 检查Ambassador自身的运行状态 #

• 确认Ambassador Pod是否正常：kubectl get pods -n <ambassador命名空间>，状态必须是Running
• 查看Ambassador日志排查服务发现问题：kubectl logs <ambassador-pod-name> -n <ambassador命名空间>，重点看是否有权限访问其他命名空间的Service/Endpoints，或者有没有服务解析报错
• 如果集群开启了RBAC，要确认Ambassador的ServiceAccount是否拥有足够权限（至少需要view权限来获取服务和端点信息）

5. 测试集群内部的连通性 #

• 进入Ambassador Pod直接访问后端服务：

  kubectl exec -it <ambassador-pod-name> -n <ambassador命名空间> -- curl <service-cluster-ip>:<端口>
  

  如果这里访问失败，说明是集群内部网络问题，比如CNI插件（Calico/Flannel等）是否正常，Pod之间是否能互通
• 也可以在其他普通Pod里测试访问后端服务，排除Ambassador Pod自身的网络异常

6. 核对后端服务的端口配置 #

• 确认Service的spec.ports[].targetPort是否和容器暴露的端口一致：比如容器暴露的是8080，但Service的targetPort写的是80，就会导致连接失败，Ambassador标记上游不健康

我之前就是因为Service的标签选择器少写了一个字段，导致Endpoints为空，触发了这个错误，调整后就正常了。按这个顺序排查，大概率能找到问题根源。

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