把流量当扩容开关：Knative 在 Kubernetes 上跑 Serverless 的冷启动与计费现实

把流量当扩容开关：Knative 在 Kubernetes 上跑 Serverless 的冷启动与计费现实

一个很常见的画面：大促前一晚，运维把订单服务的副本数手动拉到二十个，心里才踏实；平时流量只有峰值的十分之一，这二十个 Pod 里十五个在空转，CPU 曲线贴着地平线走，账单却照付不误。等到真正的突发洪峰撞上来，固定副本池要么被瞬间打满、请求排队超时，要么你已经把副本开到集群资源上限、再多也加不动。

问题不在 Kubernetes 不行，而在于扩缩容的依据放错了地方。副本数由人拍脑袋、由经验值、由一张静态的 HPA 阈值表决定，它和"此刻到底有多少真实请求在门口等着"是脱节的。Knative 的思路是把这个依据换掉：让真实请求本身成为扩容的开关。请求多，Pod 自动变多；请求归零，Pod 缩到零；中间的一切由并发指标驱动，而不是由一份写死的副本计划驱动。

这篇只讲一件事——在 Kubernetes 上用 Knative Serving 跑 Serverless 时，冷启动和计费到底是怎么发生的，哪些成本是真的省了、哪些只是账面好看，以及并发数这种看似不起眼的参数为什么能同时影响你的钱包和用户的延迟。我们只谈运行态的部署与成本，不展开事件总线和消息队列那套。

固定副本池为什么既贵又脆弱

固定副本池的本质，是用"常备军"去对冲"不确定性"。它的合理场景是流量曲线极其平稳、且对每一次毫秒级延迟都零容忍的业务，比如核心交易链路的同步写服务。但多数业务并不满足这个条件，于是常备军变成了养兵千日、用兵一时的奢侈。

脆弱性来自两个方向。第一是"养不起的冗余"：你按峰值预留，意味着低谷时段也在为空 Pod 付费，这笔钱买的是"万一来了能扛住"的安全感，不是真实算力。第二是"扛不住的峰值"：副本上限通常是手算出来的，一旦真实洪峰超过这个上限，Kubernetes 不会自动突破节点资源去救你，超出的请求只能在网关或应用层排队，最终表现为超时和 5xx。

更隐蔽的成本在节点层。固定副本池往往跑在一组常开的工作节点上，节点 7×24 计费，Pod 缩不缩根本不影响节点的账单。换句话说，把 Pod 副本从二十降到零，省下的只是那部分 Pod 占用的 vCPU 和内存额度——前提是节点池本身也是弹性计费的。如果节点是包月独享的，Pod 缩到零只是把资源空出来给别的负载，并不会让月底的账单变少。这一点是后面谈"缩到零到底省不省钱"的伏笔。

还有工程债。副本数写死在部署清单里，意味着每次流量规律变化都要改配置、走发布流程、等人审批。扩缩容本身变成了一个需要人工干预的运维动作，这和 Serverless 想要的"全自动贴合需求"背道而驰。Knative 要解决的正是这个：把扩缩依据从静态数字变成动态请求。

Knative Serving 的两个核心对象：Service 与 Revision

Knative Serving 在 Kubernetes 之上定义了一组 CRD，官方文档列出的核心对象有四个：Service、Route、Configuration、Revision。日常打交道最多的是 Service 和 Revision，理解这两个，基本就掌握了运行态的命脉。

Service 是面向用户的入口对象。你提交一个 Knative Service，它自动帮你创建并管理同名的 Route 和 Configuration，并且在每次更新时自动产生一个新的 Revision。换句话说，Service 把"路由、配置、版本快照"三件事打包成一个好用的外壳。你可以通过 spec.traffic 指定流量走最新 revision，还是钉在某一个固定 revision 上——这正是后面做蓝绿和灰度的基础。

Revision 是不可变的时点快照。每次 Configuration 发生变化（换镜像、改环境变量、调并发参数），Knative 都会生成一个新 Revision，它冻结了那一刻的代码与配置，且生成后不能修改。Revision 可以按需自动扩缩，也能被设定最小副本数常驻。这种设计的好处是回滚极其自然：把流量切回上一个 Revision 即可，不需要重新构建，因为旧快照还在。

