云原生容器编排【免费下载链接】chartsBitnami Helm Charts项目地址https://gitcode.com/GitHub_Trending/charts30/charts点击查看免费下载本篇技术指南以当前仓库 bitnami/kafka/CHANGELOG.md 为主线结合 Chart.yaml、values.yaml 与 templates/ 目录下的实际模板源码系统梳理 Bitnami Kafka Helm Chart 自 32.x 系列以来的关键演进KRaft 模式落地、Kafka 4.0 升级、安全加固seccomp/TLS/SASL、网络策略、HPA 与自动扩缩容、Provisioning 自动化等。读者将掌握每个版本变更背后的配置项含义、升级注意事项以及如何基于 values 参数在 Kubernetes 上部署与运维高可用的 Kafka 集群。一、Chart 概况与版本脉络当前仓库中的 Bitnami Kafka Chart 以kafka为名Chart.yamlappVersion为4.0.0即随 Chart 一起分发的是Apache Kafka 4.0.0容器镜像docker.io/bitnami/kafka:4.0.0-debian-12-r10同时附带jmx-exporter、kubectl、os-shell等辅助镜像。Chart 依赖common子库oci://registry-1.docker.io/bitnamicharts版本 2.x.x大量复用其标签、命名、安全上下文等公共模板能力。从 CHANGELOG.md 的完整记录看该 Chart 自 2018 年的0.0.1Kafka 1.1.1一路演进到今天的32.5.0跨越了 Kafka 1.x → 2.x → 3.x → 4.0 的整个生命周期。近一年内的变更集中在几个方向32.0.02025-03-25升级到 Kafka 4.0.0并同步更新 32.0.0 的 breaking changes 说明32.2.9 再次补充32.3.02025-06-27新增kraftVersion参数用于在静态仲裁kraftVersion0与动态仲裁kraftVersion1之间切换32.4.02025-08-13网络策略改为条件化实现conditional implementation of network policy32.4.52026-09-08为 controller、broker、provisioning 与 metrics.jmx 增加seccompProfile支持并修复podSecurityContext中 seccompProfile 的拼写错误。后续小节将逐项展开这些变更对应的配置参数、模板实现与运维含义。二、KRaft 模式与 Kafka 4.0Chart 架构的根本性变化2.1 从 ZooKeeper 到 KRaftCHANGELOG 早期的条目如 2018-2023 年间大量出现 Zookeeper、zookeeper dependency 等字样例如历史版本曾通过requirements.lock/Chart.lock依赖独立的 ZooKeeper Chart。而当前版本已经不再默认部署 ZooKeeper——CHANGELOG 中 29.3.62024-07-02专门修复了 Mount kafka_jaas.conf in controller statefulset for kraft migration即控制器 StatefulSet 在 KRaft 迁移场景下的 JAAS 配置挂载问题。Kafka 4.0 是首个完全移除 ZooKeeper 支持的主版本这也正是 32.0.0 升级被标注为 breaking change 的根本原因。当前 values.yaml 中与 KRaft 直接相关的参数包括## param clusterId Kafka KRaft cluster ID. If not set, a random one will be generated clusterId: ## param existingKraftSecret Name of the secret containing the Kafka KRaft Cluster ID and one directory ID per controller replica existingKraftSecret: ## param kraftVersion Kraft version to be used. It determines whether static quorum (kraftVersion0) or dynamic quorum (kraftVersion1) will be used. ## NOTE: Kafka 4.0 does not yet support switching kraft version. This setting was added for backward-compatibility with 3.x clusters. kraftVersion: 12.2 kraftVersion 与仲裁模式切换kraftVersion是 32.3.0 引入的配置对应 CHANGELOG 条目 Add kraftVersion value to set static/dynamic quorum。其语义如下kraftVersion0使用静态仲裁static quorum控制器节点列表在配置文件中固定声明适用于节点数量稳定的集群kraftVersion1使用动态仲裁dynamic quorum控制器节点集合可在运行期通过 KRaft API 动态增删默认值即1。values.yaml 中特别注明Kafka 4.0 尚不支持在运行期切换 kraft version该参数主要为与 3.x 集群的向后兼容而保留。升级场景下若集群由 Kafka 3.x 迁移而来且旧集群使用了静态仲裁需要在升级前确认kraftVersion与已有meta.properties一致避免仲裁节点无法互相发现。2.3 Cluster ID 与 Secret 的一致性约束CHANGELOG 中多个 bugfix 都围绕 KRaft 元数据一致性展开32.1.32025-04-01recompute secret checksum on Kafka kraft secret changes即当 KRaft Secret 变化时重新计算校验和确保 StatefulSet 模板中的注解通常用于触发 Pod 滚动重启同步更新32.0.22025-03-26conditions to create Kraft secret修正了创建 KRaft Secret 的条件判断32.1.12025-03-26upgrade issue due to secret lookup修复升级过程中对 Secret 的查找逻辑。values.yaml 对此有明确的运维提示若复用已有 PVC必须保证clusterId与 PVC 内/bitnami/kafka/data/meta.properties中记录的集群 ID 一致否则新节点将无法加入集群若 Secret 中存储的 Cluster ID 与meta.properties不一致需要删除 Secret 并以正确值重新执行升级。这正是 templates/controller-eligible/config-secrets.yaml 与 templates/secrets.yaml 所渲染 Secret 的核心职责。三、安全加固演进seccomp、TLS 与 SASL3.1 seccompProfile32.4.5 的安全基线最新版本 32.4.52026-09-08的变更为为 controller、broker、provisioning 与 metrics.jmx 的containerSecurityContext增加seccompProfile配置同时修复两处文档/配置错误——重复的runAsGroup文档行以及podSecurityContext中 seccompProfile 的拼写错误typo。在 values.yaml 中可以看到对应的四级 seccomp 配置落点## param controller.containerSecurityContext.seccompProfile.type Set Kafka containers Security Context seccomp profile controller: containerSecurityContext: seccompProfile: type: ## param broker.containerSecurityContext.seccompProfile.type Set Kafka pods Security Context seccomp profile broker: podSecurityContext: seccompProfile: type: 同样的配置还覆盖到defaultInitContainers.volumePermissions、defaultInitContainers.prepareConfig、defaultInitContainers.autoDiscovery等初始化容器的containerSecurityContext.seccompProfile.type。这意味着从运行容器到 init 容器均可通过type: RuntimeDefault或type: LocalhostlocalhostProfile收紧系统调用面满足 Pod Security StandardsPSS的 restricted 级别要求。3.2 TLS 证书链路的持续修复CHANGELOG 中 TLS 相关修复贯穿始终代表性条目32.3.82025-07-25Fix kafka-client-certs volume mount and improve TLS key handling并引用 PKCS#8 问题——修复客户端证书卷挂载并改进私钥格式PKCS#8处理30.0.52024-08-23Fix pem auth with custom encrypted private key修复使用自定义加密私钥时的 PEM 认证29.3.02024-06-12Custom SANs for auto-generated TLS certificates支持为自动生成的 TLS 证书指定自定义 SAN。对应的 values 配置位于listeners.tls区块支持JKS与PEM两种证书格式。以 provisioning Job 为例values.yaml 中provisioning.auth.tls.certificatesSecret的说明明确了两种 PEM 用法提供 CA 证书 公钥 私钥走caCert分支或提供 PEM 格式的 truststore/keystore同时passwordsSecret承载keystore-password、truststore-password、key-password三个键以解锁受密码保护的 JKS 或 PEM 私钥。3.3 SASL 与密钥管理的边界条件32.1.22025-03-27relax conditions under SASL secret must be mounted as volume放宽了 SASL Secret 必须以卷volume方式挂载的条件判断——意味着在满足特定配置如启用 K8s 原生 Secret 支持时不再强制卷挂载避免不必要地暴露文件系统路径29.3.12024-06-13Fix sasl.client.passwords not working during chart upgrade修复升级过程中sasl.client.passwords不生效的问题29.2.3 前的旧版本中还修复了 issue on how to provision access to all topics / groups29.3.11即通过 ACL 脚本为*topic / group 授权时参数拼接错误。这些条目说明 SASL 认证与 ACL 授权是生产集群最常踩坑的区域升级时务必关注sasl相关参数的渲染分支是否与自身配置如sasl.client.users/sasl.client.passwords匹配。四、网络策略与外部访问32.4.0 的条件化实现4.1 NetworkPolicy 从全量渲染到条件渲染32.4.02025-08-13feat: conditional implementation of network policy是近半年较重要的功能性变更此前 NetworkPolicy 模板在 Chart 渲染时无条件参与渲染逻辑仅由enabled开关控制是否产出条件化实现则让 NetworkPolicy 的生成完全受控于networkPolicy.enabled及其他联动条件减少在关闭网络策略时遗留的无效模板输出与 RBAC/标签误判。在 values.yaml 中网络策略参数如下networkPolicy: ## Specifies whether a NetworkPolicy should be created enabled: true ## Dont require client label for connections ## When set to false, only pods with the correct client label will have network access to the port Kafka is listening on. allowExternal: true ## Allow the pod to access any range of port and all destinations. allowExternalEgress: true ## Allow access from pods with client label set to true. Ignored if allowExternal is true. addExternalClientAccess: true ## Add extra ingress rules to the NetworkPolicy extraIngress: [] ## Add extra egress rules to the NetworkPolicy extraEgress: []模板实现位于 templates/controller-eligible/networkpolicy.yaml 与 templates/broker/networkpolicy.yaml。运维实践要点当allowExternal: false且addExternalClientAccess: true时仅带app.kubernetes.io/component: ... 客户端标签client label的 Pod 可访问 Kafka 监听端口实现最小化南北向暴露extraIngress/extraEgress用于向既有策略追加自定义规则如允许 Prometheus 抓取端口、允许特定命名空间访问。更早的 30.1.02024-09-13NetworkPolicy review与 29.1.12024-05-28Fixed Network-Policies for jmx metrics export分别对应网络策略整体重构与 JMX 指标端口的放行修复说明 metrics 与网络策略的联动一直是迭代重点。4.2 外部访问的多个修复与增强32.3.12025-06-30Add ClusterIP and loadBalancerNames check for using external access hosts list在使用外部访问主机列表时增加 ClusterIP / LoadBalancer 名称校验防止错误的主机名进入advertised.listeners32.2.02025-04-15新增topologyKey参数controller 与 broker 均有values.yaml 中controller.topologyKey/broker.topologyKey用于覆盖 common 库默认的kubernetes.io/hostname例如设为topology.kubernetes.io/zone可将副本均匀分布到不同可用区31.5.02025-03-06Service 支持ipFamilies与ipFamilyPolicy配置适配 IPv4/IPv6 双栈集群外部访问 Service 的ipFamilies/ipFamilyPolicy同样可配。外部访问 Service 模板集中在 templates/controller-eligible/svc-external-access.yaml 与 templates/broker/svc-external-access.yaml支持LoadBalancer、NodePort、ClusterIP三种类型并配套externalIPs、useHostIPs、usePodIPs、domain、nodePorts等控制项。4.3 监听器渲染的正确性32.3.22025-07-03Fix extraListeners rendering to avoid malformed YAML修复了listeners.extraListeners渲染产生畸形 YAML 的问题29.3.142024-08-01则将extraListeners正确并入kafka.listeners模板变量。当前 values.yaml 中listeners.extraListeners为数组结构可追加自定义监听器对象同时 226 行附近明确注明一旦设置了listeners.extraListeners或listeners.controller/interbroker/client/external将覆盖基于上述值自动生成的监听器配置——这是定制监听器时必须注意的优先级规则。五、资源规划与自动扩缩容5.1 heapOpts 与 JVM 内存策略的演进CHANGELOG 中多次调整默认堆内存参数30.1.52024-10-07Update default value of heapOpts to fit Kafka pod RAM limit while utilize its increased default将默认堆参数调整为在 Pod RAM limit 范围内更充分的利用32.3.62025-07-18Update default controller.heapOpts to fit default RAM limit为 controller-eligible 节点单独调整默认堆参数。当前 values.yaml 的默认值统一为## param heapOpts Kafka Java Heap configuration heapOpts: -XX:InitialRAMPercentage75 -XX:MaxRAMPercentage75broker-only 节点broker.heapOpts与 controller 节点controller.heapOpts均为-XX:InitialRAMPercentage75 -XX:MaxRAMPercentage75。这种基于可用内存百分比的写法意味着只要容器内存 limit 设置合理JVM 堆会自动按比例分配无需为不同规格节点手工换算-Xmx/-Xms。若自定义镜像或非标准内存配置需同步覆盖这两项。5.2 HPA 与仲裁引导的联动修复32.2.122025-06-03Fix HPA controller logic to use maxReplicas to build controller.quorum.bootstrap.servers是一个值得关注的联动修复当 controller 启用 HPA 时StatefulSet 的replicas不再直接取值而是由 HPA 决定见 templates/controller-eligible/hpa.yaml 中maxReplicas: {{ .Values.controller.autoscaling.hpa.maxReplicas }}但 KRaft 动态仲裁要求controller.quorum.bootstrap.servers必须列出全部可能的控制器节点。若按replicas构建该列表HPA 扩容时新增副本将无法被仲裁发现。该修复改为以 HPA 的maxReplicas构建仲裁引导列表保证扩容后的新 controller 副本能正常加入仲裁。更早的 32.2.72025-05-19Update controller and broker configuration when enabling ...也涉及启用某些特性时 controller/broker 配置的同步更新同样属于控制器与代理配置联动范畴。5.3 存储与数据持久化29.3.92024-07-18Global StorageClass as default value使全局global.defaultStorageClass成为持久卷的默认 StorageClassvalues.yaml 顶部global.defaultStorageClass即此入口controller 与 broker 的persistence.storageClass均可被其覆盖32.1.02025-03-26add missing persistentVolumeClaimRetentionPolicy为 StatefulSet 补充persistentVolumeClaimRetentionPolicy配置可在删除 Pod 时保留或回收 PVC避免误删数据。六、Provisioning集群资源的自动化供给CHANGELOG 中 Provisioning 相关的修复非常密集说明它是生产接入的关键模块32.0.32025-03-26use kafka-broker-api-versions.sh to wait for Kafka on provisioning改用kafka-broker-api-versions.sh等待 Kafka 就绪替代之前的等待方式32.3.92025-07-29Fix provisioning postScript修复postScript执行逻辑32.3.72025-07-23Fix typo in initContainers修复 provisioning init 容器中的拼写错误。模板位于 templates/provisioning/job.yamlvalues.yaml 中provisioning区块的完整参数如下provisioning: enabled: false waitForKafka: true useHelmHooks: true automountServiceAccountToken: false numPartitions: 1 replicationFactor: 1 topics: [] nodeSelector: {} tolerations: [] extraProvisioningCommands: [] parallel: 1 preScript: postScript: 典型用法是同时配置topics与extraProvisioningCommandsprovisioning: enabled: true topics: - name: orders partitions: 3 replicationFactor: 3 config: max.message.bytes: 1048576 retention.ms: 604800000 extraProvisioningCommands: - | /opt/bitnami/kafka/bin/kafka-acls.sh \ --bootstrap-server $KAFKA_SERVICE \ --command-config /shared/client.properties \ --add \ --allow-principal User:user \ --consumer --topic * postScript: | echo post provisioning check其中/shared/client.properties是 Chart 预置的客户端配置挂载点$KAFKA_SERVICE指向集群 Serviceparallel控制并行执行的 provisioning 命令数preScript/postScript用于在 topic 创建前后执行自定义 bash。结合 32.0.3 的修复可知Job 中的 init 容器会先通过kafka-broker-api-versions.sh探测 Broker 版本接口确认集群可用后再执行创建逻辑避免Job 已启动但集群未就绪的竞态。七、可观测性JMX、Prometheus 与告警CHANGELOG 中可观测性相关条目贯穿多代版本31.2.02025-01-08chore(jmx-exporter): Upgrade image and change args升级 jmx-exporter 镜像并调整启动参数29.3.82024-07-16fix jmx-servicemonitor by using JMX Exporters default metrics path修正 ServiceMonitor 使用默认指标路径/metrics29.3.72024-07-08Fix jmx-exporter scrape path修复抓取路径31.1.02024-12-10为各 Chart 统一补充 Prometheus metrics 文档章节本 Chart 亦在列。当前模板目录 templates/metrics/ 包含jmx-configmap.yaml、jmx-svc.yaml、jmx-servicemonitor.yaml、prometheusrule.yaml四个文件。values 侧对应metrics.jmx开关与metrics.serviceMonitor区块metrics: jmx: enabled: false serviceMonitor: enabled: false # 需同时开启 metrics.jmx namespace: path: /metrics interval: scrapeTimeout: labels: {} selector: {} relabelings: [] metricRelabelings: [] honorLabels: false jobLabel: prometheusRule: enabled: false groups: []开启链路为metrics.jmx.enabled: true→ 在 Kafka Pod 中注入 jmx-exporter sidecarChart 注解镜像docker.io/bitnami/jmx-exporter:1.4.0-debian-12-r0见 Chart.yaml→metrics.serviceMonitor.enabled: true生成 Prometheus Operator 的 ServiceMonitor默认路径/metrics→ 可选prometheusRule.groups定义 Kafka 告警规则。注意 ServiceMonitor 与 PrometheusRule 均依赖 jmx exporter 开启且 29.0.0 起已弃用独立的 Kafka Exporter见下节。八、弃用项与破坏性变更清单CHANGELOG 是追踪破坏性变更的第一手来源升级前务必核对以下条目版本变更类型说明32.0.02025-03-25Breaking升级至 Kafka 4.0.0彻底移除 ZooKeeper 依赖全量迁移 KRaft32.2.92025-05-28再次补充 breaking changes 说明31.0.02024-11-12Breaking大版本发布31.1.0 同步补充升级说明upgrade notes30.0.02024-08-05Breaking大版本发布配套升级说明30.0.129.0.02024-05-24Deprecation弃用 Kafka Exportermetrics.kafka相关29.0.3 修复相应 linter 规则30.1.62024-10-18Deprecation弃用--broker-list选项改用--bootstrap-server22.x 时代BreakingTLS Secret 相关破坏性变更后续版本26.x补充缺失的升级说明两条实战提示Kafka 4.0 升级32.0.0 的破坏性变更源于上游移除 ZooKeeper。若从旧版本Kafka 3.x / 依赖 ZooKeeper 的 Chart 版本升级需要先完成 KRaft 迁移、确认kraftVersion与集群 ID 一致再升级 Chart 版本弃用项替换所有 ACL / 管理类命令脚本中的--broker-list一律替换为--bootstrap-server如 provisioning 的extraProvisioningCommands示例所示否则在 Kafka 4.0 上无法执行。九、版本发布节奏与依赖治理从 CHANGELOG 可以看到该 Chart 遵循频繁的依赖引用更新 定期功能性/破坏性大版本的双轨节奏依赖引用更新:zap: :arrow_up: Update dependency references几乎每月出现多次如 32.3.1132.3.14、32.4.132.4.3 均为同一周内的依赖更新用于锁定bitnami/common子库与辅助镜像版本保证安全补丁及时跟进全仓统一变更[bitnami/*]前缀说明该 Chart 与仓库内其他 100 Chart 保持同步演进例如 32.3.6 的 BSIBitnami Secure Images欢迎语、31.1.0 的 Backup Restore 文档章节、32.2.6 的 CNABAzure Marketplace链接、32.2.3 移除 Kubernetes 1.23 的兼容引用等。对使用者而言这意味着无需过度追逐每个 patch 版本但应在功能性小版本如 32.3.0 的 kraftVersion和破坏性大版本如 32.0.0发布后及时评估升级patch 版本主要解决安全与依赖问题建议保持跟进。十、基于 CHANGELOG 的升级决策清单综合全文可沉淀出以下可直接落地的升级/运维检查清单版本映射确认核对 Chart.yaml 中version当前 32.5.0与appVersion4.0.0的对应关系确认目标 Kafka 版本KRaft 一致性升级前检查clusterId/existingKraftSecret与 PVC 中meta.properties的 Cluster ID 是否一致对应 32.1.1、32.1.3 修复仲裁配置若使用 HPA 扩容 controller确认controller.autoscaling.hpa.maxReplicas覆盖全部预期控制器节点对应 32.2.12 修复安全基线为controller、broker、provisioning、metrics.jmx的containerSecurityContext统一设置seccompProfile.type对应 32.4.5网络策略确认networkPolicy.allowExternal/addExternalClientAccess组合符合预期并检查extraIngress是否放行 Prometheus 抓取端口对应 32.4.0、29.1.1脚本兼容全文替换--broker-list为--bootstrap-server对应 30.1.6可观测性按需开启metrics.jmxserviceMonitorprometheusRule确认抓取路径为/metrics对应 29.3.7、29.3.8存储确认global.defaultStorageClass与persistence.storageClass的覆盖关系并按需配置persistentVolumeClaimRetentionPolicy对应 29.3.9、32.1.0。以上每一条都可追溯到本仓库 CHANGELOG.md 中的具体条目并在 values.yaml 与 templates/ 中找到对应的参数与模板实现——这份变更记录本身就是一份生产级 Kafka on Kubernetes的运维实践地图。赞分享云原生容器编排【免费下载链接】chartsBitnami Helm Charts项目地址https://gitcode.com/GitHub_Trending/charts30/charts点击查看免费下载相关推荐Bitnami Consul Helm Chart 版本演进深度解析从 CHANGELOG 看功能、安全与运维实践Bitnami Consul Helm Chart 版本演进深度解析从 CHANGELOG 看功能、安全与运维实践 本文以仓库中 bitnami/consul云原生容器编排Bitnami ASP.NET Core Helm Chart 全解析从版本演进看架构设计与生产级部署实践Bitnami ASP.NET Core Helm Chart 全解析从版本演进看架构设计与生产级部署实践 ASP.NET Core 是微软推出的开源跨平台云原生容器编排Bitnami Apache Helm Chart 演进全解从 CHANGELOG 看 11.x 特性、安全加固与生产实践Bitnami Apache Helm Chart 演进全解从 CHANGELOG 看 11.x 特性、安全加固与生产实践 Apache HTTP Serve云原生容器编排上一篇微信小程序简易计算器项目常见问题解决方案下一篇如何快速搭建工业物联网网关mbusd让Modbus RTU设备轻松上网创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/10/3 17:27:38 · 阅读 1.2k Bitnami Kafka Helm Chart 演进全解析：从 32.x 版本变更记录看生产级 Kafka 运维实践
云原生容器编排【免费下载链接】chartsBitnami Helm Charts项目地址https://gitcode.com/GitHub_Trending/charts30/charts点击查看免费下载本篇技术指南以当前仓库 bitnami/kafka/CHANGELOG.md 为主线结合 Chart.yaml、values.yaml 与 templates/ 目录下的实际模板源码系统梳理 Bitnami Kafka Helm Chart 自 32.x 系列以来的关键演进KRaft 模式落地、Kafka 4.0 升级、安全加固seccomp/TLS/SASL、网络策略、HPA 与自动扩缩容、Provisioning 自动化等。读者将掌握每个版本变更背后的配置项含义、升级注意事项以及如何基于 values 参数在 Kubernetes 上部署与运维高可用的 Kafka 集群。一、Chart 概况与版本脉络当前仓库中的 Bitnami Kafka Chart 以kafka为名Chart.yamlappVersion为4.0.0即随 Chart 一起分发的是Apache Kafka 4.0.0容器镜像docker.io/bitnami/kafka:4.0.0-debian-12-r10同时附带jmx-exporter、kubectl、os-shell等辅助镜像。Chart 依赖common子库oci://registry-1.docker.io/bitnamicharts版本 2.x.x大量复用其标签、命名、安全上下文等公共模板能力。从 CHANGELOG.md 的完整记录看该 Chart 自 2018 年的0.0.1Kafka 1.1.1一路演进到今天的32.5.0跨越了 Kafka 1.x → 2.x → 3.x → 4.0 的整个生命周期。近一年内的变更集中在几个方向32.0.02025-03-25升级到 Kafka 4.0.0并同步更新 32.0.0 的 breaking changes 说明32.2.9 再次补充32.3.02025-06-27新增kraftVersion参数用于在静态仲裁kraftVersion0与动态仲裁kraftVersion1之间切换32.4.02025-08-13网络策略改为条件化实现conditional implementation of network policy32.4.52026-09-08为 controller、broker、provisioning 与 metrics.jmx 增加seccompProfile支持并修复podSecurityContext中 seccompProfile 的拼写错误。后续小节将逐项展开这些变更对应的配置参数、模板实现与运维含义。二、KRaft 模式与 Kafka 4.0Chart 架构的根本性变化2.1 从 ZooKeeper 到 KRaftCHANGELOG 早期的条目如 2018-2023 年间大量出现 Zookeeper、zookeeper dependency 等字样例如历史版本曾通过requirements.lock/Chart.lock依赖独立的 ZooKeeper Chart。而当前版本已经不再默认部署 ZooKeeper——CHANGELOG 中 29.3.62024-07-02专门修复了 Mount kafka_jaas.conf in controller statefulset for kraft migration即控制器 StatefulSet 在 KRaft 迁移场景下的 JAAS 配置挂载问题。Kafka 4.0 是首个完全移除 ZooKeeper 支持的主版本这也正是 32.0.0 升级被标注为 breaking change 的根本原因。当前 values.yaml 中与 KRaft 直接相关的参数包括## param clusterId Kafka KRaft cluster ID. If not set, a random one will be generated clusterId: ## param existingKraftSecret Name of the secret containing the Kafka KRaft Cluster ID and one directory ID per controller replica existingKraftSecret: ## param kraftVersion Kraft version to be used. It determines whether static quorum (kraftVersion0) or dynamic quorum (kraftVersion1) will be used. ## NOTE: Kafka 4.0 does not yet support switching kraft version. This setting was added for backward-compatibility with 3.x clusters. kraftVersion: 12.2 kraftVersion 与仲裁模式切换kraftVersion是 32.3.0 引入的配置对应 CHANGELOG 条目 Add kraftVersion value to set static/dynamic quorum。其语义如下kraftVersion0使用静态仲裁static quorum控制器节点列表在配置文件中固定声明适用于节点数量稳定的集群kraftVersion1使用动态仲裁dynamic quorum控制器节点集合可在运行期通过 KRaft API 动态增删默认值即1。values.yaml 中特别注明Kafka 4.0 尚不支持在运行期切换 kraft version该参数主要为与 3.x 集群的向后兼容而保留。升级场景下若集群由 Kafka 3.x 迁移而来且旧集群使用了静态仲裁需要在升级前确认kraftVersion与已有meta.properties一致避免仲裁节点无法互相发现。2.3 Cluster ID 与 Secret 的一致性约束CHANGELOG 中多个 bugfix 都围绕 KRaft 元数据一致性展开32.1.32025-04-01recompute secret checksum on Kafka kraft secret changes即当 KRaft Secret 变化时重新计算校验和确保 StatefulSet 模板中的注解通常用于触发 Pod 滚动重启同步更新32.0.22025-03-26conditions to create Kraft secret修正了创建 KRaft Secret 的条件判断32.1.12025-03-26upgrade issue due to secret lookup修复升级过程中对 Secret 的查找逻辑。values.yaml 对此有明确的运维提示若复用已有 PVC必须保证clusterId与 PVC 内/bitnami/kafka/data/meta.properties中记录的集群 ID 一致否则新节点将无法加入集群若 Secret 中存储的 Cluster ID 与meta.properties不一致需要删除 Secret 并以正确值重新执行升级。这正是 templates/controller-eligible/config-secrets.yaml 与 templates/secrets.yaml 所渲染 Secret 的核心职责。三、安全加固演进seccomp、TLS 与 SASL3.1 seccompProfile32.4.5 的安全基线最新版本 32.4.52026-09-08的变更为为 controller、broker、provisioning 与 metrics.jmx 的containerSecurityContext增加seccompProfile配置同时修复两处文档/配置错误——重复的runAsGroup文档行以及podSecurityContext中 seccompProfile 的拼写错误typo。在 values.yaml 中可以看到对应的四级 seccomp 配置落点## param controller.containerSecurityContext.seccompProfile.type Set Kafka containers Security Context seccomp profile controller: containerSecurityContext: seccompProfile: type: ## param broker.containerSecurityContext.seccompProfile.type Set Kafka pods Security Context seccomp profile broker: podSecurityContext: seccompProfile: type: 同样的配置还覆盖到defaultInitContainers.volumePermissions、defaultInitContainers.prepareConfig、defaultInitContainers.autoDiscovery等初始化容器的containerSecurityContext.seccompProfile.type。这意味着从运行容器到 init 容器均可通过type: RuntimeDefault或type: LocalhostlocalhostProfile收紧系统调用面满足 Pod Security StandardsPSS的 restricted 级别要求。3.2 TLS 证书链路的持续修复CHANGELOG 中 TLS 相关修复贯穿始终代表性条目32.3.82025-07-25Fix kafka-client-certs volume mount and improve TLS key handling并引用 PKCS#8 问题——修复客户端证书卷挂载并改进私钥格式PKCS#8处理30.0.52024-08-23Fix pem auth with custom encrypted private key修复使用自定义加密私钥时的 PEM 认证29.3.02024-06-12Custom SANs for auto-generated TLS certificates支持为自动生成的 TLS 证书指定自定义 SAN。对应的 values 配置位于listeners.tls区块支持JKS与PEM两种证书格式。以 provisioning Job 为例values.yaml 中provisioning.auth.tls.certificatesSecret的说明明确了两种 PEM 用法提供 CA 证书 公钥 私钥走caCert分支或提供 PEM 格式的 truststore/keystore同时passwordsSecret承载keystore-password、truststore-password、key-password三个键以解锁受密码保护的 JKS 或 PEM 私钥。3.3 SASL 与密钥管理的边界条件32.1.22025-03-27relax conditions under SASL secret must be mounted as volume放宽了 SASL Secret 必须以卷volume方式挂载的条件判断——意味着在满足特定配置如启用 K8s 原生 Secret 支持时不再强制卷挂载避免不必要地暴露文件系统路径29.3.12024-06-13Fix sasl.client.passwords not working during chart upgrade修复升级过程中sasl.client.passwords不生效的问题29.2.3 前的旧版本中还修复了 issue on how to provision access to all topics / groups29.3.11即通过 ACL 脚本为*topic / group 授权时参数拼接错误。这些条目说明 SASL 认证与 ACL 授权是生产集群最常踩坑的区域升级时务必关注sasl相关参数的渲染分支是否与自身配置如sasl.client.users/sasl.client.passwords匹配。四、网络策略与外部访问32.4.0 的条件化实现4.1 NetworkPolicy 从全量渲染到条件渲染32.4.02025-08-13feat: conditional implementation of network policy是近半年较重要的功能性变更此前 NetworkPolicy 模板在 Chart 渲染时无条件参与渲染逻辑仅由enabled开关控制是否产出条件化实现则让 NetworkPolicy 的生成完全受控于networkPolicy.enabled及其他联动条件减少在关闭网络策略时遗留的无效模板输出与 RBAC/标签误判。在 values.yaml 中网络策略参数如下networkPolicy: ## Specifies whether a NetworkPolicy should be created enabled: true ## Dont require client label for connections ## When set to false, only pods with the correct client label will have network access to the port Kafka is listening on. allowExternal: true ## Allow the pod to access any range of port and all destinations. allowExternalEgress: true ## Allow access from pods with client label set to true. Ignored if allowExternal is true. addExternalClientAccess: true ## Add extra ingress rules to the NetworkPolicy extraIngress: [] ## Add extra egress rules to the NetworkPolicy extraEgress: []模板实现位于 templates/controller-eligible/networkpolicy.yaml 与 templates/broker/networkpolicy.yaml。运维实践要点当allowExternal: false且addExternalClientAccess: true时仅带app.kubernetes.io/component: ... 客户端标签client label的 Pod 可访问 Kafka 监听端口实现最小化南北向暴露extraIngress/extraEgress用于向既有策略追加自定义规则如允许 Prometheus 抓取端口、允许特定命名空间访问。更早的 30.1.02024-09-13NetworkPolicy review与 29.1.12024-05-28Fixed Network-Policies for jmx metrics export分别对应网络策略整体重构与 JMX 指标端口的放行修复说明 metrics 与网络策略的联动一直是迭代重点。4.2 外部访问的多个修复与增强32.3.12025-06-30Add ClusterIP and loadBalancerNames check for using external access hosts list在使用外部访问主机列表时增加 ClusterIP / LoadBalancer 名称校验防止错误的主机名进入advertised.listeners32.2.02025-04-15新增topologyKey参数controller 与 broker 均有values.yaml 中controller.topologyKey/broker.topologyKey用于覆盖 common 库默认的kubernetes.io/hostname例如设为topology.kubernetes.io/zone可将副本均匀分布到不同可用区31.5.02025-03-06Service 支持ipFamilies与ipFamilyPolicy配置适配 IPv4/IPv6 双栈集群外部访问 Service 的ipFamilies/ipFamilyPolicy同样可配。外部访问 Service 模板集中在 templates/controller-eligible/svc-external-access.yaml 与 templates/broker/svc-external-access.yaml支持LoadBalancer、NodePort、ClusterIP三种类型并配套externalIPs、useHostIPs、usePodIPs、domain、nodePorts等控制项。4.3 监听器渲染的正确性32.3.22025-07-03Fix extraListeners rendering to avoid malformed YAML修复了listeners.extraListeners渲染产生畸形 YAML 的问题29.3.142024-08-01则将extraListeners正确并入kafka.listeners模板变量。当前 values.yaml 中listeners.extraListeners为数组结构可追加自定义监听器对象同时 226 行附近明确注明一旦设置了listeners.extraListeners或listeners.controller/interbroker/client/external将覆盖基于上述值自动生成的监听器配置——这是定制监听器时必须注意的优先级规则。五、资源规划与自动扩缩容5.1 heapOpts 与 JVM 内存策略的演进CHANGELOG 中多次调整默认堆内存参数30.1.52024-10-07Update default value of heapOpts to fit Kafka pod RAM limit while utilize its increased default将默认堆参数调整为在 Pod RAM limit 范围内更充分的利用32.3.62025-07-18Update default controller.heapOpts to fit default RAM limit为 controller-eligible 节点单独调整默认堆参数。当前 values.yaml 的默认值统一为## param heapOpts Kafka Java Heap configuration heapOpts: -XX:InitialRAMPercentage75 -XX:MaxRAMPercentage75broker-only 节点broker.heapOpts与 controller 节点controller.heapOpts均为-XX:InitialRAMPercentage75 -XX:MaxRAMPercentage75。这种基于可用内存百分比的写法意味着只要容器内存 limit 设置合理JVM 堆会自动按比例分配无需为不同规格节点手工换算-Xmx/-Xms。若自定义镜像或非标准内存配置需同步覆盖这两项。5.2 HPA 与仲裁引导的联动修复32.2.122025-06-03Fix HPA controller logic to use maxReplicas to build controller.quorum.bootstrap.servers是一个值得关注的联动修复当 controller 启用 HPA 时StatefulSet 的replicas不再直接取值而是由 HPA 决定见 templates/controller-eligible/hpa.yaml 中maxReplicas: {{ .Values.controller.autoscaling.hpa.maxReplicas }}但 KRaft 动态仲裁要求controller.quorum.bootstrap.servers必须列出全部可能的控制器节点。若按replicas构建该列表HPA 扩容时新增副本将无法被仲裁发现。该修复改为以 HPA 的maxReplicas构建仲裁引导列表保证扩容后的新 controller 副本能正常加入仲裁。更早的 32.2.72025-05-19Update controller and broker configuration when enabling ...也涉及启用某些特性时 controller/broker 配置的同步更新同样属于控制器与代理配置联动范畴。5.3 存储与数据持久化29.3.92024-07-18Global StorageClass as default value使全局global.defaultStorageClass成为持久卷的默认 StorageClassvalues.yaml 顶部global.defaultStorageClass即此入口controller 与 broker 的persistence.storageClass均可被其覆盖32.1.02025-03-26add missing persistentVolumeClaimRetentionPolicy为 StatefulSet 补充persistentVolumeClaimRetentionPolicy配置可在删除 Pod 时保留或回收 PVC避免误删数据。六、Provisioning集群资源的自动化供给CHANGELOG 中 Provisioning 相关的修复非常密集说明它是生产接入的关键模块32.0.32025-03-26use kafka-broker-api-versions.sh to wait for Kafka on provisioning改用kafka-broker-api-versions.sh等待 Kafka 就绪替代之前的等待方式32.3.92025-07-29Fix provisioning postScript修复postScript执行逻辑32.3.72025-07-23Fix typo in initContainers修复 provisioning init 容器中的拼写错误。模板位于 templates/provisioning/job.yamlvalues.yaml 中provisioning区块的完整参数如下provisioning: enabled: false waitForKafka: true useHelmHooks: true automountServiceAccountToken: false numPartitions: 1 replicationFactor: 1 topics: [] nodeSelector: {} tolerations: [] extraProvisioningCommands: [] parallel: 1 preScript: postScript: 典型用法是同时配置topics与extraProvisioningCommandsprovisioning: enabled: true topics: - name: orders partitions: 3 replicationFactor: 3 config: max.message.bytes: 1048576 retention.ms: 604800000 extraProvisioningCommands: - | /opt/bitnami/kafka/bin/kafka-acls.sh \ --bootstrap-server $KAFKA_SERVICE \ --command-config /shared/client.properties \ --add \ --allow-principal User:user \ --consumer --topic * postScript: | echo post provisioning check其中/shared/client.properties是 Chart 预置的客户端配置挂载点$KAFKA_SERVICE指向集群 Serviceparallel控制并行执行的 provisioning 命令数preScript/postScript用于在 topic 创建前后执行自定义 bash。结合 32.0.3 的修复可知Job 中的 init 容器会先通过kafka-broker-api-versions.sh探测 Broker 版本接口确认集群可用后再执行创建逻辑避免Job 已启动但集群未就绪的竞态。七、可观测性JMX、Prometheus 与告警CHANGELOG 中可观测性相关条目贯穿多代版本31.2.02025-01-08chore(jmx-exporter): Upgrade image and change args升级 jmx-exporter 镜像并调整启动参数29.3.82024-07-16fix jmx-servicemonitor by using JMX Exporters default metrics path修正 ServiceMonitor 使用默认指标路径/metrics29.3.72024-07-08Fix jmx-exporter scrape path修复抓取路径31.1.02024-12-10为各 Chart 统一补充 Prometheus metrics 文档章节本 Chart 亦在列。当前模板目录 templates/metrics/ 包含jmx-configmap.yaml、jmx-svc.yaml、jmx-servicemonitor.yaml、prometheusrule.yaml四个文件。values 侧对应metrics.jmx开关与metrics.serviceMonitor区块metrics: jmx: enabled: false serviceMonitor: enabled: false # 需同时开启 metrics.jmx namespace: path: /metrics interval: scrapeTimeout: labels: {} selector: {} relabelings: [] metricRelabelings: [] honorLabels: false jobLabel: prometheusRule: enabled: false groups: []开启链路为metrics.jmx.enabled: true→ 在 Kafka Pod 中注入 jmx-exporter sidecarChart 注解镜像docker.io/bitnami/jmx-exporter:1.4.0-debian-12-r0见 Chart.yaml→metrics.serviceMonitor.enabled: true生成 Prometheus Operator 的 ServiceMonitor默认路径/metrics→ 可选prometheusRule.groups定义 Kafka 告警规则。注意 ServiceMonitor 与 PrometheusRule 均依赖 jmx exporter 开启且 29.0.0 起已弃用独立的 Kafka Exporter见下节。八、弃用项与破坏性变更清单CHANGELOG 是追踪破坏性变更的第一手来源升级前务必核对以下条目版本变更类型说明32.0.02025-03-25Breaking升级至 Kafka 4.0.0彻底移除 ZooKeeper 依赖全量迁移 KRaft32.2.92025-05-28再次补充 breaking changes 说明31.0.02024-11-12Breaking大版本发布31.1.0 同步补充升级说明upgrade notes30.0.02024-08-05Breaking大版本发布配套升级说明30.0.129.0.02024-05-24Deprecation弃用 Kafka Exportermetrics.kafka相关29.0.3 修复相应 linter 规则30.1.62024-10-18Deprecation弃用--broker-list选项改用--bootstrap-server22.x 时代BreakingTLS Secret 相关破坏性变更后续版本26.x补充缺失的升级说明两条实战提示Kafka 4.0 升级32.0.0 的破坏性变更源于上游移除 ZooKeeper。若从旧版本Kafka 3.x / 依赖 ZooKeeper 的 Chart 版本升级需要先完成 KRaft 迁移、确认kraftVersion与集群 ID 一致再升级 Chart 版本弃用项替换所有 ACL / 管理类命令脚本中的--broker-list一律替换为--bootstrap-server如 provisioning 的extraProvisioningCommands示例所示否则在 Kafka 4.0 上无法执行。九、版本发布节奏与依赖治理从 CHANGELOG 可以看到该 Chart 遵循频繁的依赖引用更新 定期功能性/破坏性大版本的双轨节奏依赖引用更新:zap: :arrow_up: Update dependency references几乎每月出现多次如 32.3.1132.3.14、32.4.132.4.3 均为同一周内的依赖更新用于锁定bitnami/common子库与辅助镜像版本保证安全补丁及时跟进全仓统一变更[bitnami/*]前缀说明该 Chart 与仓库内其他 100 Chart 保持同步演进例如 32.3.6 的 BSIBitnami Secure Images欢迎语、31.1.0 的 Backup Restore 文档章节、32.2.6 的 CNABAzure Marketplace链接、32.2.3 移除 Kubernetes 1.23 的兼容引用等。对使用者而言这意味着无需过度追逐每个 patch 版本但应在功能性小版本如 32.3.0 的 kraftVersion和破坏性大版本如 32.0.0发布后及时评估升级patch 版本主要解决安全与依赖问题建议保持跟进。十、基于 CHANGELOG 的升级决策清单综合全文可沉淀出以下可直接落地的升级/运维检查清单版本映射确认核对 Chart.yaml 中version当前 32.5.0与appVersion4.0.0的对应关系确认目标 Kafka 版本KRaft 一致性升级前检查clusterId/existingKraftSecret与 PVC 中meta.properties的 Cluster ID 是否一致对应 32.1.1、32.1.3 修复仲裁配置若使用 HPA 扩容 controller确认controller.autoscaling.hpa.maxReplicas覆盖全部预期控制器节点对应 32.2.12 修复安全基线为controller、broker、provisioning、metrics.jmx的containerSecurityContext统一设置seccompProfile.type对应 32.4.5网络策略确认networkPolicy.allowExternal/addExternalClientAccess组合符合预期并检查extraIngress是否放行 Prometheus 抓取端口对应 32.4.0、29.1.1脚本兼容全文替换--broker-list为--bootstrap-server对应 30.1.6可观测性按需开启metrics.jmxserviceMonitorprometheusRule确认抓取路径为/metrics对应 29.3.7、29.3.8存储确认global.defaultStorageClass与persistence.storageClass的覆盖关系并按需配置persistentVolumeClaimRetentionPolicy对应 29.3.9、32.1.0。以上每一条都可追溯到本仓库 CHANGELOG.md 中的具体条目并在 values.yaml 与 templates/ 中找到对应的参数与模板实现——这份变更记录本身就是一份生产级 Kafka on Kubernetes的运维实践地图。赞分享云原生容器编排【免费下载链接】chartsBitnami Helm Charts项目地址https://gitcode.com/GitHub_Trending/charts30/charts点击查看免费下载相关推荐Bitnami Consul Helm Chart 版本演进深度解析从 CHANGELOG 看功能、安全与运维实践Bitnami Consul Helm Chart 版本演进深度解析从 CHANGELOG 看功能、安全与运维实践 本文以仓库中 bitnami/consul云原生容器编排Bitnami ASP.NET Core Helm Chart 全解析从版本演进看架构设计与生产级部署实践Bitnami ASP.NET Core Helm Chart 全解析从版本演进看架构设计与生产级部署实践 ASP.NET Core 是微软推出的开源跨平台云原生容器编排Bitnami Apache Helm Chart 演进全解从 CHANGELOG 看 11.x 特性、安全加固与生产实践Bitnami Apache Helm Chart 演进全解从 CHANGELOG 看 11.x 特性、安全加固与生产实践 Apache HTTP Serve云原生容器编排上一篇微信小程序简易计算器项目常见问题解决方案下一篇如何快速搭建工业物联网网关mbusd让Modbus RTU设备轻松上网创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考