Kubernetes 云原生 Gateway 网关

CNCF 对云原生的定义中提到了几个关键的点：1、强调应用环境的动态性，像公有云、私有云、混合云等新型的动态环境已成为大多数应用的首选；2、强调在跨多云部署应用时具备非云平台绑定的属性；3、还强调了弹性扩展、基于自动化手段快速部署和拉起等方面的重要性。

ejinxian

1778人浏览 · 2023-05-28 13:28:47

ejinxian · 2023-05-28 13:28:47 发布

一、云原生定义

CNCF 对云原生的定义中提到了几个关键的点：

1、强调应用环境的动态性，像公有云、私有云、混合云等新型的动态环境已成为大多数应用的首选；

2、强调在跨多云部署应用时具备非云平台绑定的属性；

3、还强调了弹性扩展、基于自动化手段快速部署和拉起等方面的重要性。

二、云原生技术解决

数字化转型的两大背景：

1、应用的数量大，复杂性随之加大；

2、应对变化和复杂性，需要更敏捷地支撑和响应；

三、发展概述

四、云原生时代

云原生时代的 API 网关具备的安全能力、流量调度或控制特性外，还需要具备以下特性

1、容器化：支持容器化部署，可部署在容器集群外、集群入口、集群内，作为容器集群入口网关需要实现 Ingress、Gateway API 模型规范；

2、微服务：支持容器集群的服务发现，服务好容器集群内的微服务；

3、服务网格：支持容器集群边缘部署，成为服务网格的出入代理网关；

4、弹性扩展：基于容器的弹性伸缩；

5、动态应用环境：支持多云部署，实现云平台无关性；

6、声明式 API：使用声明式接口完成配置运维，并可集成到 CI/CD 流水线实现自动化；

7、可观测性：可被云原生监控体系集成，实现日志、指标、链路监控；

8、多角色：DevOps、NetOps、SecOps、AppDev 等不同用户角色可基于 K8s 实现协作，提供自服务能力。

五、网关技术选型

不同规模的企业组织架构，不同的应用业务架构，不同的应用技术架构，通用场景

1、企业架构：企业内的组织架构决定了应用系统的架构，API 网关的覆盖是全企业，还是仅仅某个部门；

2、技术架构：API 网关部署的位置与应用场景会直接影响技术选型，位置是在容器集群外、集群边缘或集群内，网关仅服务单 K8s 集群、还是跨多 K8s 集群、或者跨 K8s 集群与老的微服务集群，是否需要 API 管理，对外输出统一的 API 文档和开发者门户；

3、业务场景：业务应用场景对不同的应用协议、性能、安全性等有所区别；

4、性能：API 网关代理的后端服务级别及业务特性是什么，性能是否能满足您的需求；

5、可伸缩性：API 网关是否具备横向伸缩或纵向伸缩的能力；

6、安全性：API 网关的安全能力：零信任（访问控制、认证鉴权、TLS/mTLS、审计日志）、WAAP（WAF、Bot 防护、DDoS 缓解、API 安全）；

7、用户角色：谁负责建设和运维，谁负责使用

8、成本：总的投入成本是多少，是完全基于开源自建，还是购买企业级 API 网关

六、云原生网关技术路线

1、技术路线取决于场景，企业使用云原生技术栈Kubernetes全面化，Kubernetes 集群的流量入口，用 Ingress Controller 或者 Gateway API 就可以实现。Kubernetes 集群当成当虚拟机场景。边缘网关需要实现跨集群的负载均衡；

2、网关是在各自场景里发挥作用，分流、调度、流量控制、安全防护、流量监控等基础能力；

3、核心能力包括性能、安全性、稳定性、协议支持、限流、限速等各种标准能力。

七、语言生态对网关影响

目前流行的网关组件技术栈来看，NGINX 核心采用 C 语言、Envoy 核心采用 C++、Cloudflare 采用了 Rust、Tyk 和 Traefik 采用 Go、Spring Cloud Gateway 则采用了 Java、Ocelot 采用了.net，语言选择逻辑如下：

1、微服务框架主导类网关，一般由微服务框架所采用语言决定，例如：Spring Cloud Gateway、Ocelot，更关注于微服务框架的融合能力；

2、 PaaS 平台或容器平台主导类网关，一般采用 Go 语言，因为 Kubernetes 大量使用 Go，更关注于平台技术栈一致；

3、通用型网关，能部署在各种位置的软负载、反向代理、数据中心边缘网关等组件，则通常采用 C、C++、Rust，更关注于性能、安全性、可靠性等。

八、云原生网关产品

云原生网关更多指的是 Kubernetes 入口的网关，主流实现有三种形态：

