Knative:在 K8s 上做 Serverless

为什么需要 Knative: Serverless 的"去绑定"

第 02 篇的云 FaaS(Lambda 等)很好用, 但有两个结构性问题:

1. 厂商绑定: 函数写成了 AWS Lambda 的样子(它的签名, 它的事件格式, 它的配套服务), 想换到别的云? 基本要重写.
2. 两套世界割裂: 核心服务跑在自建的 K8s 上(有完整的可观测, CI/CD, 网络策略...), 零散任务用云 FaaS, 结果两套运维, 两套监控, 两套心智, 割裂.

Knative 的思路: 既然大家都有 K8s, 那就把 Serverless 能力做成 K8s 上的标准组件--函数/服务还是普通容器, 跑在自己的集群里, 既有 Serverless 的自动扩缩到零, 又不绑定任何云.

回到第 01 篇的抽象阶梯: K8s 已经把"集群"抽象好了, 但还得自己写 Deployment, Service, HPA, Ingress 一堆 YAML, 且 HPA 最少留 1 个 Pod(不能到零). Knative 在 K8s 之上再叠一层: 只声明一个"服务", 它自动展开成底层那一堆资源, 并补上 K8s 原生缺的两件事--缩容到零和按请求量(而非 CPU)扩缩.

它不取代 K8s, 而是站在 K8s 肩膀上.

Knative Serving: 请求驱动的服务

Serving 是 Knative 的核心, 管理"由 HTTP 请求驱动"的服务. 只需写一个 Service 资源(注意: 是 Knative 的 Service, 不是 K8s 原生的那个), 指定一个容器镜像:

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: hello
spec:
  template:
    spec:
      containers:
        - image: ghcr.io/org/hello:v1   # 就是个普通容器镜像
# 提交后, Knative 自动搞定: Deployment, Service, Ingress 路由,
# 自动扩缩(含缩容到零), 版本管理 -- 一个都不用手写

Serving 帮我们补上了 K8s 原生缺的两个关键能力:

缩容到零与按请求扩缩

K8s 的 HPA 按 CPU/内存扩缩, 且最少留 1 个 Pod. Knative Serving 不同:

• 按请求并发扩缩: 根据"当前有多少并发请求"来决定 Pod 数(更贴合 Web 服务的真实负载), 而非看 CPU.
• 能缩容到零: 一段时间没请求, Pod 数降到 0(第 02 篇的核心特征). 秘密在一个叫 Activator 的组件: 实例为零时, 新请求先被 Activator 接住, 暂存, 同时触发拉起 Pod, Pod 就绪后再把请求放行--所以"零实例"也不会丢请求(只是这第一个请求要承受第 02 篇说的冷启动延迟).

请求到达(当前实例数=0)
  → Activator 接住请求, 暂存, 不丢弃
  → 触发拉起 Pod(冷启动)
  → Pod 就绪, Activator 放行请求
  → 后续请求直达 Pod(已是热实例)

流量切分: 天然支持渐进式发布

Serving 用修订版本(Revision) 管理每次部署: 每改一次配置, 就产生一个不可变的 Revision. 然后可以按百分比把流量切分到不同 Revision:

spec:
  traffic:
    - revisionName: hello-v1
      percent: 90               # 90% 流量给旧版本
    - revisionName: hello-v2
      percent: 10               # 10% 给新版本 -- 这就是金丝雀!

有没有觉得眼熟? 这就是 CI/CD 系列第 07 篇讲的金丝雀发布--只是 Knative 把它做成了内建能力, 改个百分比就完成灰度. Knative 的 Revision + 流量切分, 天然契合渐进式交付.

可见云原生的各个主题是彼此咬合的: Serverless 的"流量切分", CI/CD 的"金丝雀", 可观测性的"指标驱动", 本就是同一套发布安全网的不同切面.

Knative Eventing: 事件驱动的另一半

Serving 管的是"请求驱动"(HTTP 来了就处理). 但第 02 篇说 Serverless 的灵魂之一是事件驱动--由消息, 文件上传, 定时器等各种事件触发. 这是 Eventing 负责的部分.

Eventing 解决一个核心问题: 如何让"事件的生产者"和"事件的消费者"解耦--生产者不需要知道谁会消费, 消费者也不需要知道事件从哪来. 它的模型(简化版):

事件源(Source)          Broker(中间枢纽)         消费者(通过 Trigger 订阅)
  ┌──────────┐           ┌─────────────┐          ┌──────────────────────┐
  │ 消息队列  │           │             │  Trigger  │ 函数A(订阅"订单创建") │
  │ 定时器    │ ──事件──▶ │   Broker    │ ────────▶ │ 函数B(订阅"支付完成") │
  │ 文件上传  │           │ (汇聚+路由) │          │ ...                  │
  └──────────┘           └─────────────┘          └──────────────────────┘
   生产者只管"发事件到 Broker", 不关心谁消费
   消费者通过 Trigger 声明"我要哪类事件", 不关心事件从哪来

• Source(事件源): 产生事件的地方(Kafka, 定时器, 各种系统).
• Broker(代理): 事件的汇聚和分发中枢--生产者把事件发给它.
• Trigger(触发器): 消费者用它声明式地订阅"我要 Broker 里哪一类事件", 并指向处理它的服务.

什么时候用 Knative

延续第 01, 02 篇的理性视角, Knative 也不是人人该上: