在 Ubuntu 上配置 Knative Serverless 并不是简单执行几条安装命令就能完成的事情，它需要先有一个可用的 Kubernetes 集群，再在集群中安装 Knative 的 Serving 和 Eventing 组件，最后还要配置网络层才能让外部流量真正到达服务。本文假设你有一台 Ubuntu 22.04 的虚拟机或物理机，至少 2 核 CPU、4GB 内存，并且已经安装了 Docker 和 curl 等基础工具。为了让过程更轻量，我们选择 k3s 而不是完整的 kubeadm 部署 Kubernetes，因为 k3s 在单节点上运行良好，且默认就包含了必要的容器运行时。
第一步：安装轻量 Kubernetes 集群
k3s 的安装非常简单，使用官方脚本即可。它会自动下载二进制文件、创建 systemd 服务，并配置好 kubectl 的 kubeconfig 文件。安装完成后需要等待所有系统 Pod 处于 Running 状态。
# 安装 k3s curl -sfL https://get.k3s.io | sh - # 等待节点就绪 sudo k3s kubectl get nodes
默认情况下，k3s 的 kubeconfig 文件位于 /etc/rancher/k3s/k3s.yaml，只有 root 用户可以读取。为了方便普通用户操作，可以将其复制到当前用户目录并修改权限。另外，k3s 默认使用 containerd 作为容器运行时，无需额外安装 Docker，但如果你已经安装了 Docker，k3s 也支持使用 Docker 作为运行时，只需在安装时加上 --docker 参数。这里我们保持默认 containerd，因为它占用资源更少，也更适合 Serverless 场景。
安装完成后，执行 kubectl get pods -A 可以看到所有系统组件都在运行。如果节点状态为 NotReady，通常是网络插件还未就绪，k3s 默认使用 flannel，一般几十秒内就会自动恢复。确认集群可用后，我们还需要安装 Knative 的命令行工具 kn，它可以方便地管理服务、修订版本和路由。
第二步：安装 Knative Serving 组件
Knative Serving 是处理 HTTP 请求并自动管理 Pod 扩缩容的核心部分。官方提供了 YAML 文件，直接使用 kubectl apply 安装即可。安装时需要注意版本匹配，本文使用 Knative 1.12 版本作为示例，你也可以访问官方发布页获取最新版本号。
# 安装 Knative Serving CRD kubectl apply -f https://github.com/knative/serving/releases/download/knative-v1.12.0/serving-crds.yaml # 安装 Knative Serving 核心组件 kubectl apply -f https://github.com/knative/serving/releases/download/knative-v1.12.0/serving-core.yaml
这一步会创建很多 CRD，例如 Service、Configuration、Revision、Route 等。这些自定义资源是 Knative 的核心抽象：Service 代表一个应用，Configuration 保存每次部署的配置，Revision 是配置的不可变快照，Route 负责把流量分配到不同的 Revision。安装完成后，可以查看 knative-serving 命名空间中的 Pod 是否都正常运行。
很多人在这一步会遇到 webhook Pod 一直处于 CrashLoopBackOff 或未就绪的状态，这通常是因为集群中的 API Server 无法访问 webhook 服务，或者证书没有正确签发。可以先用 kubectl get pods -n knative-serving 查看具体状态，如果 webhook 一直重启，可以检查日志：kubectl logs -n knative-serving deployment/webhook。常见原因是 k3s 的 kubeconfig 中没有正确设置集群地址，或者 webhook 的 Service 无法被访问。一般等待一两分钟后会自动恢复，如果持续异常，可以删除 Pod 强制重建。
第三步：配置网络层 Kourier
Knative Serving 本身不提供外部负载均衡，需要选择一个网络层来接收外部流量并将其转发到对应的 Revision。常用的选择有 Istio、Contour 和 Kourier。Istio 功能最全但资源消耗也最大，而 Kourier 是专为 Knative 设计的轻量级 Ingress 网关，非常适合测试环境和资源受限的 Ubuntu 机器。
# 安装 Kourier
kubectl apply -f https://github.com/knative/net-kourier/releases/download/knative-v1.12.0/kourier.yaml
# 将 Knative Serving 的默认网络层设置为 Kourier
kubectl patch configmap/config-network
--namespace knative-serving
--type merge
--patch '{"data":{"ingress-class":"kourier.ingress.networking.knative.dev"}}'
安装 Kourier 后，会创建一个名为 kourier 的 Service，类型为 LoadBalancer 或 NodePort，取决于集群环境。在 k3s 中，默认使用 ServiceLB，所以 Kourier 会获得一个 ClusterIP，同时 k3s 会为它创建一个 NodePort 类型的服务。你可以通过 kubectl get svc -n kourier-system 查看实际分配的端口。为了能够通过域名访问服务，我们还需要配置 DNS。最简单的方式是使用 sslip.io 提供的 Magic DNS，它会把任何以 IP 地址开头的域名解析回该 IP。
# 获取节点 IP（假设单节点）
INGRESS_HOST=$(hostname -I | awk '{print $1}')
# 配置 domain 为 sslip.io
kubectl patch configmap/config-domain
--namespace knative-serving
--type merge
--patch "{"data":{"$INGRESS_HOST.sslip.io":""}}"
注意这里 config-domain 的 key 需要是域名，值留空表示使用默认选择器。如果你的节点 IP 是 192.168.1.100，那么访问服务时可以使用 myservice.default.192.168.1.100.sslip.io 这种格式。但还需要确保 Kourier 的 Service 能够被外部访问。如果 k3s 部署在云服务器上，通常需要开放相应的 NodePort 端口；如果是在本地虚拟机，可以直接使用 NodePort 的端口进行访问。
第四步：部署示例服务并验证缩容到零
Knative 最吸引人的特性之一就是缩容到零：当一段时间没有请求时，Pod 会被完全删除，释放所有资源；当有新请求到来时，Knative 会快速重新创建 Pod 并处理请求。我们创建一个简单的 Hello World 服务来验证这个流程。
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
name: hello
spec:
template:
metadata:
annotations:
autoscaling.knative.dev/min-scale: "0"
spec:
containers:
- image: gcr.io/knative-samples/helloworld-go:latest
env:
- name: TARGET
value: "Knative"
将上述内容保存为 hello.yaml，然后执行 kubectl apply -f hello.yaml。应用后，可以通过 kn CLI 或 kubectl 查看服务状态。使用 kn service list 可以列出所有 Knative 服务，并显示 URL。如果一切正常，访问该 URL 会返回 “Hello Knative!”。等待大约 60 秒（默认缩容时间），如果没有请求，Pod 数量会变为 0。再次访问时，会经历短暂的冷启动，然后返回结果。这个延迟通常在一两秒以内，取决于镜像拉取速度。
如果访问时出现 502 或连接超时，可以先检查 Kourier 的日志，再确认域名解析是否正确。在本地测试时，如果 sslip.io 无法解析，可以手动在 /etc/hosts 中添加记录，或者直接使用 curl 的 --resolve 参数。另外，k3s 默认的 ServiceLB 可能使用随机 NodePort，需要确认外部流量能够到达该端口。
Knative 还支持基于并发数或请求数的自动扩缩容，可以通过修改 Revision 的 annotation 来调整指标。例如，设置 autoscaling.knative.dev/target: "10" 表示每个 Pod 最多处理 10 个并发请求，超过后会创建新的 Pod。这些参数在真实 Serverless 场景中非常重要，可以根据业务需求进行微调。
第五步：安装 Eventing 组件（可选）
Knative Eventing 用于构建事件驱动的 Serverless 应用，它提供了 Broker、Trigger、Channel 等抽象，可以将事件源与消费者解耦。如果只是想要 HTTP 服务的自动扩缩容，Eventing 不是必需的。但很多开发者希望体验完整的事件驱动流程，因此这里也简要说明安装步骤。
# 安装 Knative Eventing CRD kubectl apply -f https://github.com/knative/eventing/releases/download/knative-v1.12.0/eventing-crds.yaml # 安装 Knative Eventing 核心组件 kubectl apply -f https://github.com/knative/eventing/releases/download/knative-v1.12.0/eventing-core.yaml
安装 Eventing 后，集群中会多出不少 Pod，包括 eventing-controller、eventing-webhook 等。这些组件会消耗额外的内存和 CPU，在资源紧张的 Ubuntu 虚拟机上可能会导致节点压力过大。如果你只是验证 Serving 功能，建议先不要安装 Eventing。若已经安装，可以通过删除相关 YAML 来卸载，或者使用 kubectl delete namespace knative-eventing 清理所有资源。
Eventing 的调试相对复杂，常见问题是 Broker 无法正常工作，通常是因为没有配置默认的 Broker 类。在测试环境中，可以使用 MTChannelBasedBroker，它基于 Channel 和 InMemoryChannel 实现，不需要额外的消息中间件。但要想在生产环境中可靠地传递事件，还需要对接 Kafka 或 RabbitMQ 等外部消息系统，这部分内容超出了本文范围。
总结与常见问题排查
在 Ubuntu 上配置 Knative Serverless 的关键步骤包括：使用 k3s 快速创建 Kubernetes 集群、安装 Serving 组件、配置 Kourier 网络层、设置 sslip.io 域名、部署示例服务验证缩容到零。整个过程大约需要 10 到 15 分钟，取决于网络下载速度。成功部署后，你就拥有了一个轻量级的 Serverless 平台，可以继续探索流量灰度发布、自动扩缩容策略、事件驱动等高级特性。
常见的问题主要集中在 webhook 证书未就绪、域名无法解析、NodePort 端口未开放以及镜像拉取失败。对于 webhook 问题，通常等待片刻或者删除对应 Pod 重建即可解决；域名解析问题可以手动修改 /etc/hosts；NodePort 问题需要检查防火墙和安全组；镜像拉取失败则可以更换镜像源或使用私有仓库。另外，k3s 默认的 Traefik Ingress 与 Kourier 并不冲突，但要注意不要将 Knative 的域名配置错误地指向 Traefik。
最终，当你在浏览器或 curl 中看到 “Hello Knative!” 的输出，并且能在无请求时观察到 Pod 数量归零，就说明整个配置流程已经正确完成。这套环境非常适合用于学习 Knative 的基础概念，也可以作为本地开发测试的 Serverless 沙箱。
UbuntuKnativeServerless修改时间：2026-08-20 04:10:59