Route 负责把网络端点映射到一或多个 Revision，并支持按比例切分流量（比如 90% 给 v1、10% 给 v2）；Configuration 维护代码加配置的期望状态，强调代码与配置的分离，贴合十二要素方法论。四个对象合在一起，Knative 把"部署一次"变成"持续产生可寻址的版本"，而这恰恰是 Serverless 容器和传统 Deployment 最大的分野之一。

需要提醒的是，Revision 不是无限保留的。不活跃 Revision 会按照可配置的周期被垃圾回收，长时间不用的版本快照会被清掉以节省 etcd 和控制面开销。所以在做长期灰度时，要确认保留策略不会在你回滚之前把旧 Revision 回收掉。

并发数（concurrency）怎么设，直接决定成本和延迟

Knative 的默认自动扩缩器叫 KPA（Knative Pod Autoscaler），它是请求驱动的，默认目标是每个 Pod 同时处理 100 个在途请求（通过 autoscaling.knative.dev/target 注解设置）。它用 60 秒的稳定窗口评估并发，另有 6 秒的 panic 窗口——当 panic 窗口测得的并发超过目标值两倍时，KPA 进入激进扩容模式，快速加 Pod。

这个 100 的默认值不是金科玉律，它直接在你的成本和延迟之间画了一条权衡线。把并发目标调高，比如设成 200，意味着单个 Pod 要同时扛更多请求才扩容，于是你需要更少的 Pod、花更少的钱，但每个请求要和其他请求共享同一个 Pod 的 CPU、内存和连接池，尾延迟（P99）会随之抬高。把并发目标调低，比如设成 10，Pod 会更早扩容、更分散地承接请求，延迟更稳，但 Pod 数量上去了，账单一同上去。

所以并发数不是一个"越大越好"或"越小越好"的参数，而是一个业务画像参数。CPU 密集、单请求耗时长的服务，适合低并发目标，否则一个慢请求会拖住同 Pod 的几十个请求；I/O 密集、单请求很快返回的服务，可以放心用高并发目标，把 Pod 数压下来省成本。很多团队一开始用默认值 100，结果长耗时接口把 Pod 占满、其他请求排队，表象像"容量不足"，根因其实是并发目标没按接口特性细分。

更进一步，Knative 允许在同一个 Service 的不同 Revision 上设置不同的并发目标，这给了你按版本做容量实验的空间。新版本上线时先用保守并发保稳定，验证后再放宽，这种细粒度是固定副本池很难低成本做到的。顺便一提，如果你更习惯按 CPU/内存扩缩，Knative 也支持切换到标准 HPA，但 HPA 路径不支持缩到零

除了目标并发，KPA 还有几个直接影响成本的注解值得在调参时一并考虑。autoscaling.knative.dev/max-scale 给副本数封顶，防止某个异常流量把集群资源打爆、连带拖垮同节点其他服务；autoscaling.knative.dev/min-scale 设定常驻下限，是冷启动敏感路径的保底手段。target-utilization-percentage 调节 KPA 在接近目标并发时就提前扩容的激进程度，值越低、扩容越早、延迟越稳、但 Pod 越多越贵。window 注解控制评估并发的窗口长度，窗口越短反应越快、却容易因瞬时抖动频繁扩缩，带来额外开销。这些参数组合在一起才是真正的成本旋钮，而不是只有一个数字。——这又把话题引到了下一节。

缩到零真的省钱吗，还是只省了账面

缩到零（scale-to-zero）是 Knative 最有吸引力的卖点，默认在空闲一段时间（scale-to-zero-grace-period，默认 30 秒）后把 Pod 副本降到零。从画面看，没人访问就不占 Pod，这当然比养着空 Pod 优雅。但"省不省钱"取决于你账单的计量维度。

如果你的 Kubernetes 节点是包月或包年独享的，缩到零只是把 Pod 占用的额度还给了节点，节点本身的费用一分不少。这时缩到零省的是"未来可调度空间"，不是当月的现金。只有当节点池本身也是弹性计费（比如用了集群自动扩缩、竞价实例、按量节点），多余的 Pod 缩掉后能真正触发节点回收或释放，缩到零才会反映到账单上。

另一层账是冷启动代价。Pod 缩到零后，下一个请求到来时要重新拉镜像、起进程、等应用就绪，这段延迟由 Activator 组件在请求侧缓冲（它把请求先接住、排队，等 Pod 起来再转发）。对于能容忍几百毫秒到几秒延迟的异步或后台类请求，这笔延迟换成本是划算的；但对于登录、支付确认、首屏 API 这类对冷启动零容忍的路径，缩到零反而可能把"省钱"变成"流失用户"，此时更该用 min-scale 保底常驻几个实例。

