作者:元毅、如葑
Kubernetes 作为当今云原生业界标准,被众多开发者所拥抱。Serverless Kubernetes 基于 Kubernetes 之上,提供按需使用、节点免运维的 Serverless 能力。当前 Serverless Kubernetes 中默认提供 Nginx Ingress Controller 已不能满足按需使用、免运维的诉求,Serverless Kubernetes 与 ALB 结合提供按需使用、免运维的云产品网关能力,同时在微服务场景下提供 MSE 云原生网关能力支持。这里给大家介绍一下如何在 Serverless Kubernetes 中提供网关能力增强。
背景
Serverless Kubernetes (ASK)
ASK 集群是阿里云推出的无服务器 Kubernetes 容器服务。您无需购买节点即可直接部署容器应用,无需对集群进行节点维护和容量规划,并且根据应用配置的 CPU 和内存资源量进行按需付费。ASK 集群提供完善的 Kubernetes 兼容能力,同时降低了 Kubernetes 使用门槛,让您更专注于应用程序,而不是管理底层基础设施。
在 Kubernetes 上实现 Serverless 主要做到以下两点:
第一:线上如何更聚焦业务应用。
这里我们通过 Knative ,聚焦业务应用,进一步抽象 Kubernetes 资源,提供按需使用自动弹性的能力。Knative 是基于 Kubernetes 之上提供的一款开源 Serverless 应用框架,帮助您部署和管理现代化的 Serverless 工作负载,打造企业级 Serverless 平台。
Knative 主要包括 2 大核心模块:Serving 和 Eventing
• Serving 提供了 Service 应用模型,支持基于流量的灰度发布、版本管理、缩容到 0 以及自动弹性。
• Eventing 提供事件驱动能力。支持丰富的事件源,以及用于事件流转、过滤的 Broker/Trigger 模型。
第二:向下如何让用户减少对基础设施的关注
通过 IaaS 资源免运维,减少对基础设施的关注,做到节点免运维。在 Serverless Kubernetes 中通过虚拟节点结合弹性容器实例 ECI,让用户彻底摆脱对 IaaS 的运维。
使用默认网关遇到的痛点
聊完了什么是 Serverless Kubernetes, 我们接着说当前在 ASK 中使用默认网关遇到哪些问题。当前在 ASK 中默认使用 Nginx Ingress, 但是用户需要面对如下问题:
• 自有组件,维护升级
• 手动配置弹性策略
• 手动性能调优
显然满足不了 Serverless 按需使用、节点免运维的诉求。那么接下来我们讲一下如何在Serverless Kubernetes 进行网关增强。
Knative 与 ALB
ALB
应用型负载均衡 ALB(Application Load Balancer)是阿里云推出的专门面向 HTTP、HTTPS 和 QUIC 等应用层负载场景的负载均衡服务,具备超强弹性及大规模应用层流量处理能力。ALB 具备处理复杂业务路由的能力,与云原生相关服务深度集成,提供的云原生 Ingress 网关。
应用型负载均衡 ALB 具有即开即用,超大性能,稳定可靠,弹性伸缩,按需付费等特点,更加适合 7 层应用交付场景。
应用型负载均衡 ALB 面向 7 层,支持 HTTP/HTTPS/HTTP2/WSS/QUIC/GRPC 等众多协议,单实例可支持高达 100 万 QPS,业界性能遥遥领先。
产品优势
相较于传统负载均衡(原 SLB),ALB 在产品定位、性能、功能特性、运维以及云原生支持方面具备如下优势:
弹性增强
ALB 从 0 升级到 100 万 QPS,平滑无感,无需额外操作,且完全按量付费。
性能增强
如何做到比 SLB 更强的性能,主要源于多级负载、多级调度:
•提供域名,单实例支持多达 99 个 VIP,多级流量调度。
•根据流量的增长在 AZ 间智能化扩缩,用户无需感知。
•流量在所有 AZ 所有 RS 上均匀、打散调度,防止雪崩效应。
运维增强
• 基于海量大数据计算能力打造的实时访问日志中心
• 高精度实时流量秒级监控。陡增陡降,尖峰突刺一览无余。
• 实例配置管理。向 git 一样管理配置并可一键回滚。
ALB Ingress Controller
显示结合 ALB 自身产品优势,我们如何与 Kubernetes 结合使用呢?这里我们提供 cloud provider:ALB Ingress Controller。通过 Kubernetes Ingress 直接创建 ALB 实例与规则。实现 Kubernetes 与 ALB 的集成。
ALB Ingress Controller 通过 API Server 获取 Ingress 资源的变化,动态地生成 AlbConfig,然后依次创建 ALB 实例、监听、路由转发规则以及后端服务器组。Kubernetes 中 Service、Ingress 与 AlbConfig 有着以下关系:
• Service 是后端真实服务的抽象,一个 Service 可以代表多个相同的后端服务。
• Ingress 是反向代理规则,用来规定 HTTP/HTTPS 请求应该被转发到哪个 Service 上。例如:根据请求中不同的 Host 和 URL 路径,让请求转发到不同的 Service 上。
• AlbConfig 是在 ALB Ingress Controller 提供的 CRD 资源,使用 AlbConfig CRD 来配置 ALB 实例和监听。一个 AlbConfig 对应一个 ALB 实例。
•丰富的转发特性
- 基于 Header、Cookie 转发。
- 域名 URL 转发:支持根据不同的域名和 URL 进行流量调度,提升应用系统灵活性。
•高弹性大吞吐
- 性能保障型实例:推出性能保障型实例,实现不同实例间的性能隔离,提供相应规格下的性能保障。
- 超大性能规格:针对高性能需求,提供超大规格的负载均衡实例,解决性能瓶颈问题。
•面向云原生应用
- 基于原生 Kubernetes Ingress
- 天然支持阿里云容器服务 Kubernetes 产品
- 兼容 Nginx Ingress 语义
•更安全可靠
- ALB 自带 DDoS 防护,可一键集成 Web 应用防火墙。
- 集成 WAF 防护能力
- 支持持全链路 HTTPS 加密,支持 TLS 1.3 等高效安全的加密协议。
ALB Ingress Controller 架构
实例级别配置
•自定义 CR:ALBConfig
并发控制
•同一个 Lb 串行变配,不同 Lb 并行变配。
•同一个 RsPool 串行变配,不同 RsPool 并行变配。
•Lb 变配和 Rs 变配相互独立
限速控制
•Controller 同时处理的 Lb 变配和 Rs 变配分别可配置
•Controller 每秒处理的 Lb 变配和 Rs 变配分别可配置
•当 Lb 变配或 Rs 变配失败,重新 Reconcile 的时间控制、重试次数、重试间隔分别可以配置。
Knative 流量管理
那么有了这个桥梁,我们可以很方便的将 ALB 作为 Knative 网关使用,这里我们先介绍一下 Knative 的流量管理。
Knative 提供了强大的流量管理能力,包括:基于流量的灰度发布、基于流量的自动弹性以及请求事件驱动的能力。
Knative 结合 ALB 的实现
接下来我们看一下 Knative 结合 ALB 的实现。这里关键设计:将 Knative Ingress 转换成 Kubernetes Ingress, 然后通过 ALB Ingress Controller 创建 ALB 以及转发规则。
Knative 与 ALB 结合优势
那么 Knative 与 ALB 结合给我们带来了哪些呢?
• 网关全托管、免运维
• 基于流量弹性
• Header/Cookie/权重灰度发布
• 自动证书发现
MSE 云原生网关
在虚拟化的微服务架构下,业务通常采用流量网关 + 微服务网关的两层架构,流量网关负责南北向流量调度和安全防护,微服务网关负责东西向流量调度和服务治理,而在容器和 Kubernetes 主导的云原生时代,Ingress 成为 Kubernetes 生态的网关标准,赋予了网关新的使命,使得流量网关 + 微服务网关合二为一成为可能。MSE 云原生网关是兼容 Kubernetes Ingress 标准的下一代网关,将传统的流量网关和微服务网关合并,降低 50%资源成本。
MSE 云原生网关 - 与 ASK 集成支持微服务能力
云原生网关默认集成了容器服务 ASK,支持一键导入 Kubernetes 服务且自动同步 Endpoint;且自研 Multi-Ingress Controller 组件支持多 ASK 集群复用同一个网关实例,支持 Nginx Ingress 核心功能注解的无缝转换。这里只做简单的介绍,更多 MSE 云原生网关内容,可以关注后续的专门介绍。
使用场景
Serverless Kubernetes 目前支持的场景包括高弹性互联网场景、视音频行业低延迟场景、面向云原生应用场景等按需使用场景。结合 ALB 网关,可以实现新功能上线灰度发布,业务流量仿真,结合 MSE 云原生网关,可以在微服务架构最后实现快速服务发现。
小结
Severless Kubernetes 网关增强:
•Knative 与 ALB 集成,提供更应用感知 Serverless。
•支持 MSE 云原生网关,提供微服务场景能力。