目录
前言
“Istio是不是可以替换掉Ingress-controller?”
开题还是从一个问题入手吧，相信在容器化、Mesh化过程中，我们想替换掉的不仅仅是ingress-controller吧，例如各种ServiceProxy、Api Gateway等，因为云原生架构下有更好的扩展支持，但是请大家先不要急着说答案。
下面我们先来看下Tyk博客上的一篇文章节选。
标题：“ServiceProxy，ServiceMesh，API gateway 我们怎么选?”
服务代理、服务网格还是API网关？它们都是微服务架构中辅助网络通信的组件。然而它们都有不同的用途，并具有适合特定用例的独特功能：
-
服务代理是一种通用代理。如果单独使用，它通常用作负载均衡器。
-
服务网格对于平台工程师、DevOps和站点可靠性工程师来说非常方便，因为他们希望统一应用安全和治理策略。它还使他们能够详细了解微服务的执行情况。
-
API网关更多地面向API开发人员和API产品所有者。
当然，在服务代理、服务网格和API网关之间做出选择时，并不是选择一个或另一个的问题,我们可以组合使用它们。最终，它归结为你试图实现的结果。
-
您的网络是否需要零信任安全？一个服务网格可以为您自动化！
-
你想在开发中采用API优先的方法吗？然后，这里有一个API网关可以提供帮助。
你两个都要吗？为什么不呢！事实上，为什么不探索下API网关如何与服务网格一起工作呢？
看完这篇文章后，我突然觉得“Istio是不是可以替换掉Ingress-controller?”这个问题有点喜新厌旧的意思了。虽然istio代表的服务网格被大家认可，但其实无论是Ingress 还是 Api Gateway 并没有掉队，它们在和Istio一样，都尽力在努力支持新一代云原生网关Gateway API规范。因此我认为在此用“替换”一词是不正确的，但是我们可以有“选择”的权力。
下面是我调研的一些资料，来让我们更好的理解为什么是选择而不是替换！
一、网关分类
1.传统网关分类
行业中通常把网关分为两个大类：流量网关与业务网关。
-
流量网关
主要提供全局性的、与后端业务无关的策略配置，例如阿里内部的的统一接入网关Tengine就是典型的流量网关；
-
业务网关
主要提供独立业务域级别的、与后端业务紧耦合策略配置，随着应用架构模式从单体演进到现在的分布式微服务，业务网关也有了新的叫法 - 微服务网关（图示说明如下）。
2.下一代网关
目前容器技术与K8s主导的云原生时代，下一代网关模式依然是这样吗？
在虚拟化时期的微服务架构下，业务通常采用流量网关 + 微服务网关的两层架构，流量网关负责南北向流量调度和安全防护，微服务网关负责东西向流量调度和服务治理，而在容器和 K8s 主导的云原生时代，Ingress 成为 K8s 生态的网关标准，赋予了网关新的使命，使得流量网关 + 微服务网关合二为一成为可能。
二、云原生新一代网关规范 Gateway API
1.Gateway API 优势
Gateway API 相比 Ingress 的功能性更强，旨在通过由许多供应商实现并具有广泛行业支持的富有表现力、可扩展和面向角色的接口来发展 Kubernetes 服务网络。当下 Gateway API 具有如下的优势：
-
面向角色：Gateway 是由一组 API 资源组成的。不同的 API 资源代表了使用与配置 Kubernetes 网络资源的不同角色；
-
表现力强：Gateway API 的核心功能就包含诸如基于头的匹配、流量加权以及其他在 Ingress 中只能通过各实现者自定义的非标准化 Annotations 等方式实现的功能；
-
可扩展：Gateway API 允许不同资源在不同层级一同使用。这使得能够对 API 结构进行更精细化的控制。
2.支持情况
Gateway API 作为一种扩展 Kubernetes 服务网络的标准，其 Gateway 资源能够实现作为 Kubernetes API 来管理网关的生命周期，功能十分强大。目前许多 Ingress controller 都在积极支持它，包括 Istio、Kong、Traefik 等。在目前Gateway API 实现情况中，很遗憾的是，Ingress NGINX 尚未计划支持 Gateway API 。而 APISIX Ingress 已经支持了 Gateway API 的大部分特性：包括 HTTPRoute、TCPRoute、TLSRoute、UDPRoute 等。
Gateway Controller 支持情况：
-
Acnodal EPIC
-
Amazon Elastic Kubernetes Service (alpha)
-
Apache APISIX (beta)
-
Avi Kubernetes Operator (tech preview)
-
Azure Application Gateway for Containers (preview)
-
BIG-IP Kubernetes Gateway (beta)
-
Cilium (beta)
-
Contour (beta)
-
Easegress (GA)
-
Emissary-Ingress (Ambassador API Gateway) (alpha)
-
Envoy Gateway (beta)
-
Flomesh Service Mesh (beta)
-
Gloo Gateway 2.0 (beta)
-
Google Kubernetes Engine (GA)
-
HAProxy Ingress (alpha)
-
HashiCorp Consul
-
Istio (beta)
-
Kong (GA)
-
Kuma (beta)
-
LiteSpeed Ingress Controller
-
NGINX Gateway Fabric (GA)
-
STUNner (beta)
-
Traefik (alpha)
-
Tyk (work in progress)
-
WSO2 APK (GA)
Service Mesh 支持情况：
-
Istio (experimental)
-
Kuma (experimental)
-
Linkerd (experimental)
看到了吗？Istio 在Gateway API适配也没有达到GA的程度，而部分网关如APISIX、Kong也在与其齐头并进，甚至提前一步完成了GA。
三、Top Ingress Provider
在容器化的云原生大背景下，Kubernetes已经成为了基础设施与上层应用的标准接口，Kubernetes集群天然的内外网络隔离环境，使得外部流量进入Kubernetes集群内部需要通过入口网关，因此Kubernetes通过Ingress来规范化入口网关的定义与标准，虽然Ingress标准存在一些如路由表达能力弱等不足之处，社区已经在积极推进Gateway API标准定义来解决，但不可否认的是目前Ingress标准仍然占据主流，CNCF年度报告中也单独统计了Ingress Provider（Ingress标准的实现方统称为Ingress Provider）的使用情况。
从上述统计报告中可以看到虽然目前Nginx Ingress仍然占据K8s Ingress Provider榜首，但Envoy的增长是最快的，已经从2019年的不足20%增长为2020年的37%，且仅在Nginx Ingress之后，增长势头非常迅猛，这说明选择以Envoy为内核是符合云原生发展趋势的；而且随着Service Mesh逐步被大众认可，Istio + Envoy的体系可以同时覆盖Mesh与Ingress领域，实现以一套技术架构调度东西向、南北向全域流量的目标，这对用户来说也是非常有意义的。
四、信息汇总
| 类型 | 功能 |
|---|---|
| Ingress | 负载均衡、TLS、Host/Path级路由、Annotations控制、副本级流控等 |
| Istio | 负载均衡、TLS、Host/Path/版本/身份级路由、分层解耦控制、百分比流控等 |
| Api Gateway | 负载均衡、TLS、Host/Path路由、中心化控制、鉴权、数据聚合、速率限制等 |
目前在三者都未完成适配Gateway API规范的前提下，我们可以从以上表格中看到：
-
Istio 相对于Ingress，对于服务的管控更加精细化，但从应用层面看不如Ingress的普及率高；
-
Api Gateway 面向云原生也提供Ingress级支持，功能虽更趋向于全面化，但负重前行真的好吗？
-
Ingress 从长远看虽作为过渡级方案，但是应用广泛，群众基础比较牢靠；
因此，关于Ingress的替换就好比大环境下的开源节流，明明发挥着重大作用，可不能因为一时的大局观截到大动脉！
总结
随着架构向元原生架构演进，运维的视野也在从流量网关（Nginx）、服务网关（API Gateway）向Ingress Controller、Gateway Controller逐步转变，这不只简单是运维工具的切换，而面向的是整个云原生知识体系。首先这不是要革咱们运维的命，而是让我们通过回顾过去来更好的体验技术之美。
999
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