还有一个常被忽略的成本：控制面。即便所有业务 Pod 都缩到零，Knative 的 controller、autoscaler、activator、webhook 以及底层的 Kubernetes 控制组件仍在运行并持续计费。缩到零省的是数据面算力，省不掉平台底座。所以判断"该不该缩零"，正确的问法是：这个服务的请求是否稀疏到值得用冷启动延迟去换节点弹性？而不是简单地"能缩就缩"。

举一个不编具体数字也能看清的账：假设一个服务白天有稳定流量、深夜几乎无人访问。在固定副本池加包月节点的组合下，你深夜照样为那批空转 Pod 和常开节点付费，缩到零在这里毫无现金意义。若把节点换成按量弹性、并启用缩到零，深夜的算力支出会随请求归零而大幅回落，白天流量回来时集群自动扩容、Knative 再把 Pod 拉起——这时缩到零才真正转化为账单上的下降。反之，如果服务全天流量平稳，缩到零几乎永远不触发，它带来的只是每次冷启动的延迟风险，没有省钱收益。所以缩到零不是默认开启的万能开关，它是"流量有明显波峰波谷"这一前提下的工具。

冷启动压到什么程度才算可用，Java 和 Go 差多少

冷启动延迟通常来自三个阶段：镜像拉取（大镜像产生 I/O 瓶颈）、容器与应用初始化（依赖库、SDK 加载）、以及运行时优化（典型如 Java 的 JIT 编译）。把这三段压下去，冷启动才从"秒级不可接受"变成"毫秒级无感"。

语言选型的差距在这里被放大。公开实测里，未优化的 Java 应用冷启动常见在 5 到 10 秒区间，JVM 启动本身就可能吃掉 1 秒以上；而 Go 编译为原生机器码，启动时间普遍在 0.1 到 1 秒，有实测在 512MB 内存的函数环境里 Go 平均冷启动约 18 毫秒。内存占用上，Java 容器常需 100 到 500MB，Go 往往 20 到 100MB——同样规格的节点，Go 能塞下更多实例。

Java 也不是没办法。两条主流出路：一是用 GraalVM 把应用编译成原生镜像，消除 JVM 启动与 JIT 预热，实测原生镜像冷启动可压到约 48 毫秒的量级；二是镜像与运行时瘦身，用 distroless 或 alpine 基础镜像把体积从 1GB 降到 200MB 左右，配合多阶段构建和依赖分层缓存，拉取与初始化时间显著缩短。百度智能云的 Serverless 实践文章里给出过一组对比：未优化 Java 冷启动达 5–10 秒，优化后配合合理并发目标，P99 延迟可从 8 秒降到 1.2 秒。

所以"冷启动压到什么程度才算可用"没有统一答案，它取决于你的 SLA。面向内部批处理，几秒冷启动无所谓；面向 C 端首屏，几百毫秒已是上限。务实的做法是：能用 Go 就用 Go，省下的冷启动和内存直接变现为更低的副本数与更稳的尾延迟；必须用 Java 时，把 GraalVM 原生编译和镜像瘦身当作上线前置条件，而不是事后优化。另外，用 min-scale 常驻一两个实例，可以从根本上绕开冷启动，代价只是少量常驻成本——这又回到了并发与缩零的取舍。

和云函数、KEDA 事件驱动怎么选不重叠

很多人把 Knative、云函数、KEDA 当成竞品，其实它们的发力点不同，硬要比"谁更好"会选错工具。下面这张表把四种形态放在同一坐标系里看，差异会比文字更直观。

云函数是托管式的 FaaS，你只写函数、按调用次数和算力时长付费，接入云厂商的生态很顺，但语言受限、运行时受厂商约束，且天然带有厂商绑定。Knative 是跑在自有 Kubernetes 上的 Serverless 容器，语言无关、镜像可移植、可跨云与混合云部署，代价是要自己运维 K8s 与网关。两者定位的本质差异是：云函数把"运维"外包给厂商换便利，Knative 把"控制权"留在自己手里换灵活与可移植。

