企业官网建设流程全解析

• 文档
• 教程
• 云原生

本文以 Knative 官方博客《Build, Deploy, Manage Modern Serverless Workloads using Knative on Kubernetes》为核心骨架，结合当前仓库（docs）中最新版本的 Serving、Eventing 文档与示例代码，系统梳理 Knative 的设计动机、核心对象模型、Serving 实战流程与 Eventing 事件驱动机制。读完本文，你将掌握 Knative 在 Kubernetes 上实现"构建—部署—管理"一站式 Serverless 工作负载的核心概念，并能基于仓库文档独立完成首个 Service 的部署、流量拆分、自动扩缩容观察与事件流搭建。

背景：Kubernetes 已经很好，但开发者体验仍有缺口

时至今日，Kubernetes 已经成为绝大多数现代工作负载的默认部署目标。诚然，仍存在一些场景下 Kubernetes 并非最优选择，但这类场景在现代工作负载中所占的比例越来越小。

Kubernetes 的核心价值在于：它极大地抽象了基础设施管理的痛苦。几乎所有主流云服务商（CSP）的广泛支持，意味着你的工作负载天然具备可移植性；再加上已经非常繁荣的 Kubernetes 工具生态，运维人员（operator）——即负责管理 Kubernetes 的人——的体验已经相当顺畅。

那么，开发人员（developer）——即在 Kubernetes 之上构建解决方案的人——的体验如何呢？

尽管有人宣称 Kubernetes 已经等同于今天的"应用服务器"，但事实并非如此。首先，在 Kubernetes 上开发、部署和管理服务的过程仍然过于复杂。日志、监控、集成等方向虽然已有大量开源项目，但即便把它们正确地组合在一起，在 Kubernetes 上进行开发的体验依然脆弱、且过于耗费人力。

更糟的是，函数（function）作为代码开发最小单元的流行进一步增加了整体复杂度——它常常在两条互不相连的面上制造出不同的开发模式：一条面向函数（FaaS），一条面向应用（PaaS）。

结果是，今天的开发者被迫去操心与基础设施相关的琐事：镜像构建、镜像仓库发布、部署服务、负载均衡、日志、监控、扩展……而这些开发者真正想做的，只是写代码。

认识 Knative：为 Kubernetes 而生的 Serverless 平台

正是在这一背景下，Knative（发音 kay-nay-tiv）诞生了。在旧金山举办的 Google Cloud Next 大会上，Google 发布了 GKE Serverless 插件（g.co/serverlessaddon）的早期预览，同时开源了为其提供底层能力的 Knative 项目（github.com/knative）。

Knative 沉淀了 Google 内部的大量实践经验，开源项目从一开始就汇聚了 Pivotal、IBM、Red Hat、SAP 等公司的贡献，并与 OpenWhisk、riff、Kyma 等开源 Function-as-a-Service 框架社区展开协作——这些社区要么迁移到 Knative 之上，要么消费 Knative 项目中的一个或多个组件。

Knative 的核心使命可以用一句话概括：

Knative 帮助开发者在 Kubernetes 上构建、部署和管理现代 Serverless 工作负载。

它提供了一组积木式的构建模块，让"源码为中心（source-centric）"与"基于容器（container-based）"的开发工作负载得以在 Kubernetes 上落地。在项目早期，Knative 由三大组件构成：

• Build—— 源码到容器的构建编排（Source-to-container build orchestration）；
• Eventing—— 事件的管理与投递（Management and delivery of events）；
• Serving—— 请求驱动的计算，可缩容到零（Request-driven compute that can scale to zero）。

需要说明的是，这是 Knative 最初公开时的组件划分。在后续演进中，Build 组件的职能由 Cloud Native Buildpacks、ko、Tekton 等社区方案承接；当前仓库（docs）中 Knative 的组件已稳定为Serving、Eventing与Functions三部分——其中 Functions 通过客户端funcCLI 将无状态函数构建、部署为标准容器，并不安装进集群（详见 安装文档）。本文的实践部分将聚焦于持续维护的 Serving 与 Eventing 两大组件。

Knative 的核心设计：基于 CRD 的职责分离对象模型

