Serverless 基建设计

• Kubernetes 虚拟化
• OpenWhish
• Knative 架构
• 1. Knative 架构设计
  • 1.1 核心组件拆分
  • 1.2 组件交互与数据流
• 2. Knative 最佳实践
  • 2.1 服务部署与版本管理
  • 2.2 构建流程提效
  • 2.3 事件驱动设计
  • 2.4 可观测性建设
  • 2.5 生产环境高可用
• 3. 总结与演进方向

Kubernetes 虚拟化

• KubeVirt
• sysbox

其他 Kubernetes 相关项目：

• KubeVela
• KubeEdge

OpenWhish

• Docker Compose 部署：https://github.com/apache/openwhisk-devtools/blob/master/docker-compose/README.md
• K8S 部署：https://zhuanlan.zhihu.com/p/269388017

参见：知名的 Serverless 开源项目都有哪些？

Knative 架构

• Build 借助 BuildTemplate 完成源码到镜像的构建，镜像推送到镜像仓库；
• Serving 里的 Service 整合 Route（流量路由）与 Configuration（版本配置），Configuration 生成不可变的 Revision，最终由 Revision 管理业务容器（Pod）；
• Eventing 中 Event Source 产生事件并发送到 Broker，Trigger 基于规则从 Broker 过滤事件后，路由到目标 Service，Channel 作为可选的事件传输管道支撑 Broker 可靠投递。

1. Knative 架构设计

Knative 是 Kubernetes 上的无服务器（Serverless）应用编排框架，旨在简化云原生应用中服务部署、缩放、事件驱动等场景的实现。其架构核心围绕构建（Build）、服务（Serving）、事件（Eventing） 三大组件展开。

1.1 核心组件拆分

• Serving 组件：聚焦于部署与管理无状态服务，实现请求驱动的自动扩缩（包括缩到零）。

  • Revision：代表服务的一个不可变版本，包含代码与配置快照，是部署的最小单元。
  • Route：负责流量路由规则，可将流量分配到不同 Revision（如蓝绿发布、灰度发布场景）。
  • Configuration：描述服务期望状态（如容器镜像、环境变量等），修改 Configuration 会生成新 Revision。
  • Service：是 Route + Configuration 的组合抽象，通过声明式定义快速创建/更新服务生命周期。

• Build 组件：（注：Knative 后续版本中 Build 逐渐被 Tekton 整合，属于演进中的部分，但历史架构仍需理解）负责从源码到容器镜像的构建流程编排。

  • Build：定义构建任务（如拉取代码、编译、打包成镜像、推送到镜像仓库）。
  • BuildTemplate：可复用的构建模板，封装常见构建步骤（如 Maven 构建 Java 应用、Node.js 构建等），降低重复配置成本。

• Eventing 组件：实现事件驱动架构（EDA），让服务能消费/生产事件，解耦生产者与消费者。

  • Event Source：事件源（如 Kubernetes 事件、Cloud Storage 变更、定时器等），负责生成事件。
  • Broker 与 Trigger：Broker 是事件中枢，收集各类事件；Trigger 定义过滤规则，将匹配的事件路由到目标服务（如 Service 或 Knative Service）。
  • Channel：事件传输的管道，支持不同消息中间件（如 Kafka、NATS 等）作为底层实现，保证事件可靠传递。

1.2 组件交互与数据流

以“从源码到请求响应”的典型流程为例：

1. 代码构建：通过 Build 关联 BuildTemplate，拉取 Git 仓库源码 → 编译 → 构建成容器镜像 → 推送到镜像仓库。
2. 服务部署：Configuration 指定镜像地址等参数 → 生成 Revision → Route 配置流量规则 → Service 对外暴露访问入口。
3. 流量处理：外部请求到达 Route → 按规则转发到对应 Revision 的 Pod → Pod 处理请求（若当前无 Pod，Serving 自动触发扩缩容创建 Pod）。
4. 事件驱动：若服务需响应事件，Event Source 产生事件 → 发送到 Broker → Trigger 匹配后转发到目标 Service 或 Revision，触发业务逻辑。

2. Knative 最佳实践

最佳实践围绕部署效率、资源优化、可观测性、事件驱动设计等维度展开，结合生产环境痛点总结经验。

2.1 服务部署与版本管理

• 粒度控制 Revision： 利用 Configuration 做渐进式更新，每次代码或配置变更生成新 Revision。通过 Route 控制流量比例（如 10% 流量到新版本，90% 到旧版本），实现蓝绿/灰度发布。示例 YAML（Service 定义）：

  apiVersion: serving.knative.dev/v1
  kind: Service
  metadata:
    name: my-service
  spec:
    template:
      spec:
        containers:
          - image: my-repo/my-image:v1
    traffic:
      - revisionName: my-service-00001  # 旧版本
        percent: 90
      - revisionName: my-service-00002  # 新版本
        percent: 10