KEDA 和 Knative 更不是对手。KEDA 解决的是"根据事件源指标去扩缩普通 Kubernetes Deployment"——比如队列里积压了一万条消息，KEDA 把消费者副本拉起来消费完再缩回。它擅长事件洪峰、批处理、流处理。Knative Serving 擅长的是 HTTP/gRPC 请求驱动、带版本管理与缩到零的在线服务。实际架构里两者常并存：在线 API 用 Knative，背后消费 Kafka 的 worker 用 KEDA，各管一摊，互不打架。

把这三样放一起，选型就清晰了：要托管便利、轻量事件、能接受绑定，选云函数；要语言无关、可移植、自己掌控运行态，选 Knative；要按消息队列深度弹性消费，选 KEDA。它们解决的是不同维度的问题，硬凑成一个"二选一"是误读。

一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体机型、带宽与报价以官网实时信息或咨询确认为准。在对比自建 Knative 与托管云函数时，它其实是一个比选维度：当你决定把控制权留在自己手里、在自有或托管节点上跑 Knative，底层那批节点的稳定性、带宽质量和多线接入，直接决定了冷启动之外的基础网络延迟。

私有化部署 Knative 的真实门槛：网关与排队

Knative 开源免费，但"免费"指的是软件授权，不等于"零成本落地"。私有化部署的真实门槛集中在两处：对外暴露的网关，以及请求在低峰时的排队缓冲。

网关层是第一个门槛。Knative Serving 支持多种网络实现：Contour（基于 Envoy 的入口控制器）、Kourier（轻量、常与快速起步搭配）、Istio（你已经在跑服务网格时的自然选择），以及处于 beta 阶段的 Kubernetes Gateway API 实现（如 Envoy Gateway）。选哪个不是随便勾选：Istio 功能最全但运维最重，Kourier 最轻但能力有限，Contour 折中。v1.23 还加入了 IPv6 支持与代理协议透传等能力，说明网络层仍在快速演进，选型的长期维护成本要提前算进去。

排队与缓冲是第二个门槛，它藏在 Activator 里。当某个 Revision 缩到零、或所有 Pod 都在满负荷时，Activator 会先接住请求、缓冲在队列里，等扩出的 Pod 就绪再转发。这保证了请求不丢，但也意味着"用户感知到的延迟 = 排队等待 + 真实处理"。如果你的业务对尾延迟敏感，就必须认真设定最小副本数、并发目标与扩容速度，而不能把 Activator 的缓冲当成无限弹性。一旦排队时间超过网关或客户端超时，表象就是 504，根因却在容量配置。

除了这两个硬门槛，私有化还要补齐证书管理（自定义域名 HTTPS）、可观测性（指标、链路、日志）、以及和现有 CI/CD 的衔接。Knative 提供了 kn 命令行插件和 Operator 来简化安装升级，但生产环境仍建议从单集群小流量起步，先验证网关与扩缩行为，再逐步接管核心流量。这部分运维能力，恰恰是很多团队低估、最后又回头补的隐性成本。

可观测性尤其不能省。Knative Serving 原生暴露了与 Revision 绑定的指标：每个 Revision 的请求数、在途请求并发、请求时延分布，以及 Pod 实际副本数。把这些指标接进监控后，你才能回答"刚才那次延迟尖刺是并发目标设高了、还是冷启动拖的、还是 Activator 在排队"这类根因问题。没有这些数据的调参就是盲人摸象——昨天把并发调低延迟好了，今天流量结构一变又出问题，因为你改的是表象不是依据。另外，证书与自定义域名要提前规划：Knative 支持配置集群内路由与对外自定义域名，生产环境 HTTPS 和证书自动续期要在上线前接好，否则灰度切流时会卡在证书环节。

蓝绿与灰度在 Revision 上怎么自然发生

传统蓝绿和灰度要靠额外的网关规则、脚本或服务网格配置去拼，Knative 把它变成了 Revision 的内建能力。因为每个发布都会生成不可变的新 Revision，流量分配天然发生在 Revision 之间。

最朴素的灰度是比例切分：在 Service 的 spec.traffic 里写 90% 给 v1、10% 给 v2，两个 Revision 同时在线承接真实流量，出问题时把比例调回即可，不需要回滚发布。更细的玩法是用 tag 给某个 Revision 打一个独立访问入口（比如 hello-canary 这样的子域名），让内部或特定用户先打新版本，验证后再把主流量切过去。

