K8s 原生 Serverless 实践：ASK 与 Knative

以一个简单的场景为例：

• 在 K8s 中实现基于流量的灰度发布

如果要在 K8s 中实现基于流量的灰度发布，需要创建对应的 Service 与 Deployment，弹性相关的需要 HPA 来做，然后在流量灰度发布时，要创建新的版本。

以上图为例，创始版本是 v1，要想实现流量灰度发布，我们需要创建一个新的版本 v2。创建 v2 时，要创建对应的 Service、Deployment、HPA。创建完之后通过 Ingress 设置对应的流量比例，最终实现流量灰度发布的功能。

• 在 Knative 中实现基于流量的灰度发布

如上图所示，在 Knative 中想要实现基于流量的灰度发布，只需要创建一个 Knative Service，然后基于不同的版本进行灰度流量，可以用 Revision1 和 Revision2 来表示。在不同的版本里面，已经包含了自动弹性。

从上面简单的两个图例，我们可以看到在 Knative 中实现流量灰度发布时，需要直接操作的资源明显较少。

3. Knative Serving 架构

---

• **Service **

Service 对应 Serverless 编排的抽象，通过 Service 管理应用的生命周期。Service 下又包含两大部分：Route 和 Configuration。

• Route

Route 对应路由策略。将请求路由到 Revision，并可以向不同的 Revision 转发不同比例的流量。

• Configuration

Configuration 配置的是相应的资源信息。当前期望状态的配置。每次更新 Service 就会更新 Configuration。

• Revision

每次更新 Configuration 都会相应得到一个快照，这个快照就是 Revision，通过 Revision 实现多版本管理以及灰度发布。

我们可以这样理解：Knative Service ≈ Ingress + Service + Deployment + 弹性（HPA）。

4. 丰富的弹性策略

---

当然，Serverless 框架离不开弹性， Knative 中提供了以下丰富的弹性策略：

• 基于流量请求的自动扩缩容：KPA；

• 基于 CPU、Memory 的自动扩缩容：HPA；

• 支持定时 + HPA 的自动扩缩容策略；

• 事件网关（基于流量请求的精准弹性）。

三、Knative 和 ASK 融合

=======================================================================================

1. ASK：Serverless Kubernetes

---

如果要准备 ECI 资源的话，需要提前进行容量规划，这无疑违背了 Serverless 的初衷。为摆脱 ECI 资源的束缚，不必提前进行 ECI 资源规划，阿里云提出了无服务器 Serverless——ASK。用户无需购买节点，即可直接部署容器应用，无需对节点进行维护和容量规划。ASK 提供了 K8s 兼容的能力，同时极大地降低了 K8s 的使用门槛，让用户专注于应用程序，而不是底层基础设施。

ASK 提供了以下能力：

• 免运维

开箱即用，无节点管理和运维，无节点安全维护，无节点 NotReady，简化 K8s 集群管理。

• 极致的弹性扩容

无容量规划，秒级扩容，30s 500pod。

• 低成本

按需创建 Pod，支持 Spot，预留实例券。

• 兼容 K8s

支持 Deployment/statfulset/job/service/ingress/crd 等。

• 存储挂载

支持挂载云盘、NAS、OSS 存储券。

• Knative on ASK

基于应用流量的自动弹性，开箱即用，缩容到最小规格。

• Elastic Workload

支持 ECI 按量和 Spot 混合调度。

• 集成 ARMS/SLS 等云产品

2. Knative 运维复杂度

---

Knative 运维主要存在三个方面的问题：Gateway、Knative 管控组件和冷启动问题。

如上图所示，在 Knative 中管控组件会涉及到相应的 Activator，它是从 0 到 1 的一个组件；Autoscaler 是扩缩容相关的组件；Controller 是自身的管控组件以及网关。对于这些组件的运维，如果放在用户层面做，无疑会加重负担，同时这些组件还会占用成本。

除此之外，从 0 到 1 的冷启动问题也需要考虑。当应用请求过来时，第一个资源从开始到启动完成需要一段时间，这段时间内的请求如果响应不及时的话，会造成请求超时，进而带来冷启动问题。

对于上面说到的这些问题，我们可以通过 ASK 来解决。下面看下 ASK 是如何做的？

3. Gateway 和 SLB 融合

---

相比于之前 Istio 提供的能力，我们需要运营管控 Istio 相关的组件，这无疑加大了管控成本。实际上对于大部分场景来说，我们更关心网关的能力，Istio 本身的一些服务（比如服务网格）我们其实并不需要。

在 ASK 中，我们将网关这一层通过 SLB 进行了替换：

• 降成本：减少了十几个组件，大大降低运维成本和 IaaS 成本；

• 更稳定：SLB 云产品服务更稳定，可靠性更高，易用性也更好。

4. 管控组件下沉

---

对于 Knative 管控组件，ASK 做了一些托管：

• 开箱即用：用户直接使用 Serverless Framework，不需要自己安装；

• 免运维、低成本：Knative 组件和 K8s 集群进行融合，用户没有运维负担，也无需承担额外的资源成本；

最后

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Java工程师，想要提升技能，往往是自己摸索成长，自己不成体系的自学效果低效漫长且无助。

因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，不论你是刚入门Java开发的新手，还是希望在技术上不断提升的资深开发者，这些资料都将为你打开新的学习之门！

如果你觉得这些内容对你有帮助，需要这份全套学习资料的朋友可以戳我获取！！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，不论你是刚入门Java开发的新手，还是希望在技术上不断提升的资深开发者，这些资料都将为你打开新的学习之门！

如果你觉得这些内容对你有帮助，需要这份全套学习资料的朋友可以戳我获取！！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！