教程云原生容器编排【免费下载链接】kubernetes-handbookKubernetes 架构与生态从云原生到 AI 原生基础设施的构建指南项目地址https://gitcode.com/gh_mirrors/ku/kubernetes-handbook点击查看免费下载在 Kubernetes 集群中收集应用日志官方 EFK 方案并非唯一选择。本篇技术指南以 practice/app-log-collection.md 为核心讲解如何在每个 Pod 中以 Sidecar 方式运行轻量级日志采集组件 Filebeat将应用日志送入团队自有的 ELKElasticsearch Logstash Kibana集群。读完本文你将掌握 Kubernetes 日志收集的三种架构模式及其取舍、Filebeat Sidecar 方案的完整 YAML 编写方法ConfigMap 与环境变量两种配置方式以及如何在 Kibana 中验证日志索引与字段。背景为什么放弃 Logstash改用 Filebeat在 Kubernetes 环境中设计日志收集方案时Logstash 往往是第一选择——它是 ELK stack 中的重要成员功能强大且生态成熟。但 Logstash 基于 JDK 运行资源开销十分可观。团队在测试中发现在没有产生任何日志的情况下单纯启动 Logstash 就大约消耗 500M 内存。如果每个 Pod 中都启动一个日志收集组件这个资源开销显然难以接受。经过测试对比团队改用Filebeat替代 Logstash单独启动一个 Filebeat 容器大约只消耗12M 内存相较 Logstash 相当轻量级非常适合以 Sidecar 模式与业务容器同 Pod 部署。方案选型官方 EFK 的局限与三种收集架构对比Kubernetes 官方提供了 EFKElasticsearch Fluentd Kibana日志收集解决方案但该方案并不适合所有业务场景存在以下局限性所有日志必须是 stdout 前台输出而真实业务场景中无法保证所有日志都在前台输出只能有一个日志输出文件而真实业务场景中往往有多个日志输出文件Fluentd 并不是常用的日志收集工具团队更习惯用 Logstash现改用 Filebeat 替代团队已有自己的 ELK 集群且有专人维护没有必要再在 Kubernetes 上重复搭建日志收集服务。基于以上原因最终决定复用自有的 ELK 集群。Kubernetes 集群中的日志收集解决方案主要有三种对比如下编号方案优点缺点1每个 app 的镜像中都集成日志收集组件部署方便kubernetes 的 yaml 文件无须特别配置可以为每个 app 自定义日志收集配置强耦合不方便应用和日志收集组件升级和维护且会导致镜像过大2单独创建一个日志收集组件跟 app 的容器一起运行在同一个 Pod 中低耦合扩展性强方便维护和升级需要对 kubernetes 的 yaml 文件进行单独配置略显繁琐3将所有的 Pod 的日志都挂载到宿主机上每台主机上单独起一个日志收集 Pod完全解耦性能最高管理起来最方便需要统一日志收集规则、目录和输出方式综合优缺点团队选择方案二Filebeat 作为 Sidecar 容器与业务容器共享同一个 Pod。该方案在扩展性、个性化、部署和后期维护方面都能做到均衡。该方案的基本思路是业务应用将日志写入 Pod 内的共享卷如 emptyDirFilebeat 容器挂载同一卷并监听其中的日志文件再通过output.elasticsearch将日志发送到自有 ELK 集群。Filebeat 镜像由团队自行构建可直接使用公开源码构建镜像。实战以 Filebeat 为 Sidecar 的日志收集测试完整 YAMLDeployment Service ConfigMap创建应用 YAML 文件filebeat-test.yaml完整内容如下该文件可以在 manifests/test/filebeat-test.yaml 找到apiVersion: extensions/v1beta1 kind: Deployment metadata: name: filebeat-test namespace: default spec: replicas: 3 template: metadata: labels: k8s-app: filebeat-test spec: containers: - image: harbor-001.jimmysong.io/library/filebeat:5.4.0 name: filebeat volumeMounts: - name: app-logs mountPath: /log - name: filebeat-config mountPath: /etc/filebeat/ - image: harbor-001.jimmysong.io/library/analytics-docker-test:Build_8 name : app ports: - containerPort: 80 volumeMounts: - name: app-logs mountPath: /usr/local/TalkingData/logs volumes: - name: app-logs emptyDir: {} - name: filebeat-config configMap: name: filebeat-config --- apiVersion: v1 kind: Service metadata: name: filebeat-test labels: app: filebeat-test spec: ports: - port: 80 protocol: TCP name: http selector: run: filebeat-test --- apiVersion: v1 kind: ConfigMap metadata: name: filebeat-config data: filebeat.yml: | filebeat.prospectors: - input_type: log paths: - /log/* - /log/usermange/common/* output.elasticsearch: hosts: [172.23.5.255:9200] username: elastic password: changeme index: filebeat-docker-test配置说明核心要点Pod 内同时运行filebeat和app两个容器通过共享的app-logsemptyDir: {}卷实现日志传递app 将日志写入/usr/local/TalkingData/logsFilebeat 在/log目录下读取Filebeat 的配置文件通过filebeat-config这个 ConfigMap 挂载到/etc/filebeat/目录下因此不需要再定义环境变量filebeat.yml中使用filebeat.prospectors定义日志探测规则input_type: log表示读取日志文件paths支持配置多个日志路径如/log/*与/log/usermange/common/*output.elasticsearch指定输出目标hosts为自有 ELK 集群中 Elasticsearch 的地址172.23.5.255:9200可配置username/password认证index用于指定写入的索引名此处为filebeat-docker-testService 的 selector 使用run: filebeat-test与 Deployment 中 pod template 的 labelk8s-app: filebeat-test并不一致实际测试以kubectl命令创建的 Deployment 为准请以你部署时实际的 selector 配置为准。备选方案通过环境变量配置 Filebeat如果不使用 ConfigMap也可以通过传统方式传递环境变量来配置 Filebeat。例如对 Filebeat 容器进行如下配置containers: - image: harbor-001.jimmysong.io/library/filebeat:5.4.0 name: filebeat volumeMounts: - name: app-logs mountPath: /log env: - name: PATHS value: /log/* - name: ES_SERVER value: 172.23.5.255:9200 - name: INDEX value: logstash-docker - name: INPUT_TYPE value: log这种方式的局限在于PATHS只能传递单个目录。如果想传递多个目录需要修改 Filebeat 镜像的docker-entrypoint.sh脚本对该环境变量进行解析从而扩展 filebeat.yml 文件中的 PATHS 列表。因此推荐优先使用ConfigMap方式使 Filebeat 的配置更加灵活。注意事项将 app 的/usr/local/TalkingData/logs目录挂载到 Filebeat 的/log目录下该文件可以在 manifests/test/filebeat-test.yaml 找到文中使用了私有镜像仓库harbor-001.jimmysong.io测试时请换成自己的应用镜像与 Filebeat 镜像Filebeat 环境变量的取值可参考自建镜像的入口脚本约定确保环境变量名与镜像内的解析逻辑一致。部署与验证创建应用部署 Deploymentkubectl create -f filebeat-test.yaml验证 Elasticsearch 索引查看http://172.23.5.255:9200/_cat/indices可以看到如下类似的索引green open filebeat-docker-test 7xPEwEbUQRirk8oDX36gAA 5 1 2151 0 1.6mb 841.8kb其中filebeat-docker-test即为 YAML 文件中 ConfigMap 里配置的index值。在 Kibana 中查看日志访问 Kibana 的 Web 页面查看filebeat-2017.05.17索引可以看到 Filebeat 已成功收集到 app 日志点开每个日志条目可以看到以下详细字段_index值即我们在 YAML 文件的 ConfigMap 中配置的 index 值beat.hostname和beat.name即 Pod 的名称source表示 Filebeat 容器中的日志目录。实用技巧让 index 与 Service 名称对应可以通过人为地使indexservice name这样就可以方便地收集和查看每个 Service 的日志实现按业务维度对日志进行隔离和检索。仓库源码佐证Manifest 与 EFK 方案的对比仓库中的测试 Manifest本仓库在 manifests/test/filebeat-test.yaml 中保留了完整的测试文件共 64 行包含 Deployment、Service、ConfigMap 三个资源对象。与文中示例相比仓库版本将index配置为filebeat-testService 的 selector 为k8s-app: filebeat-test其他结构与示例一致。此外在 develop/client-go-sample.md 中还可以看到该filebeat-testDeployment 的实际滚动更新演练当镜像从analytics-docker-test:Build_9回退到Build_8时ReplicaSet 经历了一次缩容/扩容过程验证了应用镜像 Filebeat Sidecar组合在发布流程中的可操作性。与官方 EFK 方案的对比fluentd-es-ds.yaml官方 EFK 方案使用 DaemonSet 在每个 Node 上运行一个 Fluentd 收集宿主机日志见 manifests/EFK/fluentd-es-ds.yamlspec: serviceAccountName: efk containers: - name: fluentd-es image: harbor-001.jimmysong.io/library/fluentd-elasticsearch:1.22 resources: limits: memory: 200Mi requests: cpu: 100m memory: 200Mi volumeMounts: - name: varlog mountPath: /var/log - name: varlibdockercontainers mountPath: /var/lib/docker/containers readOnly: true volumes: - name: varlog hostPath: path: /var/log - name: varlibdockercontainers hostPath: path: /var/lib/docker/containers从该 Manifest 可以看出两种方案的差异部署形态EFK 方案每个 Node 只运行一个 FluentdDaemonSet依赖hostPath挂载宿主机/var/log与/var/lib/docker/containers只能采集 stdout 前台输出且统一路径的日志而 Filebeat Sidecar 方案与业务容器同生命周期天然支持多日志文件、多目录paths列表与自定义采集规则资源占用EFK 方案中单个 Fluentd Pod 的 requests 内存即为 200Mi而 Filebeat 单独启动仅约 12M 内存按 Pod 数量部署时的资源开销优势明显配置灵活度Filebeat 通过 ConfigMap 注入filebeat.yml采集路径、输出地址、索引名称均可按应用个性化配置适合业务日志形态多样的场景。完整的 EFK 插件安装过程含 Elasticsearch/Kibana 部署、Node 打标签beta.kubernetes.io/fluentd-ds-readytrue、RBAC 配置与 Kibana 访问方式参见 practice/efk-addon-installation.md。延伸Pod 销毁时日志丢失问题的规避思路Filebeat Sidecar 方案存在一个边界场景当 Pod 被销毁时如果 Filebeat 尚未收集完 Pod 内的日志会产生数据丢失。本仓库的 practice/data-persistence-problem.md 针对该问题给出了解决思路将应用日志持久化挂载到宿主机再由宿主机上的日志收集组件Logstash 或 Filebeat采集从而保证数据不丢失。这说明在实际生产环境中可以组合使用两种方案对实时性要求高、日志量小的应用采用本文的 Filebeat Sidecar 方案方案二对日志需要持久化、不能容忍丢失的应用采用宿主机挂载 独立收集 Pod 的方案方案三。总结本文从资源开销对比出发梳理了 Kubernetes 日志收集的三种架构模式并给出了基于自有 ELK Filebeat Sidecar方案的完整落地过程通过共享卷emptyDir打通业务容器与 Filebeat 的日志通道通过 ConfigMap 灵活配置采集路径与 Elasticsearch 输出并通过index service name的命名约定实现按 Service 维度的日志检索。结合仓库中的 manifests/test/filebeat-test.yaml 与 manifests/EFK/fluentd-es-ds.yaml 对比可以清晰理解 Sidecar 模式与官方 EFK DaemonSet 模式各自的适用场景为生产环境日志收集方案选型提供直接参考。赞分享教程云原生容器编排【免费下载链接】kubernetes-handbookKubernetes 架构与生态从云原生到 AI 原生基础设施的构建指南项目地址https://gitcode.com/gh_mirrors/ku/kubernetes-handbook点击查看免费下载相关推荐Aptos 集群日志收集实战基于 Helm 与 Vector DaemonSet 的 Kubernetes 日志管道搭建指南Aptos 集群日志收集实战基于 Helm 与 Vector DaemonSet 的 Kubernetes 日志管道搭建指南 导读 本文面向在 Kuberne区块链Web3Collabnix Kubelabs 项目Filebeat 作为 Sidecar 容器的日志收集方案Collabnix Kubelabs 项目Filebeat 作为 Sidecar 容器的日志收集方案 引言Kubernetes 日志收集的挑战与机遇 在现代示例工程教程文档如何快速使用linefit_ground_segmentation从零开始的激光雷达地面分割完整教程如何快速使用linefit_ground_segmentation从零开始的激光雷达地面分割完整教程 linefit_ground_segmentation是自动驾驶计算机视觉创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考