为什么我不使用Kubernetes的Ingress
2018-02-01 00:00
399 查看
为什么我不使用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,
那么就比较痛苦了,因为:
当你要添加了一个新的服务或hostname而需要升级你的ingress配置文件的时候,也就是说(你在一个持续集成的环境中)你要为你的pipeline去增加一个额外的步骤,让它去检查ingress的配置是否需要更新(这意味着在某种程度上你的所有microservices之间共享一个ingress)或者你是需要把你的pipeline分成两部分,其中一部分用来更新ingress(也就是说一个微服务的部署不是独立的,它还需要去更新ingress的配置才能生效)。
你引入了复杂的一层,而且它还是一个单点(如果这个点不工作了,那么你所有得服务都将无法访问)。
另一个原因就是我总是喜欢在设计产品环境时把监测功能考虑进去,这样度量基本上可以弹性伸缩并且可以防止宕机,所以有一些不同的外部负载均衡器(ELBs)可以提供给你更有效的监控策略,因为这里没有一个单点是被所有共享的(译者注:也就是说,你的系统里不会因为一个组件出了问题导致所有服务都不可用,所以的负载均衡功能上都是可以互相备份的)。
这就是我倒现在为止,决定不使用kubernets ingress的原因,事实上,大部分的流量都发生在集群内部。仅仅有很少一部分服需是要暴露在外面的。
很明显,应用程序架构各不相同的,所以没有一招儿是可以包打天下的,其中的如何取舍取决于你自己,希望本文能给你一些设计上的灵感。
4000
相关文章推荐
- 为什么我不使用Kubernetes的Ingress
- 为什么我不使用Kubernetes的Ingress
- Kubernetes使用Nginx Ingress暴露Dashboard
- 为什么我们不能使用KUBERNETES
- [经验交流] Kubernetes Nginx Ingress 安装与使用
- 为什么Kubernetes不使用libnetwork
- kubernetes集群中使用ingress发布服务
- C# 为什么使用了多线程界面假死?
- 为什么浏览器会使用多进程架构。
- 为什么在VMWare的NAT模式下无法使用traceroute
- 一线工程师带你深入学习和使用Kubernetes
- 从解决“cmake:The C compiler identification is unknown”论为什么开发人员应该使用google
- python里为什么需要使用装饰器(decorator)
- 为什么你要使用java8
- 第一课 为什么要使用SS7信令系统?
- java下Class.forName的作用是什么,为什么要使用它
- 为什么使用React
- 为什么Android开发者应该使用FlatBuffers替代JSON?
- 【AI-CPS OS】为什么您的企业应该使用Chatbots客户关系管理系统CRM
- 为什么dubbo使用ZkClient作为zookeeper的客户端