ARTICLE DETAIL

资讯详情

深耕编程入门与网站建设的一线实战洞察。

Kubernetes Helm 部署 Logstash 实践:基于 incubator/logstash 图表的多管道配置与持久化队列指南

Kubernetes Helm 部署 Logstash 实践:基于 incubator/logstash 图表的多管道配置与持久化队列指南 【免费下载链接】charts⚠️(OBSOLETE) Curated applications for Kubernetes项目地址https://gitcode.com/gh_mirrors/chart/charts点击查看免费下载本篇技术指南以当前开源仓库中的 incubator/logstash/README.md 为核心主体结合 values.yaml 与 templates 目录下的源码实现系统讲解如何在 Kubernetes 中通过 Helm 部署 Logstash 数据管道包括快速安装与卸载、多管道最佳实践、Beats Input → Elasticsearch Output 的默认管道设计、持久化队列与监控配置。读者读完本文后可以独立完成 Logstash 图表的安装调优并理解其内部 ConfigMap 配置生成、StatefulSet 挂载与探针机制。说明该图表位于仓库incubator目录下其 Chart.yaml 中标注deprecated: true且版本为0.9.6appVersion6.4.2官方说明图表已弃用并迁移至 stable/logstash。本文基于仓库内实际存在的孵化版图表进行讲解供理解与历史参考使用。Logstash 与 Kubernetes 部署背景Logstash 是 Elastic 开源的服务器端数据处理管道能够从多种来源同时摄取数据经过过滤转换后发送到目标存储stash。在 Kubernetes 环境中使用 Helm 图表可以将 Logstash 的 StatefulSet、Service、ConfigMap、持久化存储等资源一键部署并统一管理。本仓库中的incubator/logstash图表以 StatefulSet 形式运行 Logstash而非 Deployment这与持久化队列、滚动更新和数据卷管理需求高度匹配。其镜像默认使用docker.elastic.co/logstash/logstash-oss:6.4.2为 OSS 开源版本。快速安装与卸载安装最简单的方式使用默认配置直接安装$ helm install incubator/logstash使用指定 release 名称my-release安装$ helm install --name my-release incubator/logstash图表默认创建以下 Kubernetes 资源对应 templates 目录StatefulSetstatefulset.yamlServiceservice.yamlPodDisruptionBudgetpoddisruptionbudget.yaml管道与模式 ConfigMappipeline-config.yaml、patterns-config.yaml可选 Ingressingress.yaml卸载删除my-release部署$ helm delete my-release该命令会移除与图表关联的几乎所有 Kubernetes 组件并删除该 release。需要注意的是如果启用了持久化PVC 的保留策略取决于集群的回收策略配置数据卷本身需要结合集群管理方式进行后续处理。最佳实践多管道与默认管道设计一个 release 对应一个管道Logstash 支持在同一实例中配置多条管道但该图表当前的最佳实践是为每条管道单独维护一个 chart release。这样做的收益是配置更简化——每个 release 的inputs、filters、outputs各自独立管道之间相互隔离——单条管道的配置变更或故障不会影响其他管道资源配额、持久化卷和监控指标可以按管道维度独立规划。这一建议同样体现在 values.yaml 的注释中To achieve multiple pipelines with this chart, current best practice is to maintain one pipeline per chart release.默认管道Beats Input → Elasticsearch Output针对 ELK 日志场景当前推荐的日志采集链路是使用 Filebeat 从宿主机采集日志并发送到 Logstash同时启用持久化队列以增强可靠性。Filebeat 同时支持结构化如 JSON与非结构化如普通日志行日志的传输。图表默认配置的管道为input { beats { port 5044 } } output { elasticsearch { hosts [${ELASTICSEARCH_HOST}:${ELASTICSEARCH_PORT}] manage_template false index %{[metadata][beat]}-%{YYYY.MM.dd} document_type %{[metadata][type]} } }关键点解读Beats Input 端口 5044默认监听 TCP 5044 端口接收 Filebeat 等 Beats 家族数据环境变量注入ELASTICSEARCH_HOST与ELASTICSEARCH_PORT由 StatefulSet 模板从values.yaml的elasticsearch.host/elasticsearch.port注入见 statefulset.yaml默认指向elasticsearch-client.default.svc.cluster.local:9200manage_template falseLogstash 不自行管理索引模板而是依赖预先加载的 Beats 索引模板详见下文动态索引命名%{[metadata][beat]}-%{YYYY.MM.dd}按 Beat 类型与日期分索引便于后续生命周期管理。将 Beats 生成的索引模板加载到 Elasticsearch为了充分利用 Beats、Logstash、Elasticsearch 的组合能力需要将 Beats 生成的索引模板预先加载到 Elasticsearch 中详细说明见官方 Filebeat 模板文档。在 Kubernetes 集群外的一台 Linux 实例上可执行类似命令Elasticsearch 主机名按实际情况替换filebeat setup --template -E output.logstash.enabledfalse \ -E output.elasticsearch.hosts[elasticsearch.cluster.local:9200]该命令通过filebeat setup子命令生成并注册索引模板同时显式关闭 Logstash 输出output.logstash.enabledfalse指定直接写入的 Elasticsearch 地址。由于管道输出端设置了manage_template false索引映射与字段类型将完全由该预加载模板决定保证 Beats 写入字段与 Elasticsearch 索引映射的一致性。配置参数详解以下是图表可配置参数及其默认值总表对应 README.md 的 Configuration 章节参数描述默认值replicaCount副本数量1podDisruptionBudgetPod 中断预算maxUnavailable: 1updateStrategy更新策略type: RollingUpdateimage.repository容器镜像名docker.elastic.co/logstash/logstash-ossimage.tag镜像标签6.4.2image.pullPolicy镜像拉取策略IfNotPresentservice.typeService 类型ClusterIP/NodePort/LoadBalancerClusterIPservice.annotationsService 注解{}service.portsService 暴露端口beatsservice.loadBalancerIPService 的负载均衡器 IP未设置service.clusterIPService 集群 IP未设置portsLogstash 容器暴露端口beatsingress.enabled是否启用 Ingressfalseingress.annotationsIngress 注解{}ingress.pathIngress 路径/ingress.hostsIngress 接受的域名[logstash.cluster.local]ingress.tlsIngress TLS 配置[]resourcesPod 资源请求与限制{}nodeSelector节点选择器{}tolerations容忍度[]affinity亲和 / 反亲和{}podAnnotationsPod 注解{}podLabelsPod 标签{}livenessProbeLogstash 容器存活探针见values.yamlreadinessProbeLogstash 容器就绪探针见values.yamlpersistence.enabled是否启用持久化truepersistence.storageClassPVC 存储类未设置persistence.accessModePVC 访问模式ReadWriteOncepersistence.sizePVC 大小2GivolumeMountsLogstash 容器卷挂载见values.yamlvolumes额外配置的卷[]terminationGracePeriodSecondsPod 优雅终止时长30exporter.logstashPrometheus logstash-exporter 设置见values.yamlexporter.logstash.enabled是否启用 Prometheus logstash-exporterfalseelasticsearch.hostElasticsearch 主机名elasticsearch-client.default.svc.cluster.localelasticsearch.portElasticsearch 端口9200configLogstash 配置键值对见values.yamlpatternsLogstash 模式grok pattern配置nilinputsLogstash inputs 配置beatsfiltersLogstash filters 配置niloutputsLogstash outputs 配置elasticsearch管道配置机制ConfigMap 生成与挂载inputs / filters / outputs 如何变成管道文件图表将inputs、filters、outputs三个 values 区块渲染为管道 ConfigMap。从 pipeline-config.yaml 可以看出生成逻辑遍历.Values.inputs生成input_{{ $key }}条目遍历.Values.filters生成filter_{{ $key }}条目遍历.Values.outputs生成output_{{ $key }}条目。默认情况下只有一个键main即inputs.main、outputs.main。该 ConfigMap 通过 StatefulSet 挂载到/usr/share/logstash/pipeline见 statefulset.yaml 中的 volumes 定义与 values.yaml 的volumeMounts。同时config中的path.config: /usr/share/logstash/pipeline指向该挂载目录且config.reload.automatic: true开启了配置热加载——这意味着管道 ConfigMap 更新后Logstash 可以自动重载配置而无需重启 Pod。patterns自定义 grok 模式patterns区块用于为过滤器提供自定义模式文件每个 YAML heredoc 会生成一个独立的模式文件patterns: main: |- TESTING {foo:.*}$该配置渲染为独立的 patterns ConfigMap见 patterns-config.yaml挂载到/usr/share/logstash/patterns。StatefulSet 的 Pod 注解中带有checksum/patterns与checksum/pipeline基于 ConfigMap 内容的 sha256 哈希见 statefulset.yaml当模式或管道配置变更时自动触发 Pod 滚动更新保证配置与运行实例一致。状态同步与滚动更新StatefulSet 采用RollingUpdate更新策略Pod 注解中的两个 checksum 值用于追踪 ConfigMap 变更。这一机制确保管道/模式配置变化时Kubernetes 会重建 Pod 以加载新配置配合config.reload.automatic双保险兼顾配置变更的即时性与一致性。持久化队列保障数据可靠性的关键Logstash 的持久化队列persistent queue是 ELK 日志链路高可用的基础能力。图表默认启用持久化并做了对应配置见 values.yamlconfig: config.reload.automatic: true path.config: /usr/share/logstash/pipeline path.data: /usr/share/logstash/data queue.checkpoint.writes: 1 queue.drain: true queue.max_bytes: 1gb # disk capacity must be greater than the value of queue.max_bytes queue.type: persisted要点解读queue.type: persisted启用持久化队列事件在写入队列后即视为已接收即使 Logstash 进程崩溃或重启也不会丢失queue.checkpoint.writes: 1每写入 1 个事件即触发一次检查点checkpoint在性能与可靠性之间取得平衡——牺牲部分写性能换取更低的数据丢失风险queue.drain: true关闭时先排空队列中的事件再退出配合terminationGracePeriodSeconds: 30实现优雅关闭queue.max_bytes: 1gb队列最大容量 1GB磁盘容量必须大于该值。持久化存储实现这些配置依赖持久化数据卷statefulset.yaml默认persistence.enabled: true通过volumeClaimTemplates为每个副本动态创建名为data的 PVC默认存储大小为2Gi访问模式ReadWriteOncepersistence.storageClass未设置时使用集群默认 provisionerAWS 的 gp2、GKE 的 standard 等设置为-时禁用动态供给storageClassName: 若关闭持久化persistence.enabled: falsedata卷退化为emptyDir队列数据随 Pod 销毁而丢失数据挂载至/usr/share/logstash/data与path.data配置对应。健康探针与安全上下文存活 / 就绪探针图表默认通过 Logstash 监控 API 进行健康检查values.yamllivenessProbe: httpGet: path: / port: monitor initialDelaySeconds: 20 readinessProbe: httpGet: path: / port: monitor initialDelaySeconds: 20探针访问的是名为monitor的端口其容器端口取exporter.logstash.target.port默认9600见 statefulset.yaml并通过HTTP_HOST0.0.0.0、HTTP_PORT9600环境变量开启 Logstash 监控 API。periodSeconds、timeoutSeconds、failureThreshold、successThreshold均可在 values 中按需调整。安全上下文StatefulSet 设置securityContextrunAsUser: 1000、fsGroup: 1000与 Logstash OSS 镜像默认用户一致确保对持久化卷的读写权限正确。若需拉取私有镜像可通过image.pullSecrets引用已创建的 Kubernetes Secret。服务暴露与 IngressService 配置默认 Service 类型为ClusterIPservice.yaml暴露beats端口5044/TCP。values 中预置了扩展示例可选syslog-udp: 1514/UDP与syslog-tcp: 1514/TCP可选http: 8080/TCP可选loadBalancerIP指定负载均衡 IP适用于 LoadBalancer 类型Service 注解可配置 AWS 负载均衡相关参数如内部负载均衡、跨可用区负载均衡或 external-dns 主机名。容器端口ports与 Service 端口一一对应targetPort: beats指向容器端口5044需同步扩展。Ingress图表可选启用 Ingress默认关闭ingress: enabled: false path: / hosts: - logstash.cluster.local tls: []启用后由 ingress.yaml 生成 Ingress 资源支持配置 TLS 证书secretNamehosts与常用注解如kubernetes.io/ingress.class: nginx、kubernetes.io/tls-acme: true。适合通过 HTTP Input 暴露日志接收端点或提供管理访问的场景。监控集成 Prometheus logstash-exporter图表内置了 Prometheus 指标暴露支持默认关闭exporter: logstash: enabled: false image: repository: bonniernews/logstash_exporter tag: v0.1.2 pullPolicy: IfNotPresent path: /metrics port: 9198 target: port: 9600 path: /metrics启用后StatefulSet 会以 sidecar 容器方式运行bonniernews/logstash_exporterstatefulset.yaml其启动参数为sleep 60; exec /logstash_exporter --logstash.endpointhttp://localhost:9600 --web.listen-address:9198要点sleep 60延迟 60 秒启动等待 Logstash 监控 API 就绪采集目标从http://localhost:9600Logstash 监控 API拉取指标暴露端口exporter 自身监听9198路径/metricsPod 注解配合prometheus.io/scrape: true、prometheus.io/path: /metrics、prometheus.io/port: 9198见 values 中podAnnotations注释示例即可接入 Prometheus 采集。exporter 的存活/就绪探针默认periodSeconds: 15、timeoutSeconds: 60、failureThreshold: 8可从 values 中调整。资源调度与弹性配置资源限制resources默认留空推荐在生产环境显式声明resources: limits: cpu: 100m memory: 128Mi requests: cpu: 100m memory: 128Mi图表设计上不预设默认资源以便在 Minikube 等资源紧张环境顺利运行实际部署时应根据管道负载与queue.max_bytes评估内存需求持久化队列数据落盘于/usr/share/logstash/data内存占用与队列缓冲相关。调度策略nodeSelector将 Pod 调度到特定标签节点tolerations容忍节点污点affinity支持 Pod 反亲和例如将同一 release 的多个副本分布到不同节点affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - topologyKey: kubernetes.io/hostname labelSelector: matchLabels: release: logstash自定义输入输出扩展管道能力图表默认管道是 Beats → Elasticsearch但通过 values 可以灵活扩展。例如在inputs.main中追加 Kafka 输入values 注释中给出了参考配置input { kafka { bootstrap_servers kafka-input:9092 codec json { charset UTF-8 } consumer_threads 1 topics [source] type example } }对应地在outputs.main中切换为 Kafka 输出output { kafka { bootstrap_servers kafka-output:9092 codec json { charset UTF-8 } compression_type lz4 topic_id destination } }同时需要同步扩展service.ports与ports以暴露对应端口如 syslog 的 1514、http 的 8080。如需自定义 grok 模式则通过patterns区块提供。所有管道改动以 ConfigMap 形式下发借助 checksum 注解自动滚动更新。验证与排查建议查看 Pod 状态与日志kubectl get pods -l releasemy-release、kubectl logs pod-name验证管道配置进入 Pod 查看挂载的管道文件kubectl exec pod-name -- cat /usr/share/logstash/pipeline/input_main.conf测试 Beats 端口确认 Service 与容器端口 5044 是否可连通检查队列状态通过 Logstash 监控 API9600 端口查询logstash/pipeline与队列指标观察滚动更新修改inputs/outputs/patterns后通过kubectl rollout status statefulset name观察更新过程。总结本图表为 Kubernetes 中运行 Logstash 提供了完整的 Helm 封装以 StatefulSet 持久化队列保障日志链路可靠性以 ConfigMap 机制实现管道配置的声明式管理与热加载以可选的 logstash-exporter 打通 Prometheus 监控并围绕一个 release 一条管道的最佳实践将多管道隔离问题简化。在基于当前仓库版本部署时建议优先参考迁移后的 stable/logstash 图表获取持续维护的版本同时本文所阐述的管道设计、持久化队列与配置注入机制在两类图表间具有一致的原理参考价值。赞分享【免费下载链接】charts⚠️(OBSOLETE) Curated applications for Kubernetes项目地址https://gitcode.com/gh_mirrors/chart/charts点击查看免费下载相关推荐OneUptime Runner AI 修复实战把未解决异常变成一个可评审的 Pull RequestOneUptime Runner AI 修复实战把未解决异常变成一个可评审的 Pull Request 本文基于 OneUptime 仓库中文档 App/Fecommand-pathcommand path Generated from gog schema json . Do not edit this page by hand; runotepad-- 完整使用指南跨平台文本编辑器、文件对比与目录级批量查找替换快速上手notepad 完整使用指南跨平台文本编辑器、文件对比与目录级批量查找替换快速上手 notepad 也写作 Ndd是一款来自中国的开源跨平台文本编辑器基桌面应用创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表