Forrest’s 博客🎎Knative-Overview
type
status
date
slug
summary
category
tags
icon
password
AI summary
Blocked by
Blocking
Category
是什么？
Knative 由 Google 主导发起，于 2025 年 10 月正式从 CNCF Incubating 级别毕业，成为 Graduated 项目，已确立为 Kubernetes 生态中 Serverless 的标准实现之一。
Knative 是基于 Kubernetes 的 Serverless 平台中间层，通过一组 CRD提供如下能力：
- 高层抽象的应用部署（无需直接管理 Pod/Deployment/Ingress）
- 自动伸缩（包括 Scale-to-Zero）
- 事件驱动（CloudEvents 标准化）
- 函数式开发模型（Knative Functions）
- 无厂商绑定（Kubernetes-native，可部署于任意云）
Knative = Kubernetes + Serverless 能力扩展 + 事件驱动中间件 + 函数运行时
适合在 Kubernetes 之上构建现代 Serverless、微服务、事件驱动应用，既保留云原生灵活性，又显著降低开发和运维复杂度。
Knative解决什么问题？
围绕实际开发与运维痛点，Knative主要解决：
- 复杂的应用部署流程
传统 K8s 需要 Deployment/Service/Ingress/ConfigMap/Autoscaler 等多个对象配合。
Knative 将它们封装为一个 Knative Service，自动管理所有细节。
- Serverless 难点：扩容、缩容、冷启动、路由
Knative Serving 内置自动扩缩容、流量切分、并发控制、零负载自动下线。
- 构建事件驱动架构的复杂度
事件生产/消费、路由、过滤、交付保证等均由 Eventing 组件完成。
- 厂商锁定问题
Cloud Run、Lambda 均绑定到各自云平台。Knative 完全基于 Kubernetes，避免锁定。
- 推进开发体验
Knative Functions 允许“函数式”模式开发，无需容器知识即可部署。
Knative 的典型使用场景
场景 | 为什么适合 Knative |
HTTP API 服务 | 自动扩缩容、灰度发布、免维护 ingress |
LLM/AI 推理服务 | GPU 支持 + autoscale + 流量切分 |
事件驱动应用 | Broker/Trigger 统一事件路由 |
数据处理流水线 | CloudEvents 标准化 & 多阶段事件流 |
边缘计算 | Scale-to-zero 节省资源 |
微服务 | 版本管理 & 流量分配 & 配置解耦 |
整体的架构
Kubernetes
Knative 的最底层是 Kubernetes，它提供：
- Pod 调度与生命周期管理
- 网络（Service / Ingress / Gateway）
- 存储、配置、Secret、CRD 扩展机制
- 自动扩缩容基础（HPA/VPA、资源度量）
Knative 的所有能力最终都要落在 Kubernetes 资源之上，例如 Pod、Deployment、Revision、Service 等。
Knative Serving
Knative Serving 构建在 Kubernetes 之上，提供一套面向 HTTP 工作负载的 Serverless 运行环境：
- 自动根据请求量进行扩缩容（包括 Scale to Zero）
- 基于 Revision 的版本管理、流量切分、灰度发布
- 用 Container Image 直接部署服务
- 请求代理、路由和网络治理能力（通常基于 Istio/Kourier/Contour）
Serving 的核心作用是：将你的容器或函数作为“按需启动的 HTTP 服务”运行。
Knative Eventin
Eventing 进一步扩展了 Serving，使其具备事件驱动能力：
- 定义事件源（Source）和事件通道（Channel）
- 基于 CloudEvents 的统一事件格式
- 通过 Trigger 进行精确的事件过滤与订阅
- 实现服务之间的异步解耦
- 支持外部事件源（如 Kafka、AWS SQS、GitHub、Cron 等）
Eventing 的核心作用是：让你的服务可以在事件到达时被触发，形成事件驱动架构。
Knative Functions（Optional）
Functions 是构建在 Serving + Eventing 之上的更高层抽象：
- 提供函数级编程体验（FaaS 模式）
- 屏蔽容器构建、镜像发布、路由配置等复杂性
- 用更少的代码完成事件处理逻辑
- 自然运行在 Serving（HTTP）和 Eventing（事件触发）之上
其核心作用是：让开发者只写函数，不关心容器与基础设施。
类似的Serveless产品
Knative 官方文档也有说，在这些情况下不适合使用Knative。
Consider alternatives when:
- You need extremely low cold-start latency (sub-100ms)
- Your workloads require persistent state or long-running processes
类似Knative的Serveless产品也有不少，其中Cloud Run 和 Lambda 的冷启动比 Knative 快。
可以先看看Knative的冷启动流程
- 流量由网关进入（Kourier/Istio）
- 无实例 → Activator 拦截请求
- Activator 通知 Autoscaler 触发扩容
- Autoscaler 更新 Deployment scale
- Kubernetes 调度新 Pod
- 拉取镜像（如无缓存）
- 启动容器（containerd）
- Knative Queue Proxy + sidecar 初始化
- Activator 将流量转给新 Pod
这一整条链路每一环都可能增加延迟。
其中有不少不可控因素：
- k8s scheduler
- 容器镜像拉取时间
- 应用自身的init
- Knative 的控制面往返（Activator/Autoscaler）
相比之下，Lambda和Cloud Run不直接依赖K8s，不受k8s scheduler的限制，同时他们有大量的内部优化。
- 预拉取镜像
- 预热容器 / VM
- 快速调度算法
- CPU boost
- 优化过的 sandbox/runtime
小结
Knative 基于Serving+Eventing在k8s之上构建了一套Serverless的抽象，解决应用的部署、扩缩容、流量控制、事件驱动等关键问题，使得开发者只用关注业务逻辑，而不需要处理k8s复杂的底层资源。
Ref
Prev
Knative Hands-on
Next
阿里云核心服务概念梳理： FC / ECS /ECI / ACK /ACS
Loading...