尧图网络 高端网站定制 · 原创设计
免费咨询热线
400-888-6620
免费获取方案
90DaysOfDevOps:使用 EFK Stack(Elasticsearch + Fluentd + Kibana)监控 Kubernetes 日志实战
文档/教程【免费下载链接】90DaysOfDevOpsThis repository started out as a learning in public project for myself and has now become a structured learning map for many in the community. We have 3 years under our belt covering all things DevOps, including Principles, Processes, Tooling and Use Cases surrounding this vast topic.项目地址https://gitcode.com/gh_mirrors/90/90DaysOfDevOps点击查看免费下载本文是 90DaysOfDevOps 可观测性系列的实战篇章对应仓库中的 2022/vi/Days/day82.md以 Minikube 集群为载体完整演示如何在 Kubernetes 中部署 EFK StackElasticsearch Fluentd Kibana用于统一采集、存储与可视化集群日志。读完本文你将掌握 EFK 三大组件的分工与部署形态、官方 YAML 清单的每一段配置含义、从minikube start到 Kibana 日志可视化的完整操作链路并能在此基础上扩展接入 APM、指标与安全事件等更多数据源。EFK 是什么从 ELK 到 EFK 的演进上一篇文章Fluentd FluentBitDay 81中我们探讨了统一日志采集层更早的章节则介绍了以 Logstash 作为日志采集器的 ELK Stack。EFK Stack 与 ELK Stack 的唯一区别在于将采集器从 Logstash 替换为 Fluentd或 FluentBit其余两个核心组件保持一致。在 EFK 中我们用更轻量、更贴近 Kubernetes 生态的 Fluentd 来完成日志的采集、过滤、缓冲与转发。EFK Stack 由三款软件捆绑协作组成ElasticsearchNoSQL 数据库负责存储日志数据并提供搜索与查询日志的接口HTTP 9200 端口。Fluentd开源数据采集器构建统一日志层unified logging layer允许你统一数据的采集与消费从而更好地使用和理解数据Fluentd 通过插件机制把任意数据源的数据转发到任意目标端。Kibana日志管理与统计的可视化界面负责从 Elasticsearch 读取信息并以图表、表格、地图等形式呈现。下面这张架构图展示了我们即将在 Kubernetes 集群中部署的目标形态Elasticsearch 以 StatefulSet 运行、Kibana 以 Deployment 运行、Fluentd 以 DaemonSet 在每个节点上运行。部署前提启动 Minikube 集群本次实践沿用前文一直在使用的 Minikube 集群。在你的系统上执行minikube start示例环境为启用了 WSL2 的 Windows 系统Minikube 会基于 Docker 驱动拉起控制平面并完成集群配置。若你的机器此前已运行过该集群或已提前拉取镜像后续部署会明显加快。这一步完成后我们就拥有了一个可供部署 EFK 的本地 Kubernetes 环境。核心配置清单efk-stack.yaml 逐段解析仓库中提供了本次部署所需的全部清单文件 efk-stack.yaml该文件是一个多文档 YAML依次定义了 Namespace、Service、PersistentVolume、StatefulSet、Deployment、ServiceAccount、ClusterRole、ClusterRoleBinding 与 DaemonSet 共 9 类资源。下面按部署顺序逐段拆解。1. 命名空间 kube-loggingkind: Namespace apiVersion: v1 metadata: name: kube-logging所有 EFK 组件统一收纳在kube-logging命名空间下便于资源隔离与后续的权限管理、清理。2. Elasticsearch 无头服务Headless Servicekind: Service apiVersion: v1 metadata: name: elasticsearch namespace: kube-logging labels: app: elasticsearch spec: selector: app: elasticsearch clusterIP: None # 渲染为 Headless Service ports: - port: 9200 name: rest # REST 查询接口 - port: 9300 name: inter-node # 节点间通信接口关键点clusterIP: None将服务声明为Headless Service它不分配 ClusterIP而是为每个后端 Pod 提供独立的 DNS 域名形如es-cluster-0.elasticsearch。StatefulSet 正是依赖该 DNS 域实现集群节点间的稳定发现与通信。3. 持久化卷与数据目录kind: PersistentVolume metadata: name: data labels: type: elasticsearch spec: storageClassName: standard capacity: storage: 50Gi accessModes: - ReadWriteMany hostPath: path: /mnt/data清单先声明了一个基于hostPath的 PersistentVolume容量 50Gi存储类standard用于承载 Elasticsearch 数据随后 StatefulSet 内部又通过volumeClaimTemplates为每个副本动态申请 PVC每副本 5Gi、ReadWriteOnce。对 Minikube 这类本地环境而言hostPath 已足够支撑演示。4. Elasticsearch StatefulSet3 副本apiVersion: apps/v1 kind: StatefulSet metadata: name: es-cluster namespace: kube-logging spec: serviceName: elasticsearch replicas: 3 selector: matchLabels: app: elasticsearch template: metadata: labels: app: elasticsearch spec: containers: - name: elasticsearch image: docker.elastic.co/elasticsearch/elasticsearch:7.2.0 resources: limits: cpu: 1000m requests: cpu: 100m ports: - containerPort: 9200 name: rest protocol: TCP - containerPort: 9300 name: inter-node protocol: TCP volumeMounts: - name: data mountPath: /usr/share/elasticsearch/data env: - name: cluster.name value: k8s-logs - name: node.name valueFrom: fieldRef: fieldPath: metadata.name - name: discovery.seed_hosts value: es-cluster-0.elasticsearch,es-cluster-1.elasticsearch,es-cluster-2.elasticsearch - name: cluster.initial_master_nodes value: es-cluster-0,es-cluster-1,es-cluster-2 - name: ES_JAVA_OPTS value: -Xms512m -Xmx512m值得注意的配置细节discovery.seed_hosts显式列出三个候选节点的 DNS 域名依托前面 Headless Service 生成的域名Elasticsearch 7.x 借此完成节点发现cluster.initial_master_nodes指定初始 master 候选节点避免集群启动时出现脑裂node.name通过fieldRef: metadata.name动态取 Pod 名确保每个副本拥有唯一节点名ES_JAVA_OPTS-Xms512m -Xmx512m固定堆内存为 512MB防止容器被宿主机内存拖垮是资源受限的 Minikube 环境下运行 ES 的关键调优项数据目录挂载在/usr/share/elasticsearch/data与镜像默认路径一致。initContainers解决 Elasticsearch 的三大启动前置条件initContainers: - name: fix-permissions image: busybox command: [sh, -c, chown -R 1000:1000 /usr/share/elasticsearch/data] securityContext: privileged: true volumeMounts: - name: data mountPath: /usr/share/elasticsearch/data - name: increase-vm-max-map image: busybox command: [sysctl, -w, vm.max_map_count262144] securityContext: privileged: true - name: increase-fd-ulimit image: busybox command: [sh, -c, ulimit -n 65536] securityContext: privileged: trueElasticsearch 容器默认以 UID 1000 运行直接挂载 hostPath 卷会因权限不足而无法写入因此第一个 initContainer 用chown修正数据目录属主ES 还要求宿主机满足vm.max_map_count与文件描述符上限两个内核级条件后两个 initContainer 分别通过sysctl与ulimit在容器内提前设置。三个初始化容器均在主容器启动前串行完成是保证 3 副本 StatefulSet 稳定拉起的关键设计。5. Kibana Service 与 Deploymentkind: Service metadata: name: kibana namespace: kube-logging labels: app: kibana spec: ports: - port: 5601 selector: app: kibana --- apiVersion: apps/v1 kind: Deployment metadata: name: kibana namespace: kube-logging labels: app: kibana spec: replicas: 1 selector: matchLabels: app: kibana template: metadata: labels: app: kibana spec: containers: - name: kibana image: docker.elastic.co/kibana/kibana:7.2.0 resources: limits: cpu: 1000m requests: cpu: 100m env: - name: ELASTICSEARCH_URL value: http://elasticsearch:9200 ports: - containerPort: 5601Kibana 以 Deployment 方式部署 1 个副本对外暴露 5601 端口通过环境变量ELASTICSEARCH_URLhttp://elasticsearch:9200指向命名空间内的 Elasticsearch Service完成与存储层的对接。6. Fluentd 的 RBAC 与 DaemonSetFluentd 需要读取集群中每个 Pod 的日志与 Kubernetes API 元数据因此必须先创建 ServiceAccount、ClusterRole 与 ClusterRoleBindingapiVersion: v1 kind: ServiceAccount metadata: name: fluentd namespace: kube-logging labels: app: fluentd --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: fluentd labels: app: fluentd rules: - apiGroups: - resources: - pods - namespaces verbs: - get - list - watch --- kind: ClusterRoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: fluentd roleRef: kind: ClusterRole name: fluentd apiGroup: rbac.authorization.k8s.io subjects: - kind: ServiceAccount name: fluentd namespace: kube-loggingClusterRole 授予pods与namespaces的get/list/watch权限这正是 Fluentd 采集容器日志并附加 Kubernetes 元数据如 Pod 名、命名空间、标签所需的最小权限集。Fluentd 本体以 DaemonSet 部署保证集群每个节点上恰好运行一个采集 PodapiVersion: apps/v1 kind: DaemonSet metadata: name: fluentd namespace: kube-logging labels: app: fluentd spec: selector: matchLabels: app: fluentd template: metadata: labels: app: fluentd spec: serviceAccount: fluentd serviceAccountName: fluentd tolerations: - key: node-role.kubernetes.io/master effect: NoSchedule containers: - name: fluentd image: fluent/fluentd-kubernetes-daemonset:v1.4.2-debian-elasticsearch-1.1 env: - name: FLUENT_ELASTICSEARCH_HOST value: elasticsearch.kube-logging.svc.cluster.local - name: FLUENT_ELASTICSEARCH_PORT value: 9200 - name: FLUENT_ELASTICSEARCH_SCHEME value: http - name: FLUENTD_SYSTEMD_CONF value: disable resources: limits: memory: 512Mi requests: cpu: 100m memory: 200Mi volumeMounts: - name: varlog mountPath: /var/log - name: varlibdockercontainers mountPath: /var/lib/docker/containers readOnly: true terminationGracePeriodSeconds: 30 volumes: - name: varlog hostPath: path: /var/log - name: varlibdockercontainers hostPath: path: /var/lib/docker/containers该 DaemonSet 的关键机制使用官方镜像fluent/fluentd-kubernetes-daemonset该镜像内置了 Elasticsearch 输出插件通过环境变量FLUENT_ELASTICSEARCH_HOST/FLUENT_ELASTICSEARCH_PORT/FLUENT_ELASTICSEARCH_SCHEME指定日志输出目标为elasticsearch.kube-logging.svc.cluster.local:9200HTTPtolerations容忍 master 节点的NoSchedule污点确保在控制平面节点上也能运行采集器以 hostPath 方式挂载/var/log与/var/lib/docker/containers从而读取宿主机上所有容器的日志文件terminationGracePeriodSeconds: 30为优雅退出预留缓冲避免 Pod 销毁时丢失尚未刷盘的日志。部署形态小结从清单可以看出三种工作负载的部署策略差异Fluentd 是 DaemonSet每个节点一个采集本节点所有容器日志、Kibana 是 Deployment单副本即可支撑可视化、Elasticsearch 是 StatefulSet3 副本稳定网络标识 独立存储保障数据一致性。这一形态同样适用于生产集群的初步落地方案。一键部署kubectl create -f efk-stack.yaml清单就绪后一条命令即可完成全部资源的创建kubectl create -f efk-stack.yaml从输出可以看到命令依次创建了上述 9 类资源。由于涉及镜像拉取Elasticsearch 7.2.0、Kibana 7.2.0、Fluentd DaemonSet 镜像以及三个 busybox initContainer首次部署需要等待几分钟。验证部署状态Pod、Service 与资源全景实时观察 Pod 就绪在部署进行中用 watch 模式持续观察 Pod 状态kubectl get pod -n kube-logging -w该命令会持续刷新直到 Pod 进入Running状态等所有 Pod 就绪后再执行一次不带-w的查询做最终确认kubectl get pod -n kube-logging全部就绪后你应当看到3 个 Pod关联 Elasticsearch对应 3 副本 StatefulSet1 个 Pod关联 Fluentd每个节点一个Minikube 单节点环境即 1 个1 个 Pod关联 KibanaDeployment 单副本。查看命名空间内全部资源kubectl get all -n kube-logging该命令列出命名空间内的 Pod、Service、StatefulSet、Deployment 与 DaemonSet可以直观印证三种工作负载的部署形态差异Fluentd 为 daemonset、Kibana 为 deployment、Elasticsearch 为 statefulset。访问 Kibana 并配置 Index Pattern端口转发所有 Pod 就绪后另开一个终端执行端口转发将 Kibana 的 5601 端口映射到本地kubectl port-forward kibana-84cf7f59c-v2l8v 5601:5601 -n kube-logging注意Pod 名是随机生成的实际命令中的名称必须替换为你环境中的真实 Pod 名可用kubectl get pods -n kube-logging查询。随后打开浏览器访问http://localhost:5601你将看到 Kibana 欢迎页若启用过示例数据则可能先看到示例数据页面可自行选择继续并配置。创建 Index Pattern要让 Kibana 认识并检索 Elasticsearch 中的日志索引需要配置 Index Pattern点击左侧菜单的Discover标签在 Index Pattern 输入框中填写*匹配全部索引点击Next step进入第二步在 2/2 步骤中从下拉框选择timestamp作为时间过滤字段——它会按时间对数据进行过滤这是日志检索最常用的时间基准点击Create pattern创建过程需要几秒钟。创建完成后几秒后切回Discover标签即可看到来自 Kubernetes 集群的日志数据持续流入。这意味着 EFK 链路已经打通Fluentd 从节点采集容器日志 → 转发到 Elasticsearch 存储与索引 → Kibana 检索展示。扩展数据源日志、指标、APM 与安全事件EFK 部署完成并非终点。点击左上角 Kibana 图标返回主页你会发现 Kibana 支持从多种插件或来源接入数据包括APM、Log data、Metric data 与 Security eventsAdd log data提供大量日志来源选项其中包含 LogstashELK Stack 的组成部分这意味着你可以在保留 EFK 主链路的同时让 Elastic Stack 家族的其他采集器也能向同一 Elasticsearch 输出日志Metrics data可为 Prometheus 及其他大量服务添加指标数据源将指标监控与日志分析统一到 Kibana 中查看。APM应用性能监控Kibana 还支持接入APMApplication Performance Monitoring它从应用内部采集深入的性能指标与错误信息允许你实时监控成千上万个应用的性能表现。APM 侧重于应用层调用链路与性能剖析与日志、指标共同构成完整的可观测性三支柱。本文不再展开 APM 的详细接入步骤你可以在 Elastic 官方站点查阅应用性能监控的完整文档原文档第 93 行给出了 Elastic 官方 APM 页面链接。小结至此我们在 Minikube 上完成了 EFK Stack 的完整落地Elasticsearch 以 3 副本 StatefulSet 提供日志存储与检索、Fluentd 以 DaemonSet 在每个节点采集容器日志并经 RBAC 授权读取 Kubernetes 元数据、Kibana 以 Deployment 提供可视化分析入口。通过kubectl create -f、kubectl get与kubectl port-forward三步命令即可在浏览器中实时查看集群日志并进一步接入 Logstash、Prometheus 与 APM 等更多数据源。本文所述配置清单可直接复用 efk-stack.yaml若想对比基于 Helm 部署 Fluent Bit 的轻量方案可回看 Fluentd FluentBit 实战Day 81日志可视化之外的指标可视化则在下一节 Grafana 数据可视化Day 83 中展开。赞分享文档/教程【免费下载链接】90DaysOfDevOpsThis repository started out as a learning in public project for myself and has now become a structured learning map for many in the community. We have 3 years under our belt covering all things DevOps, including Principles, Processes, Tooling and Use Cases surrounding this vast topic.项目地址https://gitcode.com/gh_mirrors/90/90DaysOfDevOps点击查看免费下载相关推荐3步搞定华硕主板风扇控制彻底解决FanControl传感器识别问题3步搞定华硕主板风扇控制彻底解决FanControl传感器识别问题 你是否在使用FanControl这款优秀的Windows风扇控制软件时发现华硕主板上的温文档/教程90DaysOfDevOps 实战篇在 Minikube 上部署 EFK Stack用 Elasticsearch Fluentd Kibana 统一监控 Kubernetes 日志90DaysOfDevOps 实战篇在 Minikube 上部署 EFK Stack用 Elasticsearch Fluentd Kibana 统文档/教程Kubernetes 集群日志监控实战基于 90DaysOfDevOps 在 Minikube 上部署 EFK StackElasticsearch Fluentd KibanaKubernetes 集群日志监控实战基于 90DaysOfDevOps 在 Minikube 上部署 EFK StackElasticsearch F文档/教程上一篇几何美学的革命Bebas Neue字体如何重塑现代设计语言下一篇终极指南用FanControl彻底解决Windows电脑风扇控制难题创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
RELATED

