文档教程云原生【免费下载链接】docsUser documentation for Knative components.项目地址https://gitcode.com/gh_mirrors/docs1/docs点击查看免费下载导读在 KnativeServing 与 Eventing中ConfigMap 是管理员对控制器全局行为进行配置的主要途径几乎所有以config-前缀命名的 ConfigMap 都承载着平台级默认值与行为开关。本文以 editing-configmaps.md 为核心骨架深入讲解 Knative ConfigMap 的_example键与knative.dev/example-checksum校验机制给出正确的修改姿势、验证手段、存储与版本化管理GitOps建议并说明在使用 Knative Operator 时如何避免配置被覆盖。读完本文你将能够安全、可回滚地管理集群上的 Knative 配置。一、ConfigMap 在 Knative 中的定位Knative 遵循 Kubernetes 的声明式配置模型管理员主要通过两种方式下发集群级配置直接编辑 YAML 清单并用kubectl应用或修改 Knative 自带的 ConfigMap。其中 ConfigMap 负责平台级行为的调优绝大多数 Knative ConfigMap 位于knative-serving与knative-eventing命名空间中其设置对所有命名空间中的相关 Knative 组件生效。从 admin-overview.md 的配置清单可以看出Knative 的配置面覆盖 Serving 与 Eventing 两大组件Serving 侧config-defaults默认资源值、config-deployment支撑服务的 Deployment 资源配置、config-domain域名、config-gc垃圾回收与保留时间、config-network滚动时长、加密等、config-certmanager证书签发、config-istioIngress 网关。Eventing 侧config-br-defaultsBroker 默认类与默认 Channel、config-kafka-featuresKafka 交互特性、default-ch-webhook/kafka-channelChannel 默认值、config-ping-defaultsPingSource 默认值、config-sugarSugar Controller 行为。这些 ConfigMap 均由 Knative 安装时创建管理员可以像编辑普通 Kubernetes ConfigMap 一样用kubectl修改它们Knative 控制器会在应用后的数秒内处理新值包括回滚到旧值。二、_example键内置的配置文档与校验锚点2.1_example是什么Knative 安装的所有 ConfigMap 中都包含一个名为_example的键它本身不参与任何行为控制其值是一段注释性质的说明文字作用是向执行kubectl edit的用户展示该 ConfigMap 内所有已知配置键的用途与示例。也就是说它是随 ConfigMap 一起分发、供管理员查阅的活文档。2.2 误改_example的后果与 webhook 拦截如果管理员没有新建配置键而是直接修改了_example键的内容改动不会影响集群配置——因为_example根本不被控制器读取。为避免这种改了没反应的困惑Knative 的 webhook 会对这类编辑进行拦截并告警。其判定机制基于校验和Knative 在 ConfigMap 上维护一个knative.dev/example-checksum注解值为_example键内容的哈希。当 webhook 发现 ConfigMap 中_example键的实际内容与注解中的校验和不再一致时就会拒绝该更新并提示用户补丁无法生效。需要注意如果knative.dev/example-checksum注解缺失或为空webhook 不会生成该警告因此管理员不能修改_example键的内容但可以整体删除_example键或删除example-checksum注解本身。从仓库中的真实 ConfigMap 可以印证这一点。例如 config-deployment 的元数据中就带knative.dev/example-checksum: fa67b403注解而 editing-configmaps.md 给出了config-defaults的示例片段其注解值为5b64ff5c。2.3 一个带校验和的完整 ConfigMap 结构config-defaults是 Serving 中用途最广的 ConfigMap 之一其头部结构如下第 11 行为校验和注解apiVersion: v1 kind: ConfigMap metadata: name: config-defaults namespace: knative-serving labels: app.kubernetes.io/name: knative-serving app.kubernetes.io/component: controller app.kubernetes.io/version: devel annotations: knative.dev/example-checksum: 5b64ff5c data: _example: | ################################ # # # EXAMPLE CONFIGURATION # # # ################################ # This block is not actually functional configuration, # but serves to illustrate the available configuration # options and document them in a way that is accessible # to users that kubectl edit this config map. #注意data._example区块只是示例文档真正生效的键是data下并列的其它键。以config-defaults的实际默认值为例参见 config-defaults.mddata: revision-timeout-seconds: 300 max-revision-timeout-seconds: 600 revision-response-start-timeout-seconds: 300 revision-idle-timeout-seconds: 0 # infinite revision-cpu-request: 400m revision-memory-request: 100M revision-ephemeral-storage-request: 500M revision-cpu-limit: 1000m revision-memory-limit: 200M revision-ephemeral-storage-limit: 750M container-name-template: user-container container-concurrency: 0 container-concurrency-max-limit: 1000 allow-container-concurrency-zero: true enable-service-links: false这些键各自控制 Revision 的默认超时、CPU/内存/临时存储请求与限制、容器并发度等修改时必须新增或修改这些真实键而不是动_example。三、如何正确修改 Knative ConfigMap3.1 基本操作流程以修改 Serving 的默认域名为例完整流程见 using-a-custom-domain.md打开config-domainConfigMap 进行编辑kubectl edit configmap config-domain -n knative-serving在data下新增或替换配置键如将knative.dev设为所有 Route 的域名apiVersion: v1 data: knative.dev: _example: | ... kind: ConfigMap保存退出。若已有存量部署Knative 会自动调和reconcile该 ConfigMap 的变更并自动更新所有已部署 Service 与 Route 的主机名无需手动逐个修改。验证生效kubectl get route route-name --output jsonpath{.status.url}观察 Route 的 URL 是否已切换到新域名。Eventing 侧的修改方式完全一致例如调整 PingSource 的事件负载上限参见 sources-configuration.mdkubectl edit cm config-ping-defaults -n knative-eventing对应的data键为data-max-size单位字节-1表示不限制它控制 PingSource 写入 CloudEvents 的最大数据量。3.2 修改时务必避开_example正确姿势是在data下新增自己的键例如data: revision-timeout-seconds: 300 # 新增/修改真实键 # _example 保持原样不要编辑如果误改了_examplewebhook 会因校验和失配而拒绝补丁此时应恢复_example内容或按前述规则删除_example键 /example-checksum注解。四、最佳实践一应用前的验证与测试Knative 控制器在 ConfigMap 应用后的几秒内就会消费新值包括回滚到旧值因此改动传播速度快但也意味着错误配置会很快影响到运行中的服务。建议遵循以下实践语法与内容校验在应用前使用kubeval之类的工具校验 ConfigMap 的语法与内容或直接使用 Kubernetes 的服务端试运行能力kubectl apply --dry-runserver -f configmap.yaml--dry-runserver会由 API server 执行校验逻辑但不真正持久化能在不改动集群的前提下发现格式错误。先在预发布环境测试将 ConfigMap 变更先在 staging 环境应用确认与当前应用版本兼容后再上生产避免因配置项在版本间变更而导致线上故障。五、最佳实践二存储与版本化策略ConfigMap 的管理模式取决于权威来源放在哪里5.1 以集群为权威导出备份到 Git如果直接通过kubectl edit管理 ConfigMap集群是权威来源那么需要定期将配置导出并提交到 Git 作为恢复手段kubectl get configmap -o yaml建议把导出的 YAML 提交到版本库并在app.properties中记录对应的版本号以便回溯某版本集群使用了哪组配置。5.2 以 Git 为权威GitOps如果采用 GitOps 模式Git 是权威来源变更在 Git 中完成后通过以下方式之一应用到集群手动应用kubectl apply -f configmap.yaml自动化同步使用 Flux、ArgoCD 等 GitOps 工具在提交后自动将 Git 中的 ConfigMap 同步到集群实现配置即代码、变更可审计、回滚即git revert。六、最佳实践三Git 仓库中的 ConfigMap 组织建议在版本库中管理 ConfigMap 时推荐以下做法集中存放在仓库中建立专门目录例如k8s/configmaps/所有 ConfigMap 定义集中于此便于检索与审查用 Git tag 标记版本为特定配置版本打标签例如git tag config-v1.2.3将 tag 与 ConfigMap 内容一一对应方便精确回滚到某个配置快照配合 GitOps 工具借助 ArgoCD 或 Flux 建立从 Git 到 Kubernetes 的同步管线提交即生效并自动检测集群与 Git 的配置漂移。这些实践与 Kubernetes 通用的声明式管理理念一致能显著降低谁改了什么、何时改的、能否回滚的运维成本。七、与 Knative Operator 的协作别直接编辑 ConfigMap如果集群由Knative Operator安装和管理情况有所不同Operator 会将KnativeServing/KnativeEventing自定义资源CR中的spec.config值传播到系统 ConfigMap任何对 ConfigMap 的手工修改都会被 Operator 覆盖。因此不要直接编辑 ConfigMap而应通过修改 CR 来声明配置。具体方式参见 configuring-with-operator.mdCR 的spec.config为每个 ConfigMapconfig-name提供一个name条目其值为该 ConfigMap 的data内容。例如同时配置域名与自动扩缩容窗口apiVersion: operator.knative.dev/v1beta1 kind: KnativeServing metadata: name: knative-serving namespace: knative-serving spec: config: domain: example.org: | selector: app: prod example.com: autoscaler: stable-window: 60s需要说明的前提与限制Knative 的所有 ConfigMap 创建在与对应 CR 相同的命名空间中例如KnativeServing在knative-serving命名空间则 Serving 的 ConfigMap 也都在该命名空间未使用 Operator、采用 YAML 方式安装的集群才适合按本文前述方式直接编辑 ConfigMap两种安装方式之间的切换官方更推荐在新集群上分别安装而不是在同一集群上迁移。八、小结管理 Knative 集群配置的核心要点可以概括为三句话新增键、别动_example避免 webhook 校验和拦截先验证、再应用、后观察kubectl apply --dry-runserver 预发布测试把配置纳入 Git 版本管理导出备份或 GitOps 自动化。若集群由 Operator 管理则统一通过 CR 的spec.config声明配置而不是直接编辑 ConfigMap。掌握这些原则即可让 Knative 的配置变更变得可预期、可审计、可回滚。延伸阅读Knative 管理员配置总览含 Serving / Eventing 全部 ConfigMap 索引config-deployment 详解含example-checksum注解的 Deployment 资源配置示例config-defaults 详解Revision 默认值全部参数通过 Operator 配置 Knative自定义域名配置Eventing 事件源默认值配置赞分享文档教程云原生【免费下载链接】docsUser documentation for Knative components.项目地址https://gitcode.com/gh_mirrors/docs1/docs点击查看免费下载相关推荐PurpleLlama配置管理ConfigMap最佳实践PurpleLlama配置管理ConfigMap最佳实践 PurpleLlama是一套用于评估和改进LLM安全的工具集提供了强大的配置管理功能。本文将介绍PKnative Serving配置管理环境变量、ConfigMap和Secret的最佳用法Knative Serving配置管理环境变量、ConfigMap和Secret的最佳用法 Knative Serving作为基于Kubernetes的无服务云原生后端微服务KubeEdge配置管理最佳实践从ConfigMap到设备配置下发KubeEdge配置管理最佳实践从ConfigMap到设备配置下发 1. 边缘计算配置管理的挑战与解决方案 在工业物联网Industrial IoT场景中云原生边缘计算物联网容器编排边缘网关上一篇GitHub Copilot SDK流式保真度确保流式响应质量的机制下一篇Tsuru平台监控告警通知渠道终极配置指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考