ARTICLE DETAIL

资讯详情

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

在 Kubernetes 上部署 Logstash:Bitnami Helm Chart 完整配置与多管道实战指南

在 Kubernetes 上部署 Logstash:Bitnami Helm Chart 完整配置与多管道实战指南 云原生容器编排【免费下载链接】chartsBitnami Helm Charts项目地址https://gitcode.com/GitHub_Trending/charts30/charts点击查看免费下载导读Logstash 是 ELK 栈中的核心数据加工引擎负责从多个数据源实时采集数据、经过 filter 处理后将结果输出到最终目的地。本文以 Bitnami 官方 Helm Chart for Logstash 为主体系统讲解如何在 Kubernetes 集群中安装、配置、暴露 Logstash 服务深入剖析input/filter/output参数、多管道multiple pipelines机制、持久化、安全加固等实战要点并结合本仓库中的 values.yaml 与模板源码印证底层实现。读完本文你将掌握从一条helm install命令到生产级 Logstash 部署的完整闭环。一、Chart 概览与前置条件本 Chart 通过 Helm 包管理器在 Kubernetes 集群中引导一个 Logstash 部署其核心定义位于 Chart.yaml。以当前仓库中的版本为例该 Chart 版本为7.0.12对应的 Logstash 应用版本appVersion为9.1.2容器镜像为docker.io/bitnami/logstash:9.1.2-debian-12-r0同时依赖bitnami/common2.x库 Chart 来复用通用模板标签、资源预设、亲和性等工具函数。部署前需要满足以下前置条件Kubernetes 1.23Helm 3.8.0注意本仓库是 Bitnami Charts 的一个镜像/快照用于离线阅读与源码分析。实际安装时请替换为你的 Helm 仓库地址例如 Bitnami 官方 OCI 仓库。二、安装 Chart2.1 快速安装最简单的安装方式使用默认配置部署一个名为my-release的 releasehelm install my-release oci://registry-1.docker.io/bitnamicharts/logstash若使用通用模板则安装命令为helm install my-release oci://REGISTRY_NAME/REPOSITORY_NAME/logstash其中REGISTRY_NAME与REPOSITORY_NAME需要替换为实际的 Helm Chart 仓库地址。例如 Bitnami 官方仓库为REGISTRY_NAMEregistry-1.docker.io、REPOSITORY_NAMEbitnamicharts。默认部署行为如下对应 values.yaml 中的默认值单副本 StatefulSetreplicaCount: 1默认 Logstash 配置为通过 HTTP 在 8080 端口接收请求并输出到标准输出stdout {}启用 Monitoring APIenableMonitoringAPI: true端口9600以1001用户运行readOnlyRootFilesystem: truerunAsNonRoot: true数据持久化默认关闭persistence.enabled: false。提示可以用helm list查看集群中已安装的全部 release。2.2 通过--set覆盖参数安装时可以通过--set keyvalue逐个覆盖参数例如禁用 Monitoring APIhelm install my-release \ --set enableMonitoringAPIfalse oci://REGISTRY_NAME/REPOSITORY_NAME/logstash2.3 通过 values 文件安装生产环境更推荐将全部配置写入 YAML 文件再通过-f参数传入helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/logstash仓库中的 values.yaml 是带完整注释的默认值文件可以直接作为配置模板的起点。三、使用 Bitnami Secure Images安全镜像Bitnami 的镜像基于云优化、安全加固的企业级 Photon OS 构建其核心卖点包括对流行开源软件提供加固、近零 CVE 的镜像通过 VEX 声明、KEV 与 EPSS 评分对漏洞进行分诊与优先级排序提供 FIPS、STIG、air-gap 等合规选项以及安全物料清单SBOM通过 in-toto 提供软件供应链来源证明对 Helm Charts 提供一流支持。每个镜像都附带安全元数据可在公共目录查看应用详情与打包报告部分数据需要 BSI 商业订阅。若需使用上一代基于 Debian 的镜像可参考 Bitnami Legacy registry。从 Chart 源码看镜像加固还体现在模板层的强制约束上默认containerSecurityContext.capabilities.drop: [ALL]、seccompProfile.type: RuntimeDefault、allowPrivilegeEscalation: false见 values.yaml并且在 NOTES.txt 中通过common.errors.insecureImages对镜像验证失败给出提示若需跳过镜像验证可设置global.security.allowInsecureImages: true。四、配置与安装细节4.1 资源请求与限制Resource requests and limits生产工作负载必须为容器设置合理的资源requests与limits它们位于resources参数下。为了让配置更简单Chart 提供了resourcesPreset预置档位档位适用场景none不设置资源nano/micro极小内存场景如 Minikubesmall默认常规测试部署medium/large/xlarge/2xlarge按负载规模递增预置资源的具体数值定义在bitnami/common库的templates/_resources.tpl中。但官方明确指出生产环境不建议使用resourcesPreset因为它未必贴合你的实际负载应使用自定义的resources。resources配置示例摘自 values.yaml 的注释示例resources: requests: cpu: 2 memory: 512Mi limits: cpu: 3 memory: 1024Mi从模板实现看sts.yaml 中的资源渲染逻辑是优先采用用户显式声明的resourcestoYaml输出仅在未声明时才回退到common.resources.presetresourcesPreset这与 README 的建议完全一致。4.2 Rolling Tag 与 Immutable Tag生产环境强烈建议使用不可变标签immutable tags以避免同一 tag 被更新为不同镜像时你的部署在无感知的情况下被自动变更。Bitnami 会在主容器发布新版本、出现重大变更或存在严重漏洞时发布新 Chart 并更新容器。仓库中的模板也内置了检查机制_helpers.tpl中的logstash.checkRollingTags会调用common.warnings.rollingTag检查image与volumePermissions.image是否使用了滚动标签并在 NOTES.txt 中输出警告。4.3 暴露 Logstash 服务Chart 通过 Service 资源对外提供服务支持四种暴露方式对应 svc.yaml方式说明配置Ingress通过 Ingress Controller 暴露ingress.enabledtrueClusterIP仅在集群内部可达service.typeClusterIP默认NodePort通过每个节点的静态端口对外访问NODE-IP:NODE-PORTservice.typeNodePortLoadBalancer使用云厂商负载均衡器对外暴露service.typeLoadBalancer此外Chart 还会创建一个 headless Servicefullname-headless见 headless-svc.yaml供 StatefulSet 的 Pod 网络标识与发现使用。4.4 使用自定义配置默认情况下 Chart 提供的 Logstash 基础配置是HTTP 监听 8080 端口、输出到标准输出。你可以通过以下参数逐段调整配置inputInput 插件配置filterFilter 插件配置outputOutput 插件配置extraInput额外的 Input 插件配置与input合并渲染。以 values.yaml 为例默认配置为input: |- # udp { # port 1514 # type syslog # } # tcp { # port 1514 # type syslog # } http { port 8080 } filter: output: |- # elasticsearch { # hosts [${ELASTICSEARCH_HOST}:${ELASTICSEARCH_PORT}] # manage_template false # index %{[metadata][beat]}-%{YYYY.MM.dd} # } # gelf { # host ${GRAYLOG_HOST} # port ${GRAYLOG_PORT} # } stdout {}注释中的示例展示了常见的扩展方向通过tcp/udp接收 syslog端口 1514、通过gelf输出到 Graylog、通过elasticsearch输出到 ES 集群等。模板渲染原理配置会被拼装成 ConfigMap 中的logstash.conf文件逻辑位于 configuration-cm.yamlinput { ...(input extraInput 渲染结果) } filter { ...(filter 渲染结果) } output { ...(output 渲染结果) }值得注意的实现细节StatefulSet 模板中checksum/configuration注解会对 ConfigMap 内容求哈希sts.yaml因此配置一旦变化Pod 会自动滚动重启以加载新配置。除上述参数外Chart 还支持通过existingConfiguration参数直接引用一个已存在的 ConfigMap作为完整配置来源一旦设置该参数input、filter、output将被忽略。从 configuration-cm.yaml 可见当设置了existingConfiguration时Chart 不会渲染内置 ConfigMap而 sts.yaml 中的configurations卷会通过 logstash.configmapName 直接指向该外部 ConfigMap。4.5 创建和使用多管道Multiple PipelinesLogstash 支持在一个实例中运行多条相互独立的管道。Chart 通过enableMultiplePipelines: true开启该能力将pipelines.yml与其余配置文件放入files/conf目录或通过existingConfiguration传入包含全部配置文件的 ConfigMap如果开启了enableMultiplePipelines但挂载卷中不存在pipelines.ymlChart 会创建一个仅含单条默认管道的 dummy 文件模板中对应环境变量为LOGSTASH_ENABLE_MULTIPLE_PIPELINES见 sts.yaml容器启动脚本据此决定是否以多管道模式启动。完整实战示例通过 ConfigMap 创建两条管道第一步编写两个管道配置文件和pipelines.yml$ cat bye.conf input { file { path /tmp/bye } } output { stdout { } } $ cat hello.conf input { file { path /tmp/hello } } output { stdout { } } $ cat pipelines.yml - pipeline.id: hello path.config: /opt/bitnami/logstash/config/hello.conf - pipeline.id: bye path.config: /opt/bitnami/logstash/config/bye.conf $ kubectl create cm multipleconfig --from-filepipelines.yml --from-filehello.conf --from-filebye.conf第二步部署 Chart 时同时开启多管道并引用该 ConfigMaphelm install logstash . --set enableMultiplePipelinestrue --set existingConfigurationmultipleconfig第三步在跟踪的文件中写入测试事件并查看输出kubectl exec -ti logstash-0 -- bash -c echo hi /tmp/hello kubectl exec -ti logstash-0 -- bash -c echo bye /tmp/bye若配置正确Logstash 会分别将hi、bye从对应的/tmp/hello、/tmp/bye文件中读取并经 stdout 打印出来。4.6 添加额外环境变量使用extraEnvVars直接添加环境变量extraEnvVars: - name: ELASTICSEARCH_HOST value: x.y.z也可以从外部 ConfigMap 或 Secret 批量注入环境变量它们必须已存在于命名空间中extraEnvVarsSecret: logstash-secrets extraEnvVarsCM: logstash-configmap模板实现位于 sts.yamlextraEnvVars渲染进envextraEnvVarsCM/extraEnvVarsSecret渲染进envFrom的configMapRef/secretRef。4.7 设置 Pod 亲和性通过affinity参数可以完全自定义 Pod 亲和性规则。作为更简单的替代Chart 提供三组预置亲和性配置来源于bitnami/common库podAffinityPresetPod 亲和性预置可选soft或hardpodAntiAffinityPresetPod 反亲和性预置默认softnodeAffinityPreset节点亲和性预置通过type、key、values指定。从 sts.yaml 的实现看当显式设置了affinity时三个预置参数全部被忽略否则模板会依次渲染podAffinity、podAntiAffinity和nodeAffinity的预置规则。默认的soft反亲和性会让多个副本尽量分布在不同的节点上但不会强制。4.8 备份与恢复若要备份和恢复 Helm 部署需要将源部署的持久卷Persistent Volumes备份下来并使用 Velero 将其挂载到新部署中。Velero 是 Kubernetes 的备份/恢复工具具体步骤可参考 Bitnami 官方的备份恢复操作指南。五、持久化PersistenceBitnami Logstash 镜像将数据存储在容器的/bitnami/logstash/data路径。Chart 使用 PersistentVolumeClaimPVC跨部署保留数据该方案已验证可在 GCE、AWS 和 minikube 上工作。持久化相关参数默认值见 values.yaml参数说明默认值persistence.enabled是否启用数据持久化falsepersistence.existingClaim使用已手动创建的 PVC 名称persistence.storageClassPVC 的 StorageClass-表示禁用动态供给persistence.accessModesPVC 访问模式[ReadWriteOnce]persistence.sizePVC 存储容量请求2Gipersistence.mountPath数据卷挂载路径/bitnami/logstash/datapersistence.annotationsPVC 注解{}persistence.selector匹配已有 PV 的选择器{}模板实现要点sts.yaml启用持久化时通过volumeClaimTemplates为每个副本动态创建 PVC并设置LOGSTASH_DATA_DIR环境变量指向挂载路径未启用时data卷退化为emptyDirPod 删除后数据即丢失若persistence.enabled与volumePermissions.enabled同时开启会注入名为volume-permissions的 init 容器负责创建挂载目录并将属主改为runAsUser:fsGroup默认1001:1001。六、参数总表Parameters6.1 Global 参数名称描述默认值global.imageRegistry全局 Docker 镜像仓库global.imagePullSecrets全局镜像拉取 Secret 数组[]global.defaultStorageClass全局默认 StorageClassglobal.storageClass已弃用改用global.defaultStorageClassglobal.security.allowInsecureImages允许跳过镜像验证falseglobal.compatibility.openshift.adaptSecurityContextOpenShift restricted-v2 SCC 兼容适配auto/force/disabledauto6.2 Common 参数名称描述默认值kubeVersion强制目标 Kubernetes 版本nameOverride部分覆盖logstash.fullname模板保留 release 名fullnameOverride完全覆盖logstash.fullname模板clusterDomain集群域名cluster.localcommonAnnotations添加到所有对象的注解{}commonLabels添加到所有对象的标签{}extraDeploy随 release 部署的额外对象数组按模板求值[]diagnosticMode.enabled开启诊断模式禁用全部探针并覆盖命令falsediagnosticMode.command覆盖所有容器的命令[sleep]diagnosticMode.args覆盖所有容器的参数[infinity]6.3 Logstash 参数名称描述默认值image.registry/image.repository镜像仓库 / 仓库名docker.io/bitnami/logstashimage.digest镜像 digest设置后覆盖 tagimage.pullPolicy镜像拉取策略IfNotPresentimage.pullSecrets镜像拉取 Secret 数组[]image.debug开启调试日志falseautomountServiceAccountToken是否在 Pod 中挂载 ServiceAccount tokenfalsehostAliases添加 Pod 主机别名[]configFileNameLogstash 配置文件名须与 ConfigMap 挂载的文件名一致logstash.confenableMonitoringAPI是否启用 Logstash Monitoring APItruemonitoringAPIPortMonitoring API 端口9600extraEnvVars额外环境变量数组[]extraEnvVarsSecret/extraEnvVarsCM从 Secret / ConfigMap 注入环境变量input/extraInputInput 插件配置 / 额外 Input 插件配置filterFilter 插件配置outputOutput 插件配置existingConfiguration已存在的配置 ConfigMap设置后忽略 input/filter/outputextraConfigurationFiles额外配置文件挂载到/bitnami/logstash/config按模板渲染{}enableMultiplePipelines是否启用多管道falseextraVolumes/extraVolumeMounts额外卷 / 额外挂载[]serviceAccount.create/name/automountServiceAccountToken/annotationsServiceAccount 相关配置true//false/{}containerPorts/extraContainerPorts容器端口 / 额外容器端口[]initContainers/sidecars额外 init 容器 / 边车容器[]replicaCountLogstash 副本数1updateStrategy.type更新策略RollingUpdate/OnDeleteRollingUpdatepodManagementPolicyPod 管理策略OrderedReadypodAnnotations/podLabelsPod 注解 / 标签{}podAffinityPreset/podAntiAffinityPreset亲和性预置soft/hard/softnodeAffinityPreset.type/key/values节点亲和性预置//[]affinity/nodeSelector/tolerations自定义调度规则{}/{}/[]priorityClassName/schedulerNamePod 优先级 / 自定义调度器terminationGracePeriodSeconds优雅终止宽限期topologySpreadConstraintsTopology Spread 约束[]podSecurityContext.*Pod 安全上下文默认fsGroup: 1001见 values.yamlcontainerSecurityContext.*容器安全上下文runAsNonRoot: true、readOnlyRootFilesystem: true、capabilities.drop: [ALL]等见 values.yamlcommand/args覆盖容器命令 / 参数自定义镜像时使用[]lifecycleHooks容器生命周期钩子{}resourcesPreset资源预置档位none/nano/micro/small/medium/large/xlarge/2xlargesmallresources自定义资源 requests / limits生产推荐{}startupProbe/livenessProbe/readinessProbe三种探针配置含enabled、initialDelaySeconds、periodSeconds等见 values.yamlcustomStartupProbe/customLivenessProbe/customReadinessProbe自定义探针完全覆盖默认探针{}service.typeService 类型ClusterIPservice.ports/service.extraPortsService 端口数组 / 额外端口按模板求值[]service.loadBalancerIP/loadBalancerSourceRanges/externalTrafficPolicyLoadBalancer 相关配置/[]/service.clusterIP/annotations/sessionAffinity/sessionAffinityConfigService 其他配置见 values.yamlservice.headless.annotationsHeadless Service 注解{}networkPolicy.enabled/allowExternal/allowExternalEgressNetworkPolicy 开关 / 外部访问策略true/true/truenetworkPolicy.extraIngress/extraEgress额外入站 / 出站规则[]networkPolicy.ingressNSMatchLabels/ingressNSPodMatchLabels跨命名空间放行标签{}persistence.*持久化配置见上文见上文volumePermissions.*卷权限 init 容器配置默认resourcesPreset: nano见 values.yamlingress.enabled/selfSigned/pathType/apiVersionIngress 开关 / 自签证书 / 路径类型false/false/ImplementationSpecific/ingress.hostname/path/annotations/tlsIngress 主机 / 路径 / 注解 / TLSlogstash.local///{}/falseingress.extraHosts/extraPaths/extraRules/extraTls/secrets/ingressClassNameIngress 高级配置[]pdb.create/minAvailable/maxUnavailablePod 中断预算true//完整默认值请直接查看仓库中的 values.yaml所有参数均有逐条中文注释与示例。6.4 关于探针与健康检查的实现细节从 sts.yaml 可以确认探针的默认实现livenessProbeTCP 连接检查目标是monitoring端口9600readinessProbeHTTP GET 请求http://localhost:9600/即探测 Logstash Monitoring API 的根路径startupProbe默认关闭启用时同样使用 TCP 检查。因此若你通过extraConfigurationFiles覆盖了logstash.yml请务必保持api.http.port与monitoringAPIPort一致否则就绪探针可能一直失败。七、Ingress 与网络策略7.1 Ingress默认 hostname 为logstash.local、路径为/。启用方式ingress: enabled: true hostname: logstash.example.com tls: true ingressClassName: nginx annotations: cert-manager.io/cluster-issuer: cluster-issuer-name关键参数说明ingress.selfSigned让 Helm 生成自签名 TLS 证书ingress.tls为ingress.hostname启用 TLS证书 secret 名为hostname-tls可通过ingress.secrets手动提供证书或依靠 cert-manager 自动生成ingress.extraHosts为额外主机名添加规则ingress.extraPaths在主主机下追加额外路径如 ALB 的 SSL 重定向规则path: /*ingress.extraRules/ingress.extraTls完全自定义规则与 TLS 块按模板渲染ingress.path若使用 ALB Ingress Controller可能需要设置为/*。模板实现在 ingress.yaml后端统一指向名为http的 Service 端口。7.2 NetworkPolicyChart 默认创建 NetworkPolicynetworkpolicy.yaml策略类型包含 Ingress 与 EgressnetworkPolicy.allowExternal: true默认允许任意来源访问 Logstash 监听端口设为false时仅放行带common.names.fullname-client: true标签的 Pod、同命名空间匹配标签的 Pod以及通过ingressNSMatchLabels/ingressNSPodMatchLabels指定的跨命名空间来源networkPolicy.allowExternalEgress: true默认允许 Pod 访问任意目标设为false时仅放行 DNS53/UDP、53/TCP、预留的 9200 端口避免影响已有 Kibana/ES 访问以及集群内同标签 Pod 之间的访问。八、升级注意事项Upgrading升级到 6.4.0该版本引入了镜像验证image verification机制。如需禁用设置global.security.allowInsecureImages: true。升级到 6.0.0该次主版本更新更改了以下安全默认值可能导致自定义/初始化脚本失效runAsGroup从0改为1001readOnlyRootFilesystem设为trueresourcesPreset从none改为测试套件可运行的最小档位注意resourcesPreset不适合生产请使用适合自己场景的resourcesglobal.compatibility.openshift.adaptSecurityContext从disabled改为auto。如遇兼容性问题可将上述默认值回退为旧值。升级到 5.0.0该版本移除了 metrics 部分上游项目不再维护bitnami/logstash-exporter容器已被弃用。升级到 4.0.0该版本将 Chart 升级到 Logstash 8并标准化了大量参数主要变更securityContext拆分为containerSecurityContext与podSecurityContextLiveness / readiness 探针的httpGet字段不可再修改自定义请使用customLivenessProbe/customReadinessProbelifecycle更名为lifecycleHooksservice.ports改为按模板求值的数组结构启用ingress.tls不再自动生成证书需用ingress.selfSignedpodDisruptionBudget.*更名为pdb.*。升级到 3.0.0标准化 Ingress 规则定义方式单主机名用ingress.hostname多主机名用ingress.extraHosts数组。升级到 2.0.0移除了对files/目录中文件的挂载支持仅在某些条件下生效。请改用input/output/filter、existingConfiguration或extraDeploy等替代机制。升级到 1.2.0引入bitnami/common库 Chart 作为依赖升级前务必先更新 Chart 依赖。升级到 1.0.02020 年 11 月 13 日 Helm v2 正式 EOL 后Chart 发布了适配 Helm v3 的主版本。九、故障排查若在部署或运行中遇到常见错误可参考 Bitnami 官方的 Helm Chart 问题排查指南docs.bitnami.com的 How-to 栏目。结合本仓库源码几个高频问题可优先自查探针一直失败确认monitoringAPIPort默认 9600与extraConfigurationFiles中logstash.yml的api.http.port一致配置不生效确认existingConfiguration指定的 ConfigMap 存在于同一命名空间且 ConfigMap 中的文件名与configFileName默认logstash.conf一致镜像拉取失败私有仓库场景请配置image.pullSecrets或global.imagePullSecrets诊断排错开启diagnosticMode.enabled后所有探针被禁用、命令被覆盖为sleep infinity可进入容器手动执行/opt/bitnami/scripts/logstash/entrypoint.sh /opt/bitnami/scripts/logstash/run.sh复现启动流程见 NOTES.txt。十、小结Bitnami 的 Logstash Helm Chart 提供了从开箱即用的一行安装到生产级精细调控的完整能力。通过input/filter/output参数或existingConfiguration可以灵活定制数据处理管道enableMultiplePipelines支持多管道并行而资源预置、亲和性预置、安全上下文、NetworkPolicy、PDB 等机制则让部署在弹性、可用性与安全性上都有据可依。本文所引用的所有配置默认值与实现细节均可在本仓库的 values.yaml 与 templates 目录中逐一核对可作为你后续生产部署与二次开发的直接参考资料。赞分享云原生容器编排【免费下载链接】chartsBitnami Helm Charts项目地址https://gitcode.com/GitHub_Trending/charts30/charts点击查看免费下载相关推荐在 Kubernetes 上部署 Discourse 论坛Bitnami Helm Chart 完整实战指南在 Kubernetes 上部署 Discourse 论坛Bitnami Helm Chart 完整实战指南 Discourse 是一款自带版主与治理机制的开云原生容器编排在 Kubernetes 上部署 Grafana TempoBitnami Helm Chart 实战指南在 Kubernetes 上部署 Grafana TempoBitnami Helm Chart 实战指南 Grafana Tempo 是一个与 Grafan云原生容器编排使用 Helm Chart 在 Kubernetes 上部署 ToolJet安装、配置与升级完整指南使用 Helm Chart 在 Kubernetes 上部署 ToolJet安装、配置与升级完整指南 Helm 是 Kubernetes 生态中最常用的应用打低代码后端前端AI 应用MCP 服务上一篇univerjs/ui 包深度解析Univer 共享 UI 框架、工作台服务与 Facade UI API 完全指南下一篇Stable-Baselines3 版本演进全解析从 0.1.0 到 2.9.0 的关键变更、破坏性更新与升级指南创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表