为什么我不使用Kubernetes Ingress
本文讲的是为什么我不使用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的基础设施看起来是这样：
![1-6CC9E_ffUyNQD_9mrfZuFw.jpeg]( "1-6CC9E_ffUyNQD_9mrfZuFw.jpeg")
带有ingress的微服务架构是这样的：
![2.jpeg]( "2.jpeg")
所以使用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
