本文讲的是为什么我不使用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的微服务架构是这样的:
所以使用ingress你不用担心有不同的负载均衡器,你可以在ingress的yaml文件中指定paths,hosts和目标服务。详情见 文档 。
这些就是我现在不使用Kubernetes Ingress的原因。另一个原因是,事实上微服务间的大部分流量发生在集群内部,只有少部分服务暴露到外部网络中。
很显然每一个应用的架构都是不同的,也不存在一个完美通用的解决方案。所以是否使用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的基础设施看起来是这样:
带有ingress的微服务架构是这样的:
所以使用ingress你不用担心有不同的负载均衡器,你可以在ingress的yaml文件中指定paths,hosts和目标服务。详情见 文档 。
这很酷不是吗?
不一定,我接下来会告诉你为什么。每当我在思考生产环境的基础设施时,我总会优先想到高可用性。很明显,高可用意味着能够监控和阻止系统每一部分的宕机,以及部署新的微服务时不影响其它微服务。这意味着每次部署微服务时,部署之间完全隔离,互不影响。根据我的经验,使用Kubernetes和微服务方法后,生产环境中微服务的部署数量,从每天不到一个增长到每天20到30个。这时使用单个ingress就出现缺点了:
- 如果你需要更新配置或者添加一个服务的路径,又或者是更新ingress的hostname,这意味着(如果是持续集成环境)你不得不在你的流水线中添加一个步骤来检查每次部署的ingress配置,(即你在所有的微服务之上共享了一个单独的配置层)。或者你需要一个单独的流水线来更新ingress(即ingress没有更新前你的微服务无法部署)
- 新增一个抽象层后,会增加基础设施的复杂性,或者是存在单点故障的风险。(如果ingress无法工作,所有的微服务都无法获取)
- 我总是喜欢设计带有监控的生产环境。指标要能够反应基础设施的弹性以及避免宕机。所以使用不同的负载均衡器(ELBs)可以帮助你构建高效的监控策略,因为使用多个负载均衡器的情况下,不存在单个共享的堆栈。
这些就是我现在不使用Kubernetes Ingress的原因。另一个原因是,事实上微服务间的大部分流量发生在集群内部,只有少部分服务暴露到外部网络中。
很显然每一个应用的架构都是不同的,也不存在一个完美通用的解决方案。所以是否使用Ingress取决于你自己,但我希望可以给你一些参考。
原文链接:Kubernetes Ingress, why I don’t use it(翻译:adolphlwq)
原文发布时间为:2017-07-30
本文作者:adolphlwq
本文来自云栖社区合作伙伴Dockerone.io,了解相关信息可以关注Dockerone.io。
原文标题:为什么我不使用Kubernetes Ingress