为什么我不使用Kubernetes的Ingress

时间:2024-03-14 22:00:07

为什么我不使用Kubernetes的Ingress

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

那什么是ingress呢?

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

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

为什么我不使用Kubernetes的Ingress


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

为什么我不使用Kubernetes的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的原因,事实上,大部分的流量都发生在集群内部。仅仅有很少一部分服需是要暴露在外面的。

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