为什么我不使用Kubernetes的Ingress
2017-08-12 00:00
519 查看
为什么我不使用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的原因,事实上,大部分的流量都发生在集群内部。仅仅有很少一部分服需是要暴露在外面的。
很明显,应用程序架构各不相同的,所以没有一招儿是可以包打天下的,其中的如何取舍取决于你自己,希望本文能给你一些设计上的灵感。
7fe0
相关文章推荐
- 为什么我不使用Kubernetes的Ingress
- 为什么我不使用Kubernetes的Ingress
- 为什么Kubernetes不使用libnetwork
- 为什么我们不能使用KUBERNETES
- [经验交流] Kubernetes Nginx Ingress 安装与使用
- Kubernetes使用Nginx Ingress暴露Dashboard
- kubernetes集群中使用ingress发布服务
- JDBC为什么要使用PreparedStatement而不是Statement
- 数据库为什么使用视图
- docker对cpu使用及在kubernetes中的应用
- NoSQL开篇——为什么要使用NoSQL
- Gradle使用手册(一):为什么要用Gradle?
- bitmap 为什么不能被delete正常使用?
- 15.5.1 为什么要使用密钥
- 为什么使用数组?
- 我为什么会使用360极速浏览器
- Java中为什么使用静态代码块
- 为什么RTP往往是使用UDP,而不是使用TCP封装
- 为什么要使用JS模板引擎
- 打印日志时为什么要使用isDebugEnabled 、isInfoEnabled