相关推荐

【关注可白嫖源码】--课程设计--毕业设计--django社区生鲜电商平台[编号:project79419](案件分析)

【关注可白嫖源码】--课程设计--毕业设计--django社区生鲜电商平台[编号:project79419](案件分析)

本文仅展示核心实现逻辑与部分代码片段,完整项目源码、配套文档、数据库脚本内容较多,篇幅有限无法全部放出。 有需要完整资源的同学,可以在评论区留言【资料或领源码】,我会一 一回复站内私信,发送完整文件 摘 要 随…

📅 2026/10/8 1:54:12
Automerge-Wasm Patch 机制完全指南:路径定位、动作类型与增量同步实战

Automerge-Wasm Patch 机制完全指南:路径定位、动作类型与增量同步实战

后端 【免费下载链接】automerge A JSON-like data structure (a CRDT) that can be modified concurrently by different users, and merged again automatically. 项目地址: https://gitcode.com/gh_mirrors/au/automerge 点击查看 免费下载 Automerge 是一个基…

📅 2026/10/8 1:54:12
rsuite Panel 组件滚动阴影(scrollShadow)深度解析:从 API 用法到源码实现原理

rsuite Panel 组件滚动阴影(scrollShadow)深度解析:从 API 用法到源码实现原理

前端UI组件 【免费下载链接】rsuite 🧱 A suite of React components . 项目地址: https://gitcode.com/gh_mirrors/rs/rsuite 点击查看 免费下载 scrollShadow 是 rsuite Panel 组件在 v5.62.0 引入的一项实用特性:当面板内容区域出现滚动…

