导语：目前服务通过ingress转发到前端的pod的80，前端的pod是nginx的80端口，转发到后端的port。但是每次更新后端的pod后都需要reload一下前端的nginx才能访问服务，否则就是404。

经过排查发现将svc的类型从headless 更换为普通的cluster ip就不会出现这个问题。

Headless Service “无头服务” 。 Headless Service不需要分配一个VIP，而是直接以DNS记录的方式解析出被代理 Pod的IP地址。
域名格式：$(servicename).$(namespace).svc.cluster.local

常规的service服务和无头服务的区别
  ● service：一组Pod访问策略，提供cluster-IP群集之间通讯，还提供负载均衡和服务发现
  ● Headless service 无头服务，不需要cluster-IP，clusterIP为None的service，直接绑定具体的Pod的IP，无头服务经常用于statefulset的有状态部署。

注：server资源默认分配给cluster-IP是为了让客户端能访问。而server还提供了pod之间的相互发现，互相访问资源，他们不需要cluster-IP

无头服务使用场景：
1、无头服务用于服务发现机制的项目或者中间件，如kafka和zookeeper之间进行leader选举，采用的是实例之间的实例IP通讯。
2、既然不需要负载均衡，则就不需要Cluster IP，如果没有Cluster IP则kube-proxy 不会处理它们, 并且kubernetes平台也不会给他创建负载均衡。
无头服务有一个很重要的场景是发现所有的pod（包括未就绪的pod），只有准备就绪的pod能够作为服务的后端。但有时希望即使pod没有准备就绪，服务发现机制也能够发现所有匹配服务标签选择器的pod。

比如zk集群，zk节点pod之间必须互相识别之后进行选举，pod状态才会变为就绪，使用无头服务完美的解决这个问题。

当时pod中的dns解析是否更换，多久更换一次没有去测试。只有通过nginx再转发一次才会出现这种问题，怀疑是前端pod的nginx无法识别到对应upstream的变更。应该是正常的cluster ip有负载均衡和健康检查的功能，具体当时没有进入到前端容器中排查。