Knative 建立在**清晰的职责分离（separation of concerns）这一前提之上。它允许开发者和运维者通过定义一组自定义资源定义（Custom Resource Definitions，CRDs）**来思考工作负载的开发、部署与管理，这些 CRD 扩展了 Kubernetes 本身的对象模型。

围绕 Serving，Knative 定义了四个核心原始对象：

结合当前仓库中的 Serving 资源说明，可以更准确地理解这四个对象在现代 Knative 中的具体语义：

• Service（service.serving.knative.dev）：自动管理工作负载的整个生命周期。它控制其他对象的创建，确保你的应用始终拥有一个 Route、一个 Configuration，并且每次更新都会产生新的 Revision。Service 既可以配置为始终将流量路由到最新 Revision，也可以固定路由到某个指定的 Revision。
• Route（route.serving.knative.dev）：把网络端点映射到一个或多个 Revision。你可以通过多种方式管理流量，包括按百分比拆分（fractional traffic）和命名路由（named routes）。
• Configuration（configuration.serving.knative.dev）：维护部署的期望状态。它提供了代码与配置之间的干净分离，遵循 Twelve-Factor App 方法论；修改 Configuration 即会触发新 Revision 的创建。
• Revision（revision.serving.knative.dev）：工作负载每次修改时，代码与配置在时间点上的快照。Revision 是不可变对象，可以按需长期保留；Knative Serving 的 Revision 会依据流入流量自动扩容或缩容。

这一对象模型的"功能性实现"，意味着 Knative既容易上手，又足以支撑更高级的使用场景——随着解决方案复杂度的增长，你不需要换一套平台。

Knative Serving 实战：从部署第一个 Service 到流量管理

Knative Serving 支持快速部署 Serverless 容器、自动扩缩容（包括缩容到零），以及对接多种网络层（如 Contour、Kourier、Istio）以融入既有环境，并同时支持 HTTP 与 HTTPS 协议（详见 Serving 概览）。

部署你的第一个 Service

仓库中的 Getting Started 教程 演示了如何部署一个读取环境变量TARGET并打印Hello ${TARGET}!的 Knative Service。有两种等效的部署方式。

方式一：使用knCLI

kn service create hello \ --image ghcr.io/knative/helloworld-go:latest \ --port 8080 \ --env TARGET=World

预期输出：

Service hello created to latest revision 'hello-00001' is available at URL: http://hello.default.${LOADBALANCER_IP}.sslip.io

其中${LOADBALANCER_IP}取决于集群类型：kind环境下为127.0.0.1，minikube则取决于本地隧道。

方式二：使用kubectl应用 YAML

apiVersion: serving.knative.dev/v1 kind: Service metadata: name: hello spec: template: spec: containers: - image: ghcr.io/knative/helloworld-go:latest ports: - containerPort: 8080 env: - name: TARGET value: "World"

kubectl apply -f hello.yaml

可以看到，只用Service这一个资源，Route 与 Configuration 都会被自动创建，每次更新 Service 都会生成新的 Revision。

配套的示例代码位于仓库 code-samples/serving/hello-world/helloworld-go/helloworld.go：应用通过os.Getenv("TARGET")读取环境变量（缺省值为"World"），并监听PORT环境变量指定的端口（缺省8080）响应 HTTP 请求——这正是 Knative 服务"十二要素"式配置注入的直观体现。对应的 service.yaml 则展示了最小化的 Service 清单结构。

自动扩缩容：从零到 N 的弹性

自动扩缩容（autoscaling）是 Knative Serving 的标志性能力。默认情况下，Knative 使用内置的Knative Pod Autoscaler（KPA）为应用匹配流入需求：当应用没有流量且启用 scale-to-zero 时，Knative 会将应用缩容到零副本；流量增加时再扩容以响应需求（详见 自动扩缩容文档）。

在 Autoscaling 教程 中，可以直观地观察这一过程。首先查看服务状态：

kubectl get ksvc

NAME URL LATESTCREATED LATESTREADY READY REASON hello http://hello.default.${LOADBALANCER_IP}.sslip.io hello-00001 hello-00001 True

