虽然通过kube-proxy可以帮助实现集群内外的pod相互通信，对这些pod做负载均衡（用户态userspace轮询算法，性能低也不安全）和网络的流量代理，但是随着service的增多，nodeIP越来越多，并且kube-proxy生成的规则链也会越来越多，即使是iptables路由（内核态随机算法，性能高直接转给后端EndPoint）对Linux内核也是负担，因此引入loadbalancers，而且kube-proxy在7层网络架构中，只能限制到第四层，也就是传输层，对应用层(应用层在第七层)无能为力，所以引入ingress，它类似于api网关，运行一个反向代理服务器，类似于NGINX，需要部署Ingress Controller和配置默认的backend服务IP地址，定义返回报文，假如能调通就返回success，假如调不通就返回Failed，并且backend还要一个/health健康检查接口，方便kubectl健康检查，同时要保证Ingress Controller中path定义要与backend中定义的path路径保持一致，不然会报错。