1、NGINX 或者 NGINX 衍生品为底座的一类网关，遵循Ingress API 规范，Kubernetes 集群入口；

2、基于Envoy 去实现 Envoy Proxy；

3、自研的产品，实现的是以 Kubernetes 的规范，比如 Ingress 或 Gateway API；

九、网关产品的选择

1、理清概念，网关的核心价值是建立客户端与服务端的桥梁，那么从 5W2H 的方式来分析理解一下网关的概念：

What：什么是 API 网关 / 流量网关 / 业务网关 / 微服务网关 / 云原生网关 /BFF，跟 ADC 或负载均衡有啥区别？我需要用网关解决什么问题？
When：什么时候需要增加网关层，什么时候需要修改网关配置？
Where：网关部署在什么位置？一般来说网关部署在某一个“体系”的边缘，如：数据中心入口、可用区入口、VPC 入口、企业 / 部门入口、微服务集群入口、K8s 集群入口；
Why：我为什么需要增加这层网关，带来什么价值和缺陷？
Who：网关由谁来建设，谁来运维，谁来操作使用？
How：怎么使用网关？自动化配置，还是手动配置？网关自身的高可用、安全性如何保障？如何构建网关，是自建还是用云产品？
How Many：我们需要部署几层网关？每个网关集群的性能指标是什么？打算投入多少成本？

2、架构梳理，适应企业组织架构和应用技术架构

企业组织架构：康威定律中说企业的组织架构决定应用架构，网关往往位于各组织的边界，用于衔接不同的组织。
应用技术架构：我们需要理清自身应用的主要业务场景与流量场景，及使用了哪些应用协议等。例如：视频直播类应用与电商平台类应用的流量特征肯定有所区别。此外，应用部署的环境是什么、是否为传统微服务架构（Spring Cloud），有无使用 K8s 集群，有无使用多 K8s 集群，多 K8s 集群是主备 / 双活 / 多活高可用，有无历史系统需要兼容集成，是否有统一的 PaaS 平台等都是重点考虑的内容。

3、场景梳理，网关衔接了应用与客户端，通常来说网关的核心价值点有

隐藏后端应用的内部技术架构，对外提供量身定制的 API，降低复杂度并加速应用发布；
为应用提供统一的基础设施层，把应用通用的横切面非功能都卸载到这一层；
通过统一的流量监控简化应用故障的排查；
具体有哪些场景大类呢？常见的有：
应用协议：四层协议（TCP、UDP），七层协议（HTTP/1、HTTP/2、HTTP/3、HTTPS、WebSocket、gRPC、Dubbo、SOAP、MQTT、HLS、RTMP 等）
流量路由：基于请求上下文的条件路由、蓝绿部署、灰度发布、A/B 测试、负载均衡、会话保持；
流量控制：限流限速、限并发、限带宽、请求 / 响应改写、请求重定向、协议转换、集群级限流限速
流量安全：访问控制、认证鉴权、TLS/mTLS、审计日志、WAF、Bot 防御、DDoS 缓解、API 安全、CORS；
服务治理：自动服务发现、熔断降级、主动健康检查；
服务优化：响应缓存、响应压缩
流量可视：指标监控、日志监控、链路监控、安全监控
API 管理：API 生命周期、版本控制、安全策略、流量策略、API 文档、开发者门户
高可用：主备、多活高可用，网关有状态集群（配置同步、会话同步、内存计数器同步）；
高性能：网络吞吐、请求吞吐、响应延时、基于加密卡的 SSL 卸载加速、基于 DPDK 的内核优化；
可扩展：足够的扩展点、基于脚本的插件扩展能力；
自动化运维：声明式 API、动态配置加载、自动化监控采集、容器化部署；
国产化支持：国产服务器 / 操作系统的支持、国密算法等；

十、未来网关市场

IDC 在 2022 年 10 月发布的《IDC Market Glance: Integration and API Management, 2022》，Garner 在 2022 年发表了一份市场报告《Market Guide for API Gateways》

NGINX架构

应用场景

云原生提体系

第一、把K8s 建立起高性能、高安全、高可观测性的网络连接能力，横向和纵向扩展。横向扩展需要通过Service Mesh 去解决，纵向扩展是 Ingress Controller 或者 Gateway API 解决。安全方面是由 NGINX 相关的安全模块，其基于零信任与 WAAP 体系实现较为全面的安全能力。

第二、把K8s 安全且高性能的管理集群内与集群外的 API。Kubernetes 都能做好高性能的管理，就是在安全高性能的网络问题解决后，再提供 API 管理的能力。

第三、把K8s 提升系统可靠性与韧性，实现跨集群或跨云的伸缩。

来源：