📅 2026/10/8 1:49:12
MORE NEWS

更多资讯

📰

Ryzen AI Max NPU激活指南:让gfx1151真正驱动SnowLLM

1. 项目概述:为什么“锐龙 AI Max”在 SnowLLM 场景下成了纸面性能?你手里的那台搭载 Ryzen AI Max 处理器的笔记本,开机时任务管理器里清清楚楚写着“AMD Ryzen AI 9 3900”,NPU 核心数显示为 16,AI 加速器型号标注为…

📰

AnyPS5:面向Linux开发者的PS5硬件逆向工具链

1. 项目概述:AnyPS5不是PS5模拟器,而是一套面向Linux开发者的PS5硬件逆向工程工具链AnyPS5这个名称很容易让人第一反应联想到“在PC上运行PS5游戏”,但实际完全不是这么回事。我接触过不少被标题误导的朋友,花几天时间折腾环境&am…

📰

Ponytail插件实战:AI整理引擎把碎片信息一键扎成周报日报

第一次看到 Ponytail 这个名字的时候,我第一反应是某款美妆 App 的马尾辫特效。等我真正把 ponytail skill 装进自己常用的笔记工具里,跑了一周,才明白这插件为什么叫这个名字——它做的事情,本质上就是把你扔进来的各种散乱信息&…