然后观察 Pod 在无流量时如何缩容到零（可能需要最多 2 分钟，再次访问会重置计时器）：

kubectl get pod -l serving.knative.dev/service=hello -w

NAME READY STATUS hello-world 2/2 Running hello-world 2/2 Terminating hello-world 1/2 Terminating hello-world 0/2 Terminating

重新访问 URL 后，Pod 又会自动从 Pending 恢复到 Running。这种"按需扩容、无流量归零"的机制，正是 Serverless 体验的核心。

流量拆分与蓝/绿发布

Revision 是应用代码与配置的时间点快照，每次修改 Knative Service 配置都会产生新 Revision。流量拆分就是在同一 Service 的不同 Revision 之间按比例分配流量，它天然服务于蓝/绿部署与金丝雀（canary）发布。

在 Traffic splitting 教程 中，更新环境变量以创建第二个 Revision：

kn service update hello --env TARGET=Knative

预期会看到新 Revisionhello-00002，URL 不变。查看现有 Revision：

kn revisions list

NAME SERVICE TRAFFIC TAGS GENERATION AGE CONDITIONS READY REASON hello-00002 hello 100% 2 30s 3 OK / 4 True hello-00001 hello 1 5m 3 OK / 4 True

默认情况下 100% 流量指向最新 Revision。现在将流量在两个 Revision 之间各拆 50%：

kn service update hello \ --traffic hello-00001=50 \ --traffic @latest=50

对应的 YAML 形式是在 Service 的spec下追加traffic段：

spec: ... traffic: - latestRevision: true percent: 50 - latestRevision: false percent: 50 revisionName: hello-00001

反复访问服务 URL，你会交替看到Hello Knative!与Hello World!——流量确实在两个 Revision 间被均分。其中@latest始终指向最新 Revision（此处为hello-00002）。

如果需要更精细的发布流程，流量管理文档 提供了完整的蓝/绿部署操作路径：部署首个 Revision → 创建指向它的 Route → 更新 Service 产生第二个 Revision → 通过带tag: v2的命名路由把新版本"暂存"（0% 流量）→ 用独立 URL 验证 → 逐步切流 50%/50% → 最终 100% 切换到新版本。此外，traffic段还支持tag属性为特定流量目标生成独立地址（如staging-<route-name>.<namespace>.<domain>），并可通过networking.knative.dev/visibility=cluster-local标签将特定路由限定为集群内可见（见 私有服务配置）。

Knative Eventing：事件驱动的 Serverless 计算

除了上述 Serving 对象，Knative 还定义了面向事件（eventing）的原则对象——毕竟，这才叫 Serverless。

Knative 将事件生产者与消费者解耦，并以 CNCFCloudEvents规范来标准化事件处理（原博客写作时基于 CloudEvents v0.1；当前仓库文档显示事件遵循 CloudEvents 规范、specversion为 1.0，参见 Eventing 说明 与 CloudEvents 教程）。

原始的 Eventing 对象模型

在 Knative 早期的对象模型中，Eventing 定义了四个原则对象：

现代 Eventing 模型：Source、Broker 与 Trigger

随着项目演进，当前仓库的 Eventing 文档 将这一模型抽象为三个相互解耦的构件，其本质一脉相承：

• Source（事件源）：事件生产者的 Kubernetes 自定义资源，充当生产者与事件 sink（接收端）之间的桥梁。sink 可以是普通 Kubernetes Service、Knative Service、Channel 或 Broker。常见的内置 Source 包括 APIServerSource、PingSource、ContainerSource、SinkBinding、KafkaSource 等（完整列表见 Event sources 文档）。
• Broker（代理）：定义事件网格、汇聚事件池的 Kubernetes 自定义资源。它提供可发现的事件入口端点（事件生产者通过 HTTP POST 向 Broker 发送事件），并使用 Trigger 完成事件投递。出于审计与访问控制的考虑，也可以按命名空间拆分为多个 Broker（例如将含 PII 与不含 PII 的事件分开），详见 Brokers 文档。
• Trigger（触发器）：表达"订阅某个 Broker 特定事件"的意愿。Trigger 的subscriber指向一个 Destination（如 Knative Service），并可基于 CloudEvents 属性做精确过滤。当前支持exact、prefix、suffix、all、any、not、cesql等过滤方言，以及向后兼容的filter.attributes精确匹配（见 Triggers 文档）。

