Knative v1.0 版本发布深度解读：Serving、Eventing、扩展组件与 Operator 的里程碑更新-北京尧图网络

文档教程云原生【免费下载链接】docsUser documentation for Knative components.项目地址https://gitcode.com/gh_mirrors/docs1/docs点击查看免费下载2021 年 11 月 2 日Knative 正式发布 v1.0 版本标志着这个构建在 Kubernetes 之上的开源 Serverless 平台在核心组件层面进入 GAGeneral Availability状态。本次发布覆盖 Knative Serving、Knative Eventing、Apache Kafka Broker、RabbitMQ Broker/Source、kn命令行工具以及 Knative Operator 等多个组件。本文以仓库中的 v1.0 release 发布公告为主体结合当前仓库中对应的配置文档与安装指南逐项解读本次发布的关键变更、破坏性迁移步骤及其背后的设计意图帮助你评估升级影响并完成落地配置。版本发布总览与版本标记约定v1.0 版本在版本管理上引入了一个重要的约定调整所有组件仓库统一使用knative-v1.0.0作为版本标签包括 Serving、Eventing、Eventing 扩展、knCLI 与 Operator对于通过 Go 库方式引用 Knative 代码的用户Go 模块版本号则使用v0.27。这意味着当你以标签方式部署或追踪发布时使用knative-v1.0.0而在go.mod中引入 Knative 依赖时使用v0.27.x系列版本。这一双轨版本约定从 v1.0 起成为 Knative 各组件仓库的统一规范理解它可以避免在升级时混淆发布标签与 Go 库版本。Highlights 亮点速览本次发布的三个全局性亮点如下所有组件版本统一标记为knative-v1.0.0Go 库使用v0.27per-namespace 通配符证书供给器wildcard certificate provisioner已集成进基础控制器不再是独立安装的组件默认情况下Prefer: reply请求头会被转发给 Broker Triggers 的订阅者subscriber这是 Eventing 在回复语义reply semantics上的一次行为统一。以下分组件展开说明。Knative Serving v1.0证书管理重构与并发监控新能力破坏性变更per-namespace 通配符证书供给集成进主控制器Serving 中最值得关注的变更是将原本独立部署的per-namespace 通配符证书供给器serving-nscert合并进 Knative Serving 的基础控制器。合并之后这一能力由config-networkConfigMap 中的namespace-wildcard-cert-selector字段控制该字段使用 Kubernetes 标准的 LabelSelector 语法让你可以选择哪些命名空间应当被自动供给通配符证书。从旧版本迁移的步骤将namespace-wildcard-cert-selector设置为以下值以实现为未显式禁用通配符证书的命名空间供给证书matchExpressions: - key: networking.knative.dev/disableWildcardCert operator: NotIn values: [true]删除上一版本中由serving-nscert.yaml资源定义的 Deployment、Service 与 ClusterRole对应 Pull Request #12174 的变更。当前仓库的外部域名加密配置文档对namespace-wildcard-cert-selector的用法给出了更完整的说明取值空字符串禁用该功能这是默认行为取值{}空对象为所有命名空间启用通配符证书供给使用matchExpressions按标签选择命名空间实现选择性启用或选择性退出opt-outnamespace-wildcard-cert-selector: |- matchExpressions: - key: networking.knative.dev/disableWildcardCert operator: NotIn values: [true]上面的配置会选择所有标签值不在集合true中的命名空间即未显式禁用证书供给的命名空间。也可以直接利用 Kubernetes 自带标签按命名空间名称选择namespace-wildcard-cert-selector: |- matchExpressions: - key: kubernetes.io/metadata.name operator: In values: [my-namespace, my-other-namespace]在线调整配置的命令可自行调整 label selector 内容kubectl patch --namespace knative-serving configmap config-network -p {data: {namespace-wildcard-cert-selector: {\matchExpressions\: [{\key\:\networking.knative.dev/disableWildcardCert\, \operator\: \NotIn\, \values\:[\true\]}]}}}配置修改后需要重启 Knative Serving controller 以启动 cert-manager 集成kubectl rollout restart deploy/controller -n knative-serving需要注意的是每个命名空间一张通配符证书的模式只支持 DNS-01 challenge无法与 HTTP-01 challenge 配合使用启用后Kubernetes 服务的外部域名例如application.example.com即可获得自动签发与续期的 HTTPS 证书。新特性concurrencyStateEndpoint 实验功能Serving 引入了一个新的实验性功能concurrencyStateEndpoint当某个容器的并发度从 0 变为非 0或从非 0 变为 0时可以通过一个 webhook 端点获知该状态变化。这一能力来自 #11802、#12162 与 #11917 等系列改动为后续实现更细粒度的零并发感知调度与生命周期管理铺路。需要说明的是发布公告明确将其标记为experimental生产环境使用前应关注后续版本的能力收敛情况。新特性activator 与 mesh compatibility mode 的协同当config-network中的网格兼容模式mesh compatibility mode未设置为auto时activator 会尊重 Kubernetes 的 readiness 状态并且在 Kubernetes 就绪探测传播速度比 activator 自身探测更快时避免重复探测对应 Pull Request #12086。这一变更的背景可以从 HTTP 请求流文档中理解activator 是 Knative Serving 集群级的共享组件在流量低或为零时充当请求的缓冲队列并向 autoscaler 发出扩容信号在高流量阶段请求则绕过 activator 直达 Revision 的 Pod。此前 activator 会自行对 Pod 做就绪探测可能与 Kubelet 的 readiness probe 产生重复或冲突。v1.0 之后在非auto模式下 activator 直接采纳 Kubernetes 的 readiness 判定减少了探测冗余也避免了两套探测机制信号不一致导致的请求转发抖动。Bug 修复TLS 证书请求时机Serving 修复了一个 TLS 证书请求时机问题此前在域名归属domain-ownership尚未建立时就会请求 TLS 证书可能导致证书与域名绑定不一致或请求失败对应 Pull Request #12080。v1.0 调整了请求顺序确保先确认域名归属再发起证书申请。Knative Eventing v1.0交付语义收紧与调度器换代破坏性变更strict-subscriber 特性开关Eventing 引入了一个影响 Subscription API 的破坏性变更。当strict-subscriber特性开关被启用时Subscription 的spec.subscriber成为必填字段此前仅提供spec.reply而不设置spec.subscriber的 Subscription 将不再被接受。这一变更的目的是对齐 eventing spec 的语义并改善使用 Subscription 时的用户体验。官方计划在1.1 版本中默认启用该特性开关因此如果你的 Subscription 目前只配置了spec.reply而缺少spec.subscriber需要在升级到 1.1 之前补齐订阅者定义以避免兼容性中断。对应 Pull Request #5762。从当前仓库的 Subscription 文档可以看到规范的 Subscription 对象包含channel事件来源、subscriber必填的事件接收方、可选的reply订阅者回复事件的目的地与delivery失败处理配置apiVersion: messaging.knative.dev/v1 kind: Subscription metadata: name: subscription-name namespace: default spec: channel: apiVersion: messaging.knative.dev/v1 kind: Channel name: channel-name delivery: deadLetterSink: ref: apiVersion: serving.knative.dev/v1 kind: Service name: service-name reply: ref: apiVersion: messaging.knative.dev/v1 kind: InMemoryChannel name: service-name subscriber: ref: apiVersion: serving.knative.dev/v1 kind: Service name: service-name新特性Prefer: reply 请求头转发Eventing 在回复语义上做了两项行为统一Broker Triggers 的订阅者默认会收到Prefer: reply请求头对应 Pull Request #5773当 Subscription 设置了spec.reply时发送给 Subscription 订阅者的请求也会带上Prefer: reply请求头对应 Pull Request #5764。这两个特性合在一起意味着只要事件流中存在回复路径reply订阅者就能通过Prefer: reply头感知到本请求期待一个回复事件从而在事件网格中形成统一的回复协商机制。v1.0 中该行为默认开启这是 Eventing 在事件回复语义上的一次重要收敛。新特性deadLetterSink 命名空间默认值与 Channel 状态新增 deadLetterSinkUriEventing 对死信dead letter处理语义做了多处增强spec.delivery.deadLetterSink.ref.namespace的默认值对于 Broker、Trigger、Channel 和 Subscription如果该字段未显式指定将默认使用metadata.namespace即资源自身所在的命名空间减少了跨命名空间引用的配置负担对应 Pull Request #5748Channel 状态新增deadLetterSinkUriChannel 会将解析后的死信目标 URI 写入status字段deadLetterChannel字段被废弃官方给出1 年的过渡期后移除对应 Pull Request #5746。结合仓库中的事件投递失败处理文档delivery配置的完整语义如下deadLetterSink指定事件无法投递给订阅者时转发的目标可以是 Knative Service、Kubernetes Service 等任意符合 sink 契约的 Addressable 对象或一个 URIretry事件进入死信队列前的最大重试次数注意首次投递不计入 retry 次数因此总投递次数为retry 1backoffDelay失败后重试前等待的时间使用 ISO 8601 格式例如PT1S表示 1 秒backoffPolicy退避策略取linear每次重试间隔线性递增或exponential退避延迟为backoffDelay * 2^重试次数。新特性delivery 字段强制校验Channel 与 Subscription 将强制校验delivery字段对应 Pull Request #5777。此前delivery配置的合法性与取值范围约束较松v1.0 起会在准入阶段对死信目标、重试次数、退避策略等参数进行严格校验提前拦截非法配置避免运行时才暴露问题。新特性新一代多租户 Scheduler 与 DeschedulerEventing 引入下一代多租户 Scheduler 与 Descheduler对应 Pull Request #5818其核心设计是通过plugin 接口指定 Scheduler profileprofile 由 predicates 与 priorities 组成分别对 Pod 执行过滤filtering与打分scoring从而计算最优的 vreplica 放置方案当 autoscaler 新增 Pod 时Scheduler 会对已放置的 vreplicas 与新增 vreplicas 一起执行再平衡rebalancing当 vreplicas 需要缩容并移除放置时必须安装 Descheduler profile才能执行清理。这一机制为 Eventing 中多租户、大规模事件处理的资源调度提供了更灵活、更可扩展的基础设施也是后续 Kafka 数据平面等场景横向扩展能力的支撑。新特性Kreference mapping resolver 模板新增 UIDEventing 在Kreference 映射解析器mapping resolver模板字段中新增了UID对应 Pull Request #5810使得事件路由相关的引用解析可以携带资源的 UID 信息为引用追踪与审计提供更精确的标识。Bug 修复Parallel 与 Sequence 更新时泄漏资源Eventing 修复了两处资源泄漏问题Parallel 更新时泄漏资源对应 Pull Request #5775Sequence 更新时泄漏资源对应 Pull Request #5718。值得注意的是修复生效有一个前提所提供 Channel 的 ClusterRole 必须带有duck.knative.dev/channelable标签并且包含delete动词。如果你的自定义 Channel 部署尚未授予该权限需要先补齐 RBAC 规则否则上述修复无法对相应 Channel 生效。Eventing 扩展组件 v1.0Apache Kafka BrokerRBAC 资源重命名与 deadLetterSinkUriKnative Eventing 的 Kafka Broker 扩展eventing-kafka-broker在 v1.0 中对数据平面相关 RBAC 资源做了系统性重命名对应 Pull Request #1315| 组件 | 旧名称 | 新名称 | | - | - | - | | KafkaBroker ClusterRole |knative-kafka-data-plane|knative-kafka-broker-data-plane| | KafkaBroker ServiceAccount |knative-kafka-data-plane|knative-kafka-broker-data-plane| | KafkaBroker ClusterRoleBinding |knative-kafka-data-plane|knative-kafka-broker-data-plane| | KafkaSink ClusterRole |knative-kafka-data-plane|knative-kafka-sink-data-plane| | KafkaSink ServiceAccount |knative-kafka-data-plane|knative-kafka-sink-data-plane| | KafkaSink ClusterRoleBinding |knative-kafka-data-plane|knative-kafka-sink-data-plane|如果你在集群中按旧名称配置了额外的 RBAC 策略或监控规则升级后需要同步更新这些引用。同时Kafka Broker 扩展将Broker 与 Trigger 的status.deadLetterSinkUri设置为spec.delivery.deadLetterSink解析后的 URI对应 Pull Request #1349。这与 Eventing 核心的 deadLetterSinkUri 能力保持一致让 Kafka Broker 的触发器和 Broker 也能通过状态字段暴露解析后的死信地址。Kafka Broker 的典型配置方式可参考仓库中的 Knative Broker for Apache Kafka 文档在 Broker 上通过eventing.knative.dev/broker.class: Kafka注解指定 Broker 类通过spec.config引用包含default.topic.partitions、default.topic.replication.factor、bootstrap.servers等参数的 ConfigMap并可选地在spec.delivery.deadLetterSink中配置死信目标apiVersion: eventing.knative.dev/v1 kind: Broker metadata: annotations: eventing.knative.dev/broker.class: Kafka name: default namespace: default spec: config: apiVersion: v1 kind: ConfigMap name: kafka-broker-config namespace: knative-eventing delivery: deadLetterSink: ref: apiVersion: serving.knative.dev/v1 kind: Service name: dlq-serviceRabbitMQ Broker 与 Source并行消费与过滤器不可变RabbitMQ Broker 与 Source 扩展eventing-rabbitmq在 v1.0 引入以下变化Trigger 默认并行发送事件Trigger 现在会并行地向订阅者发送事件in-flight 消息数量默认为 10可通过注解rabbitmq.eventing.knative.dev/prefetchCount调整对应 Pull Request #418 描述的并行消费模型一致——后者通过rabbitmq.eventing.knative.dev/parallelism注解设置 Trigger 的 worker 数量来提升吞吐两者都反映了 RabbitMQ 触发器的并行投递能力。Trigger 过滤器强制不可变由于底层的 RabbitMQ binding 本身不可变Trigger 的过滤器filters在创建后不允许修改必须重建 Trigger对应 Pull Request #468。Bug 修复Broker 在未定义死信 sink 时不再为死信事件创建队列对应 Pull Request #453避免了无意义的资源占用。kn CLI v1.0参数体系整理kn命令行工具在 v1.0 中完成了一轮参数清理与能力增强如果你的脚本中使用了旧参数升级前需要逐一核对。移除的已废弃参数--lookup-path对应 Pull Request #1506--min-scale与--max-scale对应 Pull Request #1498--limits-cpu与--limits-memory同上。重命名与新能力--extra-containers重命名为--containers对应 Pull Request #1499废弃--concurrency-target与--concurrency-utilization分别由--scale-target与--scale-utilization取代对应 Pull Request #1490废弃--autoscale-window由--scale-window取代对应 Pull Request #1489当指定 N-1 个 revision 时自动计算流量切分traffic split对应 Pull Request #1483减少了手动分配流量的出错概率当配置文件不存在时自动创建默认配置对应 Pull Request #1472开箱即用改进缺失 API 时的错误提示信息对应 Pull Request #1497。Bug 修复修复了domain describe引用中显示的 kind 类型不正确的问题对应 Pull Request #1477。knCLI 的安装方式可参考仓库中的安装 CLI 工具文档其中同时介绍了kubectl、kn以及kn operator插件的安装与验证方法。Knative Operator v1.0高可用与调度增强Knative Operator 在 v1.0 中完成了面向生产环境的重要强化主要变化包括将高可用HA应用到 Operator 管理的所有 Deployment对应 Pull Request #749并从 HA 缩容清单中移除了 pingsource-mt-adapter#788与 pingsource#740当高可用配置的副本数更大时同步调整 HPA 的maxReplicas对应 Pull Request #748避免 HPA 上限与 HA 副本数冲突新增spec.deployments.affinity支持对应 Pull Request #777允许为 Operator 管理的 Deployment 配置节点亲和性新增spec.deployments.tolerations支持对应 Pull Request #747允许为 Deployment 配置污点容忍为 Knative 资源准备app.kubernetes.io/version标签对应 Pull Request #738移除已废弃的enabledComponents字段设置对应 Pull Request #735加入 COC 与贡献文档#790、改用 codegen-library 脚本#734、移除 eventing 的 heartbeat#792等维护性更新。Bug 修复修复了安装自定义spec.manifests时的错误问题对应 Pull Request #750。Operator 管理的 Serving 配置方式可参考仓库中的 Knative Serving Operator 自定义资源配置文档其中展示了通过spec.version指定组件版本、通过spec.manifests覆盖模式或spec.additionalManifests追加模式定制安装清单等能力apiVersion: operator.knative.dev/v1beta1 kind: KnativeServing metadata: name: knative-serving namespace: knative-serving spec: version: 1.20升级建议与落地参考综合 v1.0 的变更升级到该版本前建议按以下清单核对Serving 证书体系如果此前独立部署了serving-nscert控制器需要按上文迁移步骤将namespace-wildcard-cert-selector配置写入config-network并删除旧的 Deployment、Service 与 ClusterRole如果此前未使用通配符证书则默认行为不受影响。Eventing 的 Subscription检查现有 Subscription 是否都设置了spec.subscriber为 1.1 版本默认启用strict-subscriber做准备。Eventing 的 Channel/Subscription确认delivery配置符合新的校验规则并将deadLetterChannel迁移到deadLetterSink1 年过渡期内完成。自定义 Channel 的 RBAC确保 Channel 对应的 ClusterRole 带有duck.knative.dev/channelable标签且包含delete动词以受益于 Parallel/Sequence 资源泄漏修复。Kafka/RabbitMQ 扩展更新 Kafka 数据平面 RBAC 资源名称引用如需调整 RabbitMQ 触发器的并行投递能力可设置rabbitmq.eventing.knative.dev/prefetchCount注解。kn CLI 脚本将废弃参数--lookup-path、--min-scale、--max-scale、--limits-cpu、--limits-memory替换为对应新参数--scale-target、--scale-utilization、--scale-window等。如果你希望通过 Operator 方式管理版本可以结合 KnativeServing CR 配置文档的spec.version字段完成指定版本的安装与升级若使用 YAML 直接安装可参考 YAML 安装 Serving 文档中的安装流程与硬件要求单节点至少 6 CPU、6 GB 内存、30 GB 磁盘。安装完成后可通过kubectl get pods -n knative-serving验证各组件处于Running状态。结语Knative v1.0 是一次兼具里程碑与承前启后意义的发布它统一了各组件仓库的版本标记将 Serving 的通配符证书供给能力收编进主控制器收紧了 Eventing 的 Subscription 与 delivery 语义替换了多租户调度器内核并对knCLI 的参数体系与 Operator 的高可用、亲和性、容忍度等调度能力做了系统性完善。对于已经运行 Knative 的团队本次发布的破坏性变更主要集中在证书供给迁移与 Subscription 校验收紧两处其余多为能力增强与行为统一。理解这些变更背后的设计意图将帮助你更平稳地完成升级并为后续 1.1 版本例如strict-subscriber的默认启用做好准备。赞分享文档教程云原生【免费下载链接】docsUser documentation for Knative components.项目地址https://gitcode.com/gh_mirrors/docs1/docs点击查看免费下载相关推荐Knative v1.7 版本发布深度解读Serving 自动伸缩、Eventing 特性与网络扩展更新全览Knative v1.7 版本发布深度解读Serving 自动伸缩、Eventing 特性与网络扩展更新全览 2022 年 8 月 25 日Knative文档教程云原生Knative 1.6 版本发布深度解析Serving、Eventing、kn CLI 与 Operator 的更新要点与配置实践Knative 1.6 版本发布深度解析Serving、Eventing、kn CLI 与 Operator 的更新要点与配置实践 Knative 1.6 是文档教程云原生Knative 1.5 版本发布深度解析Serving、Eventing 与生态扩展核心特性详解Knative 1.5 版本发布深度解析Serving、Eventing 与生态扩展核心特性详解 Knative 1.5 是 Knative 项目在 2022文档教程云原生创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

