ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

Bitnami Elasticsearch Helm Chart 版本演进全解析:从 0.1.3 到 22.1.x 的架构、安全与运维变迁

Bitnami Elasticsearch Helm Chart 版本演进全解析:从 0.1.3 到 22.1.x 的架构、安全与运维变迁 云原生容器编排【免费下载链接】chartsBitnami Helm Charts项目地址https://gitcode.com/GitHub_Trending/charts30/charts点击查看免费下载本文以bitnami/elasticsearch的官方 Changelogbitnami/elasticsearch/CHANGELOG.md为核心脉络结合该 Chart 当前的 Chart.yaml、values.yaml 与 templates 目录结构系统梳理这条从 2018 年 0.1.3 一路演进到 2025 年 22.1.x 的发行轨迹。读者将能从中掌握该 Chart 的节点角色架构、X-Pack 安全与 TLS 演进、存储与高可用能力、Prometheus 可观测性集成以及每个大版本背后的设计动机与升级注意事项并据此为自己的生产集群制定合理的版本选择与配置策略。一、Chart 现状一览版本、镜像与目录结构当前仓库中该 Chart 的元数据见 Chart.yaml为Chart 版本22.1.7Changelog 最新记录为 2025-08-14 发布的22.1.6随后又发布了补丁版22.1.7App 版本9.1.2镜像为docker.io/bitnami/elasticsearch:9.1.2-debian-12-r0依赖Kibana 子 Chart12.x.x由global.kibanaEnabled条件控制与 Bitnami 公共库common2.x.x许可证Apache-2.0tanzuCategory: service从 templates 目录可以清晰看到当前 Chart 的资源布局它是 Changelog 多年演进的结果master/、data/、ingest/、coordinating/四类节点的 StatefulSet/Deployment、HPA、PDB、NetworkPolicy、ServiceAccount、Headless Service 模板metrics/下的 exporter Deployment、Service、ServiceMonitor、PrometheusRule顶层configmap.yamlelasticsearch.yml、initialization-configmap.yaml、secrets.yaml、tls-secret.yaml、ingress.yaml、service.yaml、_helpers.tpl、NOTES.txt。二、重大版本里程碑一路看架构与工程标准化的转折点Changelog 从 2018-04 的0.1.3起步记录了几个决定性的主版本版本时间核心变化0.1.x2018 上半年初始 Chart引入 RBAC、metrics exporter、values-production.yaml等基础能力2.0.02018-08全面适配非 root运行Adapt elasticsearch chart to non-root5.0.02019-04适配Elasticsearch 713.0.02020-11Chart 切换到apiVersion: v2Helm 3 标准16.0.02021-09引入X-Pack Security支持18.0.02022-05Standardization Elasticsearch 8 Refactorchart 全面标准化重构并随 ES 8 重构20.0.02024-03Improve security defaults以安全默认值方式提升基线21.5.02025-04默认启用usePasswordFilestrue密码以文件方式注入而非环境变量22.0.x2025-04~05升级 common 库、移除 K8s 1.23 引用、新增shareProcessNamespace支持此外19.7.0标记了100% OCIChart 改为纯 OCI 分发19.0.0则正式废弃 elasticsearch-curator这两点对使用 Bitnami 仓库的运维人员有直接影响现代用法是helm install直接引用 OCI 仓库并通过索引生命周期管理如 Snapshot 或 ILM替代 curator。三、节点角色架构master / data / ingest / coordinating 的成形与演进四类节点分工是当前 Chart 的骨架其演进在 Changelog 中有迹可循Ingest 节点成为默认组件19.2.42022-09Deploy ingest nodes by default19.2.3修复了.Values.ingest.enabledfalse时 ingest StatefulSet 仍被部署的问题说明该开关在早期存在渲染缺陷。Coordinating 节点持续完善17.5.3修正 coordinating HPA 的 kind改为 StatefulSet19.10.2为其增加coordinating.extraRoles21.6.1修复了coordinating.security.enabled未生效的 bug。角色可扩展19.10.0引入通用extraRoles允许为某类节点追加额外的 ES 角色。对照 values.yaml 的默认值节点组关键默认值说明masterreplicaCount: 2、masterOnly: true、heapSize: 128m、podManagementPolicy: Parallel历史上一度默认 3 个 master15.4.0当前默认 2 个可配 PDBdatareplicaCount: 2、heapSize: 1024m、resourcesPreset: medium数据节点默认更大的堆coordinatingreplicaCount: 2、heapSize: 128m纯协调节点ingestenabled: true、replicaCount: 2、heapSize: 128m独立的 ingest StatefulSet 可选专用 Service/Ingress值得注意的设计细节来自 values.yaml 注释coordinating.extraRoles注释明确指出“在 Elasticsearch 中所有节点都是协调者coordinating-only 节点默认不承担其他角色”ingest.service.enabled注释提示专用 ingest Service 适合重写入场景但 ingest 节点只接受带 pipeline 的 index 请求其他请求不会被重路由这是使用该开关前必须理解的行为约束所有节点组都默认readOnlyRootFilesystem: true、runAsNonRoot: true、丢弃 ALL capabilities、seccompProfile: RuntimeDefault这是19.21.0引入 readOnlyRootFilesystem、19.14.0引入 seccompProfile、19.16.0强化 Pod/Container SecurityContext 之后的安全基线。从模板看四类节点的落地master/、data/、ingest/、coordinating/各自包含statefulset.yaml、hpa.yaml、pdb.yaml、networkpolicy.yaml、serviceaccount.yaml、svc-headless.yamlingest 另有service.yaml与ingress.yaml。也就是说每一类节点都是独立的 StatefulSet并通过各自的 headless service 与clusterDomain默认cluster.local组成集群这正是17.9.17中“Elasticsearch hosts 依赖集群配置更新”与19.6.0“恢复 headless 服务为 headless”两项变更所服务的网络模型。四、安全能力演进从可选 X-Pack 到默认安全基线安全是 Changelog 中变化最密集的主题X-Pack 接入16.0.02021-09引入 X-Pack Security 支持。当前 values.yaml 中security.enabled默认false但security.tls.restEncryption默认true——注意注释“配置密码认证需要先启用 TLS”。TLS 证书管理19.5.10修复“升级时重新生成自签名证书”的问题避免升级导致证书轮换19.1.11修复生成 TLS 证书的 altNames19.1.1修复 TLS secret17.1.5修复 keystore/truststore 密码 secret。22.0.12则移除了 copyTlsCerts init container此前证书复制逻辑引发多处 issue。当前 TLS 参数支持 JKS/PKCS12 与 PEM 两种证书形态usePemCerts支持 per-节点组 existingSecretmaster/data/ingest/coordinating并提供autoGenerated自签名模式其注释明确给出升级警告若启用 autoGenerated 证书用 helm upgrade 新增节点类型前必须删除旧的 ES TLS secret否则新节点证书不匹配。凭证注入方式21.5.0将usePasswordFiles默认改为true——密码通过挂载文件而非环境变量注入避免进程环境变量泄露。当前还支持security.existingSecret19.13.11文档化了期望的 secret keyelasticsearch-password。容器与平台安全19.15.0停止使用默认 ServiceAccount19.17.0将 ServiceAccount token 自动挂载收敛到 Pod 声明层级19.20.0提供 Openshiftrestricted-v2自动适配19.17.1将seLinuxOptions置空以兼容 Openshift22.0.4新增shareProcessNamespace支持。网络层19.18.0默认启用 NetworkPolicy18.1.0为 Ingress 增加extraRules21.2.6修复 ingress backend 声明名称。启用安全的一个最小配置对应 values.yaml 的security段security: enabled: true # 开启 X-Pack 密码认证默认依赖 TLS elasticPassword: # 或使用 existingSecret期望 key: elasticsearch-password tls: restEncryption: true # 默认即 true autoGenerated: false # 生产建议自行签发或注入 existingSecret verificationMode: full21.6.2的tests: Enable security during testing与21.6.1的 coordinating security 修复说明安全组合TLS 多节点类型一直是测试与修复的重点区域升级时务必回归验证。五、存储与高可用PV、RetentionPolicy、PDB、HPA、拓扑约束持久化9.0.0为 master 挂载 PVC12.4.0/12.5.0允许 master/data 使用既有 PVC 与既有 PV13.1.0支持自定义 volumeClaimTemplate 选择器21.3.16修复 volumeClaimTemplates 缺少apiVersion/kind的问题。当前默认accessModes: [ReadWriteOnce]、size: 8Gi并可通过existingClaim/existingVolume/selector复用存量卷。PVC 保留策略21.3.0为 master 与 data 的 StatefulSet 引入persistentVolumeClaimRetentionPolicy默认whenScaled: Retain、whenDeleted: Retain可在 values.yaml 的master.persistentVolumeClaimRetentionPolicy/data.persistentVolumeClaimRetentionPolicy中调整。可用性组件19.8.0为所有组件加 PDB21.2.0统一启用 PodDisruptionBudget15.3.0引入 HPA现四类节点组均有autoscaling段默认minReplicas: 3、maxReplicas: 1117.1.0支持 topologySpreadConstraints17.2.0支持 priorityClassName14.3.0支持自定义 schedulerName11.0.0让 master 并行部署podManagementPolicy: Parallel。调度12.7.0引入基于 common 预设的 affinity当前每个节点组都提供podAffinityPreset/podAntiAffinityPreset/nodeAffinityPreset以及完整affinity、nodeSelector、tolerations。这些能力在 templates 中一一对应每个节点组目录下的pdb.yaml、hpa.yaml、networkpolicy.yaml生产集群可直接按“master 奇数个 data 按容量规划 PDB 保可用 HPA 仅用于协调/ingest”的思路组合。六、可观测性exporter、ServiceMonitor 与 PrometheusRule7.1.0引入 ServiceMonitor 支持18.2.0增加 PrometheusRule19.21.2修复 exporter 的es.uri模板17.9.16让 metrics 在TLS 开启时自动适配14.2.0在无 coordinating 节点时切换 metrics 端点17.5.5修复 metrics 密码注入。当前 values.yaml 的metrics段默认enabled: falseexporter 镜像为bitnami/elasticsearch-exporter:1.9.0-debian-12-r16端口9114可通过metrics.extraArgs追加如--es.snapshots、--es.indices等参数metrics.serviceMonitor.enabled与metrics.prometheusRule.enabled分别控制 Prometheus Operator 的抓取与告警规则prometheusRule.rules中给出了基于elasticsearch_cluster_health_status的示例告警red/yellow 状态、持续 1m、severity critical。七、运维与生命周期细节init 容器、诊断模式、单节点与集群互联sysctl init 容器4.1.2增加可开关的 sysctl init container7.1.0改为默认启用12.8.0为其补充 resources14.4.0简化逻辑17.0.3修复 sysctl 参数。当前sysctlImage.enabled默认true用于在 Pod 内设置 Elasticsearch 所需内核参数如vm.max_map_count。volumePermissions1.0.x时代即有卷权限处理当前volumePermissions.enabled默认false仅在默认runAsUser/fsGroup不适用时开启。默认 init 容器总开关21.6.0新增enableDefaultInitContainers可一键关闭 sysctl、volume permissions、复制插件等默认 init 容器方便使用自定义镜像或受限平台。诊断模式15.10.0引入diagnosticMode开启后禁用所有探针并以sleep infinity覆盖命令便于排障。单节点部署19.12.0支持 single-node适合开发/演示环境。集群互联19.3.0增加extraHosts14.1.0增加 hostAliases配合 values.yaml 中跨 namespace/K8s 集群组网的使用场景17.9.0支持协议选择http/https。初始化脚本与配置12.2.0支持自定义 init scripts 与 extra env vars当前为initScripts/initScriptsCM/initScriptsSecret15.6.0引入extraConfig追加elasticsearch.yml配置12.3.0支持文件系统 snapshot 仓库路径snapshotRepoPathplugins参数在4.2.x时代即已文档化。服务与入口17.7.0增加 master ingress19.4.0支持可配置 service 名称servicenameOverride22.1.0修正 Kibana 引用的服务名称19.1.0为所有 StatefulSet 支持自定义 annotations17.5.0为 coordinating 服务支持 externalTrafficPolicy17.8.0为 data 服务支持 annotations。八、Kibana 集成与依赖管理10.0.0将 Kibana 作为依赖引入10.1.0改为通过全局值启用17.0.0大幅升级 Kibana 主版本22.0.1更新 Kibana 子 Chart。当前 Chart.yaml 中global.kibanaEnabled默认false控制 Kibana 子 Chart并通过global.elasticsearch.service.name/fullname/ports.restAPI让 Kibana 找到 ES。17.3.2记录的Kibana restEncryption注意事项提醒启用 REST TLS 时需同步为 Kibana 配置证书否则两者连接会失败。九、当前默认配置速查基于 values.yaml类别默认值端口REST9200、Transport9300container 与 service 一致集群clusterName: elastic、clusterDomain: cluster.local凭证usePasswordFiles: true、security.enabled: false、security.tls.restEncryption: true探针各节点组 liveness/readiness 默认开启initialDelay 180s/90sstartup 默认关闭镜像策略pullPolicy: IfNotPresent支持image.digest覆盖 tag19.2.0引入 digest 支持资源预设master/coordinating/ingest 为smalldata 为mediummetrics 与 init 容器为nano19.19.1引入全局global.defaultStorageClass、global.imageRegistry、global.imagePullSecrets、global.security.allowInsecureImagesOpenshiftglobal.compatibility.openshift.adaptSecurityContext: auto十、升级路径与注意事项总结综合 Changelog 中的修复记录升级时建议关注以下高概率风险点TLS/证书autoGenerated 证书升级前清理旧 secret22.x 注释19.5.10后自签名证书不再随升级重生成证书过期需手动处理。StatefulSet 字段21.3.16修正 volumeClaimTemplates 的 apiVersion/kind若使用旧版 Helm 渲染请核对生成物19.5.3修复 statefulset 的 apiVersion。节点角色与 env19.19.4修复ELASTICSEARCH_NODE_ROLES取值19.1.8修复master.heapSize不生效问题——配置堆大小前确认使用的是当前参数名。Service/Ingress 命名19.4.0/22.1.0/21.2.6涉及服务名与 ingress backend 命名升级后需检查引用关系。废弃能力curator19.0.0废弃、values-production.yaml13.1.3移除、PodSecurityPolicy17.1.8标记废弃、K8s 1.23 支持22.0.2移除——依赖这些特性的旧用法需提前迁移。结语从 0.1.3 的“能跑起来”到 22.1.x 的“四类节点 安全基线 可观测性 存储高可用”的工程化标准 Chartbitnami/elasticsearch的 Changelog 本身就是一部 Helm 运维最佳实践史。在选用版本时建议结合上述演进要点对照 values.yaml 与 templates 逐个确认安全、存储与网络配置并优先关注 22.x 之后的安全默认值改进。赞分享云原生容器编排【免费下载链接】chartsBitnami Helm Charts项目地址https://gitcode.com/GitHub_Trending/charts30/charts点击查看免费下载相关推荐Bitnami Argo Workflows Helm Chart 版本演进全解析从 0.1.0 到 13.0.x 的功能变迁与配置实践Bitnami Argo Workflows Helm Chart 版本演进全解析从 0.1.0 到 13.0.x 的功能变迁与配置实践 本文以 argo w云原生容器编排Bitnami Cilium Helm Chart 演进全解析从 0.1.0 到 3.x 的版本脉络、架构与配置实践Bitnami Cilium Helm Chart 演进全解析从 0.1.0 到 3.x 的版本脉络、架构与配置实践 本文以 bitnami/cilium/C云原生容器编排Bitnami cert-manager Helm Chart 版本演化全解析从 0.1.0 到 1.5.x 的功能与安全演进指南Bitnami cert manager Helm Chart 版本演化全解析从 0.1.0 到 1.5.x 的功能与安全演进指南 本文以 bitnami/c云原生容器编排上一篇testssl.sh 常见问题FAQ深度解析运行时行为、STARTTLS 评分与 Bash 架构原理下一篇魔兽争霸3终极优化方案WarcraftHelper插件完全使用指南创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表