📰

前端 Vite 接大模型接口:从 dev server 到上线,4 个最容易被忽略的工程坑

授权与合规声明 本文为技术实践笔记,示例均基于公开文档与自建环境中的实验,不涉及任何未获授权的系统。文中结论仅代表个人实践小结,与所涉厂商无利益关系。转载请注明出处。1. 背景:前端为什么容易在「调大模型接口」上踩坑 1.1…

📰

游戏引擎基础架构:内存、数据结构与数学库的底层设计

1. 项目概述:为什么“引擎基础架构”是游戏开发者的必修课如果你正在写一个能跑起来的渲染循环,却在第3帧就遇到内存暴涨、对象销毁后指针悬空、数学向量运算结果莫名偏移——别急着怀疑显卡驱动或编译器bug,大概率是你还没真正理解游戏引擎基…

📰

AI策略执行报告实战:从Policy到可执行拦截体系的工程化落地

1. 从一份“AI Policy Enforcement Report”说起:为什么执行环节才是AI落地的真正分水岭这两年我经手过不少企业内部的AI治理项目,从最早的“能不能用”到后来的“怎么管”,再到现在的“怎么执行到位”,整个行业的关注点明显在往深…

TODAY

今日更新

THIS WEEK

本周精选

THIS MONTH

本月热门

读完文章,想聊聊您的网站?

告诉我们您的行业与需求,资深顾问一对一梳理方案与报价,全程免费。

📞 💬