事件在整个链路中通过标准 HTTP POST 请求收发，并遵循 CloudEvents 规范，因此任何编程语言都能创建、解析、发送与接收事件。各组件松散耦合：生产者可以在没有活跃消费者监听之前就产生事件，消费者也可以在生产者出现之前就表达对某类事件的兴趣。

端到端的事件流示例

仓库的 Getting Started 教程 提供了一个完整的事件流示例——使用 CloudEvents Player 应用同时扮演源与接收端。

首先部署 CloudEvents Player Service，并通过SinkBinding把它绑定到名为example-broker的 Broker：

kn service create cloudevents-player \ --image quay.io/ruben/cloudevents-player:latest kn source binding create ce-player-binding \ --subject "Service:serving.knative.dev/v1:cloudevents-player" \ --sink broker:example-broker

然后创建 Trigger，让 Broker 中的事件流向 CloudEvents Player（同样作为 sink）：

kn trigger create cloudevents-trigger --sink cloudevents-player --broker example-broker

由于未指定--filter，该 Trigger 会监听进入 Broker 的所有 CloudEvents。如果想按事件类型过滤，可以指定--filter type=some-type——此时 Trigger 只投递类型为some-type的事件，其余一概忽略。

也可以直接通过命令行向 Broker 发送事件：

curl -i http://cloudevents-player.default.${LOADBALANCER_IP}.sslip.io \ -H "Content-Type: application/json" \ -H "Ce-Id: 123456789" \ -H "Ce-Specversion: 1.0" \ -H "Ce-Type: some-type" \ -H "Ce-Source: command-line" \ -d '{"msg":"Hello CloudEvents!"}'

注意：Broker 只是事件的"收纳容器"。要让事件真正被消费，必须创建 Trigger。此外，用于开发环境的 InMemoryChannel 支撑的 Broker 仅供开发使用，切勿用于生产部署（生产环境请选择 MTChannelBasedBroker 搭配持久化 Channel，或 Apache Kafka Broker，详见 创建 Broker 文档）。这种 Source → Broker → Trigger → Sink 的编排，正是社区常说的"事件驱动架构（EDA）"，你完全可以借此在 Kubernetes 上搭建自己的"函数即服务（FaaS）"。

如何安装并上手 Knative

根据 安装文档，Knative 提供三种安装路径：

想快速体验的话，安装knCLI 后运行 Quickstart 插件，即可在本地一键拉起包含 Serving 与 Eventing 的开发环境（该插件默认会预装一个 InMemoryChannel 支撑的 Broker，可用kn broker list验证）。随后即可按上文教程依次完成首个 Service 部署、流量拆分、自动扩缩容观察与事件流搭建。

总结

本文围绕 Knative 的核心脉络，从"开发者体验缺口"切入，介绍了 Knative 在 Kubernetes 上构建、部署与管理现代 Serverless 工作负载的完整图景：

• 对象模型：Configuration、Revision、Route、Service 四大 CRD 以职责分离的方式统一了应用与函数的开发、部署与管理；其"轻量起步、复杂可用"的设计，让 Knative 既能服务简单用例，也能支撑高级场景。
• Serving 实战：一个Service资源即可完成部署，并自动获得路由、配置与版本管理；配合自动扩缩容（缩容到零）与基于 Revision 的流量拆分，可以平滑实施蓝/绿与金丝雀发布。
• Eventing 机制：从早期的 Event Sources / Event Types / Event Consumers / Event Feeds，演进到如今的 Source / Broker / Trigger 模型，通过标准化的 CloudEvents 与 HTTP POST 实现生产者与消费者的完全解耦。

无论你在开发的是单体应用还是函数，Knative 的对象模型都能让 Kubernetes 上的开发流程大幅简化。围绕这些关键使用模式（镜像推送、蓝/绿部署、源码到 URL 等），仓库还提供了丰富的 Serving 代码示例 与 Getting Started 教程，可以作为下一步深入实践的起点。

• 文档
• 教程
• 云原生