蓝绿则更简单：保留旧 Revision 常驻、把 100% 流量指向新 Revision，一旦异常立刻把流量指回旧 Revision。因为 Revision 是不可变快照，回切是瞬时且确定的，不会引入"重新构建可能不一致"的风险。配合 Knative 的健康检查与就绪探针，新 Revision 没通过就绪前不会接流量，进一步降低灰度风险。

这种版本原生的流量治理能力，是 Knative 相比"裸 Deployment + HPA"的隐性优势。它让发布从"一次性的替换动作"变成"可观测、可回退、可比例的持续过程"，对需要频繁上线又怕出事的团队价值很高。需要注意的是，长时间并存的多个 Revision 会占用更多资源与 etcd 条目，所以保留策略和回收周期要和应用的上线节奏对齐。

落地前被反复追问的几个问题

下面是真实选型时最常被问到的几个问题，逐一给判断，不绕弯。

Knative 和云函数最大的使用差异在哪？

差异在"控制权与可移植性"。云函数是厂商托管的 FaaS，你只管函数代码，运行时、扩缩、网络都归厂商，按调用计费，代价是语言受限和厂商绑定。Knative 是你自己的 K8s 上的 Serverless 容器，语言无关、镜像可携、跨云部署，代价是你要自己运维 Kubernetes 与网关，软件本身免费但底座要成本。

冷启动怎么压，Go 和 Java 差多少？

压冷启动三板斧：瘦身镜像（distroless / alpine，体积从 GB 级降到百 MB 级）、预热或 min-scale 常驻、以及语言与编译优化。差距上，Go 原生二进制冷启动普遍 0.1–1 秒、实测有到 18 毫秒的量级，Java 未优化常 5–10 秒，用 GraalVM 原生编译可压到约 48 毫秒。结论：能选 Go 优先，必须 Java 就把原生编译和镜像瘦身当上线前置。

并发数设多少，成本和延迟怎么权衡？

默认 KPA 目标是每 Pod 100 个在途请求。调高省 Pod、降成本但抬尾延迟；调低延迟更稳但 Pod 更多、账单更厚。CPU 密集或长耗时接口用低并发，I/O 密集且快的接口用高并发。不要一个默认值套全部接口。

缩到零真的划算吗，哪些场景反而不该缩零？

只有节点池也是弹性计费时，缩到零才反映到现金账单；包月节点缩零只是腾出调度空间。对冷启动零容忍的路径（登录、支付、首屏 API）不该缩零，改用 min-scale 保底。稀疏、可容忍延迟的异步任务，才适合缩零换弹性。

Knative 和 KEDA 怎么分工不打架？

Knative Serving 管 HTTP/gRPC 请求驱动的在线服务（带版本、缩零）；KEDA 管按事件源指标扩缩的普通 Deployment（队列、流、批处理）。两者常并存于同一集群，各管一摊，不存在二选一。

流量灰度在 Revision 上怎么自然做？

每次发布生成新 Revision，用 Service 的 spec.traffic 按比例切分（如 90/10），或用 tag 给新版本单独入口。异常时把流量指回旧 Revision 即可瞬时回退，因为快照不可变。

私有化部署门槛高在哪，网关怎么选？

门槛在网关与排队缓冲。网关可选 Contour / Kourier / Istio / Gateway API（beta），按运维能力与功能需求取舍；排队由 Activator 负责，但要警惕缓冲时间超过客户端超时造成的 504。生产建议从小流量单集群起步。

按请求计费在自建环境怎么落地？

Knative 本身不向你收"每请求"费用，它开源免费。自建环境的"按请求计费"要靠底层资源计量去近似：弹性节点（竞价/按量）+ 缩到零，让算力支出贴合真实流量；若节点包月，则只能内部做成本分摊，无法真正按用量对外计费。

一万网络能给 Serverless 部署接什么：从选型到落地

回到一个务实的问题：决定在自有或托管 Kubernetes 上跑 Knative 之后，底层的算力与网络从哪来？这正是 IDC 服务商能接上的位置——Knative 解决的是运行态的扩缩与版本，但它跑的每一台节点、每一条出口带宽，都是实打实的基础设施。

