目录
前言
吃透一个技术，不仅要掌握详细的用法能够熟练的操作，更需要掌握技术出现的前因后果。不会平白无故创造一种技术，技术的产生是为了解决现有痛点的。本篇就一起来看下ingress出现的前因后果。
第一章：Service
service这个逻辑概念的出现是为了解决pod漂移和容器云服务内部调用的问题。其实容器云很多概念跟公有云相似，因为它就是从公有云实例管理的理念演化过来的。service是个逻辑概念，是不占用真实资源的，跟弹性伸缩组的概念类似；pod与云实例概念类似，代表一个最小的管理资源；pod中的container与实例中进程概念类似；init-container干的事一般是cloud-init或者开机启动项里干的事。
k8s内部通过service互相寻址，但service解决不了k8s外部访问服务的问题。
第二章：Service+LB
为了让k8s外部有一个固定的入口访问k8s内的服务，常规的做法是通过负载均衡器，这样就有了固定的IP+端口，LB负责将流量转发到对应的service上。
这套解法虽然解决service外部访问的问题，但又会带来另一个致命的弊端：成本太高了。按照这种设计，每一个service都要配置一个LB，那就相当不划算了，特别是微服务场景。而关于LB的维护又不属于k8s体系，需要在云平台中去进行操作，为了完成一件事情还得跨越两个基础底座去完成。
第三章：Service+LB+Nginx
为了降低成本，可以只使用一个公共的规格足够强劲的LB，这个LB先把流量转发到Nginx上然后让Nginx转发到service上，不就解决了资源成本的问题么？
思路完全对头，也确实能达到省钱的目的，但这看似完美的设计存在一个致命的缺陷：Nginx的配置维护。每次service发生变化，Nginx就得相应的去改配置，面对一整个集群service的维护，配错了服务流向出现问题就会造成故障。要是能有个东西帮我们把这陀脏活累活干掉那该多好啊。
第四章：Service+Ingress
service的变动与Nginx配置的变动是存在绑定关系的，我们为啥不让k8s自己来管理nginx的配置，使用manifest这种声明式的方式，织入到自动化流水线中呢？这样只要把Nginx运行在k8s里，既能解决Nginx的配置维护问题，又能解决Nginx的部署和算力问题，一箭双雕。这就是Ingress。
只不过这种设计会让Nginx变成性能瓶颈，因为它承载着整个k8s的流量，可以通过pod的横向扩展能力解决算力问题，但一定要注意做好反亲和防止nginx的pod落到同一台node上，避免因竞争宿主机的网络资源带来性能瓶颈。
总结
为了解决外部访问需要引入LB，为了解决LB太多的问题引入了Nginx，为了解决Nginx配置和部署问题引入了Ingress，Ingress的使用需要注意反亲和。
新技术的产生是为了解决现有的痛点，一定要分析前因后果；新技术往往会带来新的问题，不是技术越新潮越好，而是越合适越好。