• 缩容到零（Scale to Zero）优化： Knative Serving 支持请求驱动的自动扩缩，空闲时缩到零节省资源。需确保应用启动时间足够快（通过优化镜像分层、预热逻辑），避免冷启动延迟过高。可结合 autoscaler 配置调整扩缩策略（如基于并发请求数而非 CPU 指标，适合无状态 Web 服务）。

2.2 构建流程提效

• 复用 BuildTemplate： 团队内统一 Java、Python 等技术栈的 BuildTemplate，减少重复编写 Dockerfile 或构建脚本。例如 Node.js 构建模板：

  apiVersion: build.knative.dev/v1alpha1
  kind: BuildTemplate
  metadata:
    name: nodejs-build
  spec:
    steps:
      - name: npm-install
        image: node:18
        command: ["npm", "install"]
      - name: build
        image: node:18
        command: ["npm", "run", "build"]
      - name: build-image
        image: gcr.io/kaniko-project/executor:v1.9.0
        command:
          - /kaniko/executor
        args:
          - --dockerfile=Dockerfile
          - --context=.
          - --destination=my-registry/node-app:{{repoCommit}}  # 利用参数化

• 与 CI/CD 整合： Knative Build 可对接 GitOps 或 Jenkins、GitLab CI 等工具，实现“代码提交 → 自动构建 → 部署到 Knative”流水线。例如 GitLab CI 中调用 kubectl 应用 Knative Service YAML，完成持续部署。

2.3 事件驱动设计

• 解耦事件生产者与消费者： 使用 Broker 作为事件枢纽，生产者只需向 Broker 发事件，无需关心谁消费；消费者通过 Trigger 订阅感兴趣的事件（基于 CloudEvent 规范过滤）。示例 Trigger：

  apiVersion: eventing.knative.dev/v1
  kind: Trigger
  metadata:
    name: order-event-trigger
  spec:
    broker: default  # 关联 Broker
    filter:
      attributes:
        type: com.example.order.created  # 过滤事件类型
    subscriber:
      ref:
        apiVersion: serving.knative.dev/v1
        kind: Service
        name: order-processing-service  # 事件目标服务

• 事件溯源与可靠投递： 选择支持持久化的 Channel 实现（如 Kafka Channel），保证事件不丢失。结合 CloudEvent 的 id、source、type 等元数据，在消费者侧做幂等处理（防止重复事件导致业务问题）。

2.4 可观测性建设

• 指标（Metrics）与监控： Knative 组件自带 Prometheus 指标暴露（如 serving.knative.dev 下的请求数、延迟、Pod 扩缩计数）。在 Grafana 中配置 Dashboard，监控 Revision 级别的流量、Autoscaler 决策指标（如并发数）。

• 日志（Logging）： 开启 Kubernetes 集群日志采集（如 Elasticsearch + Kibana 或 Loki + Grafana），让 Service 容器日志、Knative 系统组件日志（如 activator、controller）可集中查询。通过给 Revision 打标签，实现按版本维度检索日志。

• 链路追踪（Tracing）： 集成 OpenTelemetry 或 Jaeger，在请求从 Ingress 到 Revision Pod 的过程中注入追踪 ID，分析请求延迟分布、组件依赖关系。需在 Knative 组件和业务服务中配置追踪代理（如 OpenTelemetry Collector）。

2.5 生产环境高可用

• 多租户与资源隔离： 通过 Kubernetes Namespace 隔离不同团队/应用的 Knative 资源，结合 ResourceQuota 限制 CPU、内存使用。对 Broker 等事件组件，可为关键业务单独部署 Broker 实例，避免资源竞争。

• 控制平面与数据平面冗余： Knative 的 controller（控制平面）需多副本部署，防止单点故障；数据平面（如 activator、queue-proxy）随 Revision 扩缩，需保证网络策略允许组件间通信（如 activator 与 queue-proxy 之间的流量）。

3. 总结与演进方向

Knative 架构通过模块化组件覆盖从构建到服务治理再到事件驱动的全链路，降低云原生应用开发门槛。最佳实践需结合团队技术栈、业务场景（如 Web 服务、批处理、事件驱动微服务）做适配：

• 纯无状态 Web 服务优先用 Serving 实现自动扩缩；
• 事件密集型场景深度整合 Eventing 与消息中间件；
• 持续交付流水线结合 Build（或 Tekton）实现 GitOps 流程。

未来 Knative 会更紧密结合 Kubernetes 生态（如与 KCP、Backstage 等集成），并在边缘计算、Serverless 数据库联动等方向拓展，持续简化云原生复杂场景。

以上从架构内核到落地实践梳理了 Knative 关键知识点，实际生产需根据业务规模、技术成熟度逐步落地各模块，平衡效率与稳定性。