📚 课程目录第4章生产环境安装与配置

4. 生产环境安装与配置

Knative 本身不解决“跑在什么集群上”的问题，它把这一层完全交给 Kubernetes。因此生产环境的第一步不是装 Knative，而是先把集群的节点规格、容器运行时、CNI、Ingress 与可观测性底座定下来。选型一旦确定，后续 Serving 的 Pod 调度、Eventing 的消息投递、自动扩缩容的冷启动表现都会受其约束。本节按“集群底座 → Serving/Eventing 部署 → 网络与 Ingress 选型”的顺序展开，并给出可直接参考的配置样例与判断依据。

一、Kubernetes 集群选型：先定约束，再定组件

Knative Serving 的每个 Revision 都会以 Pod 形式运行，缩容到零时 Pod 被回收，请求到达时再冷启动。这意味着集群选型要优先关注三件事：节点能否快速拉起 Pod、CNI 是否支持大规模 Service/Endpoint、以及是否允许 Knative 所需的准入与聚合 API。

节点规格上，控制面建议 3 节点起步（etcd 与 apiserver 高可用），Worker 节点按业务分池。以教学示例为例：通用池 4 vCPU / 16 GiB，用于常驻服务；突发池 8 vCPU / 32 GiB，用于冷启动密集的在线服务；Eventing 的 Broker/Channel 若使用 Kafka，则单独规划 8 vCPU / 32 GiB 的中间件池，避免与业务 Pod 争抢。容器运行时推荐 containerd，Kubernetes 版本建议 1.27 及以上，以匹配当前 Knative 版本对 API 的要求。

CNI 选型直接影响 Knative 的网络性能与可观测性。Calico 适合需要 NetworkPolicy 精细控制的场景；Cilium 基于 eBPF，在 Service 转发、可观测性和带宽效率上更有优势，适合请求量大、需要链路追踪的 Serverless 平台。无论选哪种，都要确认其支持 Knative 依赖的 Service、EndpointSlice 与 NetworkPolicy 语义。

此外，Knative 需要集群启用若干能力：Aggregated APIServer（用于 Serving 的 autoscaling 与 networking 自定义资源）、MutatingAdmissionWebhook、ValidatingAdmissionWebhook，以及可用的默认 StorageClass（用于 Eventing 的持久化 Channel）。若使用托管集群，需确认这些能力未被裁剪。

二、Knative Serving 与 Eventing 部署

部署顺序建议先 Serving 后 Eventing，因为 Eventing 的部分组件依赖 Serving 的 Webhook 与网络能力。Serving 安装核心是 serving-crds.yaml 与 serving-core.yaml，随后按需安装网络插件（如 Kourier、Istio、Contour）和 HPA 插件。Eventing 安装 eventing-crds.yaml 与 eventing-core.yaml，再按需安装 Broker 实现（MTChannelBasedBroker 或 Kafka Broker）。

# 1. 安装 Serving CRD 与核心组件
kubectl apply -f https://github.com/knative/serving/releases/download/knative-v1.12.0/serving-crds.yaml
kubectl apply -f https://github.com/knative/serving/releases/download/knative-v1.12.0/serving-core.yaml

# 2. 安装网络层（以 Kourier 为例）
kubectl apply -f https://github.com/knative/net-kourier/releases/download/knative-v1.12.0/kourier.yaml
kubectl patch configmap/config-network \
  -n knative-serving \
  --type merge \
  -p '{"data":{"ingress-class":"kourier.ingress.networking.knative.dev"}}'

# 3. 安装 Eventing 核心
kubectl apply -f https://github.com/knative/eventing/releases/download/knative-v1.12.0/eventing-crds.yaml
kubectl apply -f https://github.com/knative/eventing/releases/download/knative-v1.12.0/eventing-core.yaml

# 4. 验证
kubectl get pods -n knative-serving
kubectl get pods -n knative-eventing

部署完成后，重点检查三类状态：knative-serving 与 knative-eventing 命名空间下 Pod 是否全部 Running；kubectl get ksvc 能否正常返回；以及 Webhook 是否可用（kubectl get validatingwebhookconfiguration）。若 Pod 处于 CrashLoopBackOff，常见原因是集群未启用聚合 API 或镜像拉取受限。

三、网络层与 Ingress 选型实践

Knative 的网络层负责把外部流量路由到 Revision，并参与缩容到零后的流量唤醒。常见选型有三类：Kourier 轻量、部署简单，适合中小规模与快速验证；Istio 功能完整，支持 mTLS、细粒度流量治理与灰度，适合已有 Istio 体系或需要强流量策略的场景；Contour 基于 Envoy，配置简洁，适合偏好 Envoy 生态的团队。

选型判断可参考以下维度：是否需要 mTLS 与请求级鉴权、是否需要按 Header/权重做灰度、团队是否已有对应网关运维经验、以及单集群预期 QPS。若只是内部服务且规模有限，Kourier 往往足够；若面向公网且需要 WAF、限流、灰度，Istio 或 Contour 更合适。

Ingress 配置上，Knative 通过 config-domain 指定域名，通过 config-network 指定 ingress-class。生产环境还应配置自动 TLS（如 cert-manager）与外部 DNS。下面给出一个自定义域名与 TLS 的配置片段：

kubectl patch configmap/config-domain \
  -n knative-serving \
  --type merge \
  -p '{"data":{"example.com":""}}'

# 为 ksvc 配置自动 TLS（需 cert-manager）
kubectl apply -f - <<'EOF'
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: demo
  annotations:
    networking.knative.dev/ingress-class: kourier.ingress.networking.knative.dev
spec:
  template:
    spec:
      containers:
      - image: ghcr.io/knative/helloworld-go:latest
EOF

验证网络是否生效，可用 kubectl get ksvc demo 查看 URL，再用 curl -H "Host: demo.example.com" http://<ingress-ip> 测试。若返回 503，通常是 Kourier/Istio 的 Gateway 未就绪或 DNS 未解析；若返回 404，检查 config-domain 与 ksvc 的 host 是否匹配。

四、部署后的关键校验与常见问题

安装完成后，建议按以下清单逐项确认，避免“装上了但不可用”：

控制面健康：kubectl get pods -n knative-serving 与 -n knative-eventing 全部 Running，且无反复重启。
Webhook 可用：kubectl get validatingwebhookconfiguration | grep knative 存在且未报错。
网络层就绪：Kourier 的 kourier-system 或 Istio 的 istio-system 下 Gateway Pod 正常。
域名与 TLS：config-domain 已配置，cert-manager 签发的证书处于 Ready。
缩容到零：部署一个 ksvc，等待约 60 秒后 Pod 数变为 0，再发起请求观察是否被唤醒。

若冷启动延迟明显，可先检查 Activator 是否正常、镜像是否已预热、以及节点是否开启了足够的 CPU 预留。Kourier 场景下，冷启动通常比 Istio 略快，但流量治理能力较弱，需按业务取舍。

生产环境不要直接使用默认的 config-domain（如 example.com），也不要跳过 TLS。未配置 TLS 时，Knative 的自动 TLS 与 HTTPS 重定向不会生效，公网暴露存在风险。

最后，集群选型、Serving/Eventing 部署与网络层选型三者是相互约束的：节点规格决定冷启动上限，CNI 决定网络性能与策略能力，Ingress 决定流量治理与安全边界。建议在预发环境先用一个真实服务跑通“部署 → 缩容到零 → 唤醒 → 灰度”的完整链路，再复制到生产，避免把配置问题带到线上。