为什么我不使用Kubernetes Ingress


【编者的话】本文中,作者表达了个人对于是否使用Kubernetes Ingress的观点和理由。

【3 天烧脑式基于Docker的CI/CD实战训练营 | 北京站】本次培训围绕基于Docker的CI/CD实战展开,具体内容包括:持续集成与持续交付(CI/CD)概览;持续集成系统介绍;客户端与服务端的 CI/CD 实践;开发流程中引入 CI、CD;Gitlab 和 CI、CD 工具;Gitlab CI、Drone 的使用以及实践经验分享等。

不幸的是,目前的Kubernetes文档并不完善,这也是为什么很多事情非常混乱,其一就是Kubernetes Ingress。

ingress是什么?

非常简单,ingress是一层代理,负责根据hostname和path将流量转发到不同的服务上。使得一个负载均衡器用于多个微服务。

没有ingress的基础设施看起来是这样:
1-6CC9E_ffUyNQD_9mrfZuFw.jpeg

带有ingress的微服务架构是这样的:
2.jpeg

所以使用ingress你不用担心有不同的负载均衡器,你可以在ingress的yaml文件中指定paths,hosts和目标服务。详情见文档

这很酷不是吗?

不一定,我接下来会告诉你为什么。


每当我在思考生产环境的基础设施时,我总会优先想到高可用性。很明显,高可用意味着能够监控和阻止系统每一部分的宕机,以及部署新的微服务时不影响其它微服务。这意味着每次部署微服务时,部署之间完全隔离,互不影响。
根据我的经验,使用Kubernetes和微服务方法后,生产环境中微服务的部署数量,从每天不到一个增长到每天20到30个。这时使用单个ingress就出现缺点了:
  1. 如果你需要更新配置或者添加一个服务的路径,又或者是更新ingress的hostname,这意味着(如果是持续集成环境)你不得不在你的流水线中添加一个步骤来检查每次部署的ingress配置,(即你在所有的微服务之上共享了一个单独的配置层)。或者你需要一个单独的流水线来更新ingress(即ingress没有更新前你的微服务无法部署)
  2. 新增一个抽象层后,会增加基础设施的复杂性,或者是存在单点故障的风险。(如果ingress无法工作,所有的微服务都无法获取)
  3. 我总是喜欢设计带有监控的生产环境。指标要能够反应基础设施的弹性以及避免宕机。所以使用不同的负载均衡器(ELBs)可以帮助你构建高效的监控策略,因为使用多个负载均衡器的情况下,不存在单个共享的堆栈。


这些就是我现在不使用Kubernetes Ingress的原因。另一个原因是,事实上微服务间的大部分流量发生在集群内部,只有少部分服务暴露到外部网络中。

很显然每一个应用的架构都是不同的,也不存在一个完美通用的解决方案。所以是否使用Ingress取决于你自己,但我希望可以给你一些参考。

原文链接:Kubernetes Ingress, why I don’t use it(翻译:adolphlwq)

2 个评论

应用场景不同而已,如果一个常驻服务,必须一个web站点、或是一个对外API接口,用ingress 还是非常方便的。

反观,如果不用ingress而是用node port模式,那么这种服务多起来,会非常难管理。谁天天记得30001端口的是什么业务,什么域名,那几个pod。
ingress 是单点?无语了。

要回复文章请先登录注册