从选型阶段看，跑 Knative 的节点建议具备：稳定的多线 BGP 出口（降低跨运营商访问的基线延迟，这部分延迟和冷启动是叠加关系，冷启动压得再低，出口抖一下用户照样感知到）、可弹性扩容的工作节点池（否则缩到零省不掉现金）、以及足够的控制面余量（Knative 的 autoscaler 与 activator 在洪峰时自身也要算力）。这些不是 Knative 的功能，却是它能否"省钱又稳"的前提。

一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体机型、带宽与报价以官网实时信息或咨询确认为准。对正在评估把在线服务迁到 Knative 的团队来说，它意味着底层节点、机柜与带宽可以一体化谈下、统一交付，而不必在多个供应商之间拼接网络与算力，从而把运行态优化的重心放在并发目标、缩零策略与镜像瘦身上，而不是耗费在底层对接的扯皮里。

数据来源

Knative 官方文档（knative.dev，Serving 章节）：Knative Serving 对象模型，Service / Route / Configuration / Revision 四个核心 CRD 的定义与交互关系，KPA 默认并发目标、稳定窗口与 panic 窗口、scale-to-zero-grace-period 等参数说明。

Knative 官方博客（knative.dev/blog/releases）：Announcing Knative v1.23 Release，发布于 2026-07-29，记录 Serving 1.23 的新增能力（临时卷、IPv6 自动扩缩、启动探针校验）及最低支持 Kubernetes 1.34。

knative/serving GitHub Releases：v1.23.0 版本资产与发布时间（2026-07-29），以及 v1.22、v1.21 等历史版本线。

endoflife.date/knative：Knative 各版本发布与支持周期，标注 1.23 为当前受支持版本、最低支持 Kubernetes 1.34。

百度智能云技术文章《Serverless 深度解析：Knative 部署、冷启动优化与微服务融合实践》：给出未优化 Java 冷启动 5–10 秒、优化后 P99 从 8 秒降至 1.2 秒等实测区间，以及镜像瘦身、GraalVM 原生编译等优化手段。

DevPress（CSDN）容器并发编程对比文章：对比 Java 与 Go 在容器内的启动时间（Java 5–15 秒、Go 0.1–1 秒）与内存占用区间。

datasea.cn Go 与 Java 冷启动实测：在 512MB 内存函数环境下，Go 平均约 18 毫秒、Java GraalVM 原生约 48 毫秒、Java JVM 约 1100 毫秒的启动数据。

ToolRadar、The Art of CTO 等 2026 年对比资料：Knative 与 Google Cloud Functions 的定位差异（容器编排 / 托管 FaaS）、语言支持、学习与运维曲线、计费模式（云函数按调用次数、Knative 开源免费但需自承底座）。

一万网络能给 Serverless 部署接什么：下单前要确认的清单

一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体机型、带宽与报价以官网实时信息或咨询确认为准。把在线服务迁到 Knative 之前，用下面这份清单逐项确认，能少踩很多坑。

1. 节点计费模式：确认工作节点是包月独享还是按量/竞价弹性；只有弹性节点，缩到零才真正省现金，否则只是腾出调度空间。

2. 出口网络质量：确认是否具备 BGP 多线接入，跨运营商基线延迟会直接叠加在冷启动之上，影响最终用户体验。

3. 最低支持版本：Knative v1.23 要求 Kubernetes 1.34 起，确认你计划使用的集群版本在受支持范围内，避免踩到已结束支持的旧版。

4. 网关选型：在 Contour / Kourier / Istio / Gateway API 之间按运维能力取舍，不要盲目上最重的 Istio，也不要为省事牺牲必要的流量治理能力。

5. 并发目标设定：按接口特性分档设 autoscaling.knative.dev/target，长耗时与 CPU 密集用低值，I/O 密集用高值，避免一个默认值套全部。

6. 缩零策略：对冷启动零容忍的路径（登录、支付、首屏）用 min-scale 保底常驻，仅对稀疏异步任务启用缩到零。

7. 语言与镜像：能用 Go 优先；必须 Java 时把 GraalVM 原生编译与 distroless 镜像瘦身列为上线前置，控制冷启动与内存占用。

8. 超时与排队：确认网关、客户端与 Activator 缓冲时间的层级关系，避免排队等待超过超时引发 504。

9. Revision 保留：配置不活跃 Revision 的回收周期，保证灰度回退时旧快照还在，不会被提前清掉。

10. 可观测性：补齐指标、链路与日志，Knative 的扩缩行为必须用数据验证，而不是凭感觉调参。