Knative v1.0 版本发布深度解读：Serving、Eventing、扩展组件与 Operator 的里程碑更新

相关推荐

sebastian/version 版本演进全解析：从 ChangeLog 看 Git 托管 PHP 项目的版本号管理库

机械臂建模+双臂蒙特卡洛法工作空间、笛卡尔空间、运动学圆弧轨迹（Matlab代码实现）

用C#实现EtherCAT主站：架构、PDO映射与DC同步实战

更多资讯

AR人脸数据集稀疏表示实验：BMP读取、数据划分与SRC配置指南

Scrum敏捷开发框架：角色分工与团队协作实践

uni-app项目模板搭建指南：从目录结构到请求封装与多端调试

OpenCode高级用法：斜杠命令、Agent模式与上下文管理实战

CS229机器学习课程资料包：讲义、作业与讲解的完整使用指南

微网系统碳交易优化模型设计与Matlab实现

今日更新

小波包能量谱原理与MATLAB实现：从频带分解到故障特征提取

基于LSTM的网易云音乐评论情感分析：数据清洗与模型调优实战

Alpha-Beta剪枝与极大极小值算法：博弈树搜索原理与实战优化

本周精选

交通拥堵预测毕设：基于Python+LSTM的车辆流量预测系统全流程解析

MATLAB/Simulink搭建10机39节点电力系统暂态稳定仿真实战

无人机航拍三维重建全流程：从SfM到网格生成的避坑指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？