为什么我不使用Kubernetes的Ingress

很不幸，据我所知Kubernetes的文档不是很完美，这就是为什么有很多同学在使用它的时候会遇到很多的坑，Ingress这个组件就是这些坑中的一个。

那什么是ingress呢？

非常简单！Ingress就是依靠hostname或者path为不同的service提供了一个流量的代理（译者注：ingress就是一个工作在7层的负载均衡器），所以这样的一个负载均衡器可以代理很多的微服务。

一个没有ingress的基础架构是这样的：

一个有ingress的基础架构是这样的：

所以现在你不需要担心不同的负载均衡器了，你需要做的仅仅是在ingress的yaml文件中定义路径，主机名和目标服务（具体格式请参考：https://kubernetes.io/docs/con ... gress/)。

它非常酷，对吧？
但其实并非如此，下面我来告诉你为什么。

当我想要设计一个生产环境的时候，我总是想把它变得高可用（high availability），它的好处是可以监控每个系统部件并且预防宕机的发生，并且在部署一个新微服务的时候不会中断已经的部署了的服务。也就是说，我要首先保证的是每一个被部署的组件都是完全独立的。

我有部署过很多生产环境的经验，我非常感谢kubernetes和微服务方法，让我从每天部署不多于1个服务到每天部署20至30个（当然是不同种类的服务）但是这个时候如果你只有一个ingress，那么就比较痛苦了，因为：

1. 当你要添加了一个新的服务或hostname而需要升级你的ingress配置文件的时候，也就是说（你在一个持续集成的环境中）你要为你的pipeline去增加一个额外的步骤，让它去检查ingress的配置是否需要更新（这意味着在某种程度上你的所有microservices之间共享一个ingress）或者你是需要把你的pipeline分成两部分，其中一部分用来更新ingress（也就是说一个微服务的部署不是独立的，它还需要去更新ingress的配置才能生效）。
2. 你引入了复杂的一层，而且它还是一个单点（如果这个点不工作了，那么你所有得服务都将无法访问）。
3. 另一个原因就是我总是喜欢在设计产品环境时把监测功能考虑进去，这样度量基本上可以弹性伸缩并且可以防止宕机，所以有一些不同的外部负载均衡器（ELBs）可以提供给你更有效的监控策略，因为这里没有一个单点是被所有共享的（译者注：也就是说，你的系统里不会因为一个组件出了问题导致所有服务都不可用，所以的负载均衡功能上都是可以互相备份的）。

这就是我倒现在为止，决定不使用kubernets ingress的原因，事实上，大部分的流量都发生在集群内部。仅仅有很少一部分服需是要暴露在外面的。

很明显，应用程序架构各不相同的，所以没有一招儿是可以包打天下的，其中的如何取舍取决于你自己，希望本文能给你一些设计上的灵感。