前言：在上一篇文章中，我们聚焦K8s应用稳定性的核心，详细讲解了健康检查与资源限制实战，从三种健康检查（livenessProbe、readinessProbe、startupProbe）的实操，到Pod级别、命名空间级别的资源限制配置，再到生产环境最佳实践和常见问题排错，全程实操、命令可复制，帮你彻底解决了“Pod异常无法自动恢复、资源滥用导致集群不稳定”的难题，进一步提升了应用稳定性，为后续日志收集、故障排查打下了坚实基础。
重点记住3点：

  1. 健康检查的核心是“发现异常、自动恢复”，三种探针各司其职：livenessProbe重启异常Pod，readinessProbe隔离未就绪Pod，startupProbe避免启动中误判；

  2. 资源限制的核心是“控制资源、避免滥用”，通过requests（请求值）和limits（限制值），控制Pod资源使用范围，搭配命名空间配额实现批量控制；

  3. 生产环境中，健康检查与资源限制需结合使用，再搭配HPA，才能最大化保证应用稳定运行、集群资源合理分配。

正如上一篇预告，本节课我们将学习K8s日志收集的核心——EFK/ELK部署与配置。在前面的教程中，我们解决了应用的“自愈、扩容、资源控制”问题，但在生产环境中，还有一个关键痛点：K8s集群中的Pod分布在不同节点上，日志分散在各个节点的容器内部，当应用出现故障时，需要逐个节点、逐个Pod查看日志，排查效率极低，甚至无法快速定位故障原因。

EFK（Elasticsearch + Fluentd + Kibana）和ELK（Elasticsearch + Logstash + Kibana）是K8s集群中最常用的日志收集方案，核心作用是“集中收集、存储、查询、可视化”所有Pod的日志，帮你快速定位故障、分析应用运行状态。本文依然针对小白，延续系列“全程实操、命令可复制、yaml可复用”的风格，从“日志收集核心原理、EFK与ELK的区别、EFK完整部署（重点）、ELK部署（备选）、日志收集配置、日志查询与可视化、生产环境最佳实践、常见问题排错”八个维度，手把手教你掌握K8s日志收集的核心用法，解决“日志分散、无法快速排查故障”的问题，为应用故障排查、监控告警打下基础，贴合生产环境需求。

前置要求：已搭建好K8s集群，掌握Pod、Deployment、StatefulSet、健康检查、资源限制的基本概念和基础操作（参考前十一篇教程）；了解基本的日志概念（如日志级别、日志格式）；集群节点有足够的资源（建议至少2核4Gi内存，EFK/ELK组件对资源有一定要求）；已部署基础应用（如Nginx、Redis），用于测试日志收集功能。

一、先理解：K8s日志收集核心原理与EFK/ELK区别

在开始实操之前，我们先搞清楚两个核心问题：K8s日志收集的原理是什么？EFK和ELK有什么区别？小白只需记住：日志收集的核心是“集中化”，EFK和ELK都是“收集→存储→可视化”的三层架构，区别仅在于日志收集组件不同。

1.1 K8s日志收集核心原理
K8s集群中，Pod的日志默认存储在所在节点的/var/log/containers/目录下（每个Pod对应一个日志文件），但这些日志分散在各个节点，无法直接集中查询。日志收集的核心流程分为3步，简单易懂：

  1. 日志收集：通过日志收集组件（Fluentd或Logstash），采集集群中所有Pod的日志（包括容器日志、应用日志）；

  2. 日志存储：将收集到的日志，统一存储到Elasticsearch（分布式搜索引擎，支持高效检索）；

  3. 日志可视化：通过Kibana（可视化工具），对存储在Elasticsearch中的日志进行查询、筛选、分析、可视化，方便运维人员快速定位故障。

补充说明：K8s中，日志收集组件通常以DaemonSet方式部署（每个节点部署一个Pod），确保能采集到所有节点上的容器日志，避免遗漏。

1.2 EFK与ELK的核心区别（小白必记）
EFK和ELK都是K8s日志收集的主流方案，三层架构基本一致，核心区别仅在于“日志收集组件”不同，小白可根据自身需求选择：

方案 日志收集组件 核心优势 适用场景
ELK Logstash 功能强大，支持复杂的日志过滤、转换；生态完善，集成多种插件 日志量大、需要复杂日志处理（如格式转换、过滤）的场景
EFK Fluentd 轻量、资源占用低；配置简单，易于部署；对K8s兼容性更好 中小型集群、资源有限、追求简单部署的场景（生产环境首选）

关键说明：本文重点实操EFK方案（生产环境中小集群首选），同时提供ELK方案的部署步骤（备选），小白可根据自身集群资源和需求选择，两种方案的核心流程和用法基本一致。

二、实战1：EFK 完整部署（重点，生产环境首选）

EFK由Elasticsearch（存储）、Fluentd（收集）、Kibana（可视化）三个组件组成，部署顺序为：Elasticsearch → Fluentd → Kibana。我们使用Helm部署（简化部署流程，命令可直接复制），同时配置资源限制、健康检查，确保组件稳定运行。

2.1 前置准备：部署Helm（若未部署）
若之前部署Prometheus时未安装Helm，先执行以下命令安装（适用于Linux系统）：

# 安装Helm
curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash
# 验证Helm安装成功
helm version
# 添加常用Helm仓库
helm repo add elastic https://helm.elastic.co
helm repo add fluent https://fluent.github.io/helm-charts
helm repo update

2.2 部署Elasticsearch（日志存储）
Elasticsearch是分布式搜索引擎，用于存储和检索日志，我们部署单节点Elasticsearch（适用于中小型集群），同时配置资源限制和健康检查，避免资源滥用。

# 1. 创建命名空间（用于隔离EFK组件，便于管理）
kubectl create namespace efk

# 2. 部署Elasticsearch（单节点，资源限制：2核4Gi）
helm install elasticsearch elastic/elasticsearch -n efk \
  --set replicas=1 \
  --set resources.requests.cpu=2 \
  --set resources.requests.memory=4Gi \
  --set resources.limits.cpu=2 \
  --set resources.limits.memory=4Gi \
  --set clusterHealthCheckParams=wait_for_status=green&timeout=1s \
  --set persistence.enabled=false  # 测试环境可关闭持久化，生产环境建议开启（需配置PV）

# 3. 查看Elasticsearch状态，确保Pod处于Running状态
kubectl get pods -n efk -l app=elasticsearch
# 查看Elasticsearch详细信息，确认无报错
kubectl describe pod <elasticsearch-pod名称> -n efk

# 4. 验证Elasticsearch服务是否正常
kubectl exec -it <elasticsearch-pod名称> -n efk -- curl http://localhost:9200
# 正常响应会返回Elasticsearch的版本信息、集群状态等

关键说明：

  • Elasticsearch对内存要求较高，建议至少分配4Gi内存，否则可能启动失败；

  • 生产环境中，建议开启持久化（–set persistence.enabled=true），并配置PV/PVC，避免日志丢失；

  • Elasticsearch默认端口9200（用于API交互），9300（用于集群间通信）。

2.3 部署Fluentd（日志收集）
Fluentd是轻量级日志收集组件，我们以DaemonSet方式部署（每个节点部署一个Pod），确保能采集到所有节点上的容器日志，同时配置日志过滤规则，只收集有用的日志。

# 部署Fluentd（DaemonSet方式，资源限制：0.5核1Gi）
helm install fluentd fluent/fluentd -n efk \
  --set resources.requests.cpu=500m \
  --set resources.requests.memory=1Gi \
  --set resources.limits.cpu=1 \
  --set resources.limits.memory=2Gi \
  --set config.output.elasticsearch.host=elasticsearch-master.efk.svc.cluster.local \
  --set config.output.elasticsearch.port=9200 \
  --set config.output.elasticsearch.index_name=k8s-logs-%Y.%m.%d  # 日志索引格式（按日期分割）

# 查看Fluentd状态，确保所有节点都有一个Fluentd Pod（Running状态）
kubectl get pods -n efk -l app.kubernetes.io/name=fluentd
# 查看Fluentd日志，确认日志收集正常（无报错）
kubectl logs <fluentd-pod名称> -n efk

关键说明：

  • Fluentd以DaemonSet方式部署，确保每个节点都能采集日志，避免遗漏；

  • config.output.elasticsearch.host配置为Elasticsearch的Service地址（elasticsearch-master.efk.svc.cluster.local），确保Fluentd能将日志发送到Elasticsearch；

  • 日志索引按日期分割（k8s-logs-年.月.日），便于后续按日期查询日志。

2.4 部署Kibana（日志可视化）

Kibana是Elasticsearch的可视化工具，用于查询、筛选、分析日志，我们部署Kibana并关联Elasticsearch，通过端口转发访问Kibana Web界面。

# 部署Kibana（资源限制：1核2Gi）
helm install kibana elastic/kibana -n efk \
  --set resources.requests.cpu=1 \
  --set resources.requests.memory=2Gi \
  --set resources.limits.cpu=1 \
  --set resources.limits.memory=2Gi \
  --set elasticsearchHosts=http://elasticsearch-master.efk.svc.cluster.local:9200  # 关联Elasticsearch

# 查看Kibana状态，确保Pod处于Running状态
kubectl get pods -n efk -l app=kibana
# 查看Kibana日志，确认无报错
kubectl logs <kibana-pod名称> -n efk

# 端口转发，访问Kibana Web界面（默认端口5601）
kubectl port-forward svc/kibana-kibana -n efk 5601:5601
# 打开浏览器，访问http://localhost:5601，进入Kibana界面

关键说明：Kibana默认无需登录（测试环境），生产环境建议配置登录认证，避免未授权访问；访问Kibana时，若提示“Elasticsearch未连接”，需等待1-2分钟，或检查Elasticsearch状态是否正常。

2.5 EFK部署验证：收集Nginx日志
部署完EFK后，我们部署一个Nginx应用，测试日志收集功能，确认日志能正常收集、存储、查询。

# 创建nginx-test.yaml文件（用于测试日志收集）
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-log-test
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx-log
  template:
    metadata:
      labels:
        app: nginx-log
    spec:
      containers:
      - name: nginx
        image: nginx:1.24
        ports:
        - containerPort: 80
        # 配置日志输出格式（便于Kibana解析）
        env:
        - name: NGINX_ACCESS_LOG
          value: "/var/log/nginx/access.log main"
        - name: NGINX_ERROR_LOG
          value: "/var/log/nginx/error.log warn"
        # 挂载日志目录（可选，确保日志能被Fluentd采集）
        volumeMounts:
        - name: nginx-logs
          mountPath: /var/log/nginx
      volumes:
      - name: nginx-logs
        emptyDir: {}

# 部署Nginx应用
kubectl apply -f nginx-test.yaml
# 查看Nginx Pod状态
kubectl get pods -l app=nginx-log
# 模拟Nginx访问，生成日志
kubectl exec -it <nginx-pod名称> -- /bin/bash
curl http://localhost  # 访问Nginx首页，生成访问日志
curl http://localhost/error  # 访问不存在的路径，生成错误日志

# 查看Fluentd日志，确认日志已被收集
kubectl logs <fluentd-pod名称> -n efk | grep nginx-log-test

# 访问Kibana Web界面，查询日志
# 1. 打开http://localhost:5601，进入Kibana首页，点击“Discover”
# 2. 创建索引模式：输入“k8s-logs-*”（匹配所有日志索引），点击“Next step”
# 3. 时间字段选择“@timestamp”，点击“Create index pattern”
# 4. 回到Discover页面，即可看到Nginx的访问日志和错误日志，可通过筛选条件查询

验证结果：在Kibana中能看到Nginx的访问日志（200状态码）和错误日志（404状态码），说明EFK日志收集功能正常，达到“集中收集、查询”的目的。

三、实战2：ELK 部署（备选方案）

ELK由Elasticsearch（存储）、Logstash（收集）、Kibana（可视化）组成，部署流程与EFK类似，核心区别是将Fluentd替换为Logstash。适用于日志量大、需要复杂日志处理的场景，小白可根据需求选择部署。

3.1 部署Elasticsearch（与EFK一致）

# 1. 创建命名空间（若未创建）
kubectl create namespace elk

# 2. 部署Elasticsearch（单节点，资源限制：2核4Gi）
helm install elasticsearch elastic/elasticsearch -n elk \
  --set replicas=1 \
  --set resources.requests.cpu=2 \
  --set resources.requests.memory=4Gi \
  --set resources.limits.cpu=2 \
  --set resources.limits.memory=4Gi \
  --set persistence.enabled=false

# 3. 验证Elasticsearch状态
kubectl get pods -n elk -l app=elasticsearch
kubectl exec -it <elasticsearch-pod名称> -n elk -- curl http://localhost:9200

3.2 部署Logstash（日志收集）

Logstash功能强大，支持复杂的日志过滤、转换，我们以DaemonSet方式部署，配置日志采集规则，将日志发送到Elasticsearch。

# 部署Logstash（DaemonSet方式，资源限制：1核2Gi）
helm install logstash elastic/logstash -n elk \
  --set replicas=1 \
  --set resources.requests.cpu=1 \
  --set resources.requests.memory=2Gi \
  --set resources.limits.cpu=2 \
  --set resources.limits.memory=4Gi \
  --set config.pipeline.filebeat.inputs[0].type=container \
  --set config.pipeline.filebeat.inputs[0].paths[0]="/var/log/containers/*.log" \
  --set config.pipeline.output.elasticsearch.hosts[0]=elasticsearch-master.elk.svc.cluster.local:9200 \
  --set config.pipeline.output.elasticsearch.index=k8s-logs-%{+YYYY.MM.dd}

# 查看Logstash状态
kubectl get pods -n elk -l app=logstash
# 查看Logstash日志，确认无报错
kubectl logs <logstash-pod名称> -n elk

3.3 部署Kibana（与EFK一致）

# 部署Kibana，关联Elasticsearch
helm install kibana elastic/kibana -n elk \
  --set resources.requests.cpu=1 \
  --set resources.requests.memory=2Gi \
  --set elasticsearchHosts=http://elasticsearch-master.elk.svc.cluster.local:9200

# 查看Kibana状态，端口转发访问
kubectl get pods -n elk -l app=kibana
kubectl port-forward svc/kibana-kibana -n elk 5601:5601

验证方法：与EFK一致，部署Nginx应用，模拟访问生成日志，在Kibana中查询日志，确认日志收集正常即可。

四、进阶配置：日志过滤、按应用分类收集

默认情况下，EFK/ELK会收集集群中所有Pod的日志，但生产环境中，我们可能需要“过滤无用日志、按应用分类收集、按日志级别筛选”，本节以EFK为例，讲解进阶配置，ELK配置逻辑类似。

4.1 配置Fluentd过滤无用日志
集群中会产生大量无用日志（如kube-system命名空间的组件日志），我们可以配置Fluentd，只收集指定命名空间（如app-namespace）的应用日志，过滤无用日志。

# 编辑Fluentd配置（修改DaemonSet的configmap）
kubectl edit configmap fluentd-config -n efk

# 在<filter **>标签中，添加以下过滤规则（只收集app-namespace命名空间的日志）
<filter **>
  @type grep
  <regexp>
    key $.kubernetes.namespace_name
    pattern /^app-namespace$/  # 只收集app-namespace命名空间的日志
  </regexp>
</filter>

# 保存退出后，重启Fluentd Pod，使配置生效
kubectl rollout restart daemonset fluentd -n efk
# 查看Fluentd日志，确认过滤规则生效
kubectl logs <fluentd-pod名称> -n efk

4.2 按应用分类收集日志（按Pod标签分类）
我们可以配置Fluentd，根据Pod的标签（如app=nginx、app=redis），将不同应用的日志存储到不同的Elasticsearch索引中，便于分类查询。

# 编辑Fluentd配置
kubectl edit configmap fluentd-config -n efk

# 修改<match **>标签中的索引配置，按Pod标签分类
<match **>
  @type elasticsearch
  host elasticsearch-master.efk.svc.cluster.local
  port 9200
  index_name k8s-logs-${$.kubernetes.labels.app}-%Y.%m.%d  # 按app标签分类索引
  logstash_format true
  logstash_prefix k8s-logs
  flush_interval 5s
</match>

# 重启Fluentd Pod
kubectl rollout restart daemonset fluentd -n efk

# 测试：部署不同应用（Nginx、Redis），查看索引
kubectl exec -it <elasticsearch-pod名称> -n efk -- curl http://localhost:9200/_cat/indices
# 会看到类似k8s-logs-nginx-2026.03.09、k8s-logs-redis-2026.03.09的索引

4.3 按日志级别筛选日志
应用日志通常包含不同级别（info、warn、error、fatal），我们可以在Kibana中配置筛选条件，只查看error级别的日志，快速定位故障。

# 1. 访问Kibana Web界面（http://localhost:5601），进入Discover页面
# 2. 在筛选框中输入：log_level:error（需确保日志中包含log_level字段）
# 3. 即可筛选出所有error级别的日志，快速定位应用故障
# 补充：若日志中无log_level字段，需在Fluentd中配置日志解析，提取日志级别

五、Kibana 日志查询与可视化实战（重点）

Kibana的核心作用是“日志查询、筛选、可视化”，本节讲解最常用的操作，帮小白快速上手，解决“如何快速查询日志、分析故障”的问题。

5.1 日志查询基础操作

  • 模糊查询：在搜索框中输入关键词（如“error”“404”），即可查询包含该关键词的所有日志；

  • 精确查询：使用双引号包裹关键词（如“GET /error”），查询精确匹配的日志；

  • 按字段筛选：点击左侧“Available fields”中的字段（如kubernetes.namespace_name、kubernetes.pod_name），选择“Add filter”，即可按命名空间、Pod名称筛选日志；

  • 按时间筛选：页面右上角可选择时间范围（如最近1小时、最近6小时），筛选指定时间内的日志。

示例：查询app-namespace命名空间、nginx-log-test Pod的error级日志，时间范围为最近10分钟。

5.2 日志可视化：创建仪表盘（Dashboard）
生产环境中，我们可以创建Kibana仪表盘，将常用的日志指标（如日志数量、不同级别日志占比、各应用日志数量）可视化，便于实时监控应用运行状态。

# 1. 进入Kibana首页，点击“Dashboard”，选择“Create dashboard”
# 2. 点击“Add panel”，选择“Visualize Library”
# 3. 选择可视化类型（如Pie chart、Bar chart），配置数据源（索引模式）和指标：
#    - 饼图（Pie chart）：展示不同级别日志的占比（如info、warn、error）；
#    - 柱状图（Bar chart）：展示各应用的日志数量；
#    - 折线图（Line chart）：展示日志数量随时间的变化趋势。
# 4. 配置完成后，点击“Save”，保存仪表盘，后续可直接访问查看。

5.3 日志导出（用于故障排查）
当应用出现故障时，可将相关日志导出为文件，便于后续分析或提交给开发人员排查问题：

# 1. 在Kibana Discover页面，筛选出需要导出的日志；
# 2. 点击页面右上角的“Share”，选择“Export”；
# 3. 选择导出格式（如CSV、JSON），点击“Export”，即可下载日志文件。

六、生产环境最佳实践（面试必问）

结合前面的实操，本节总结EFK/ELK生产环境最佳实践，帮助小白规范配置，避免踩坑，同时应对面试提问，重点关注“稳定性、可靠性、可维护性”三个核心。

6.1 组件部署最佳实践

  • Elasticsearch：

    • 生产环境建议部署3节点集群（高可用），避免单节点故障导致日志丢失；

    • 开启持久化存储（PV/PVC），选择高性能存储（如SSD），确保日志存储稳定；

    • 配置资源限制（至少2核4Gi内存），避免资源不足导致Elasticsearch崩溃；

    • 定期清理日志（配置索引生命周期管理ILM），避免日志过多占用存储空间。

  • 日志收集组件（Fluentd/Logstash）：

    • 优先选择Fluentd（轻量、资源占用低，对K8s兼容性更好）；

    • 以DaemonSet方式部署，确保每个节点都能采集日志，避免遗漏；

    • 配置日志过滤规则，过滤无用日志（如kube-system命名空间的组件日志），减少存储压力。

  • Kibana：

    • 配置登录认证（如使用LDAP、用户名密码），避免未授权访问；

    • 创建不同角色的用户（如管理员、运维人员），分配不同的权限（如查询权限、编辑权限）；

    • 定期备份Kibana配置（如仪表盘、索引模式），避免配置丢失。

6.2 日志收集最佳实践

  • 日志格式统一：所有应用采用统一的日志格式（如JSON格式），便于Kibana解析和筛选；

  • 按应用/命名空间分类：将不同应用、不同命名空间的日志存储到不同的索引中，便于分类查询和管理；

  • 日志级别规范：应用日志需包含级别（info、warn、error、fatal），便于快速筛选故障日志；

  • 避免收集敏感日志：过滤掉密码、token等敏感信息，确保日志安全。

6.3 运维最佳实践

  • 监控EFK/ELK组件：部署Prometheus+Grafana，监控Elasticsearch、Fluentd/Logstash、Kibana的运行状态（如Pod状态、资源使用率、日志收集量）；

  • 设置告警规则：当组件故障（如Elasticsearch集群状态异常、Fluentd日志收集失败）、日志量突增、error日志量异常时，及时通知运维人员；

  • 定期维护：定期清理过期日志、备份日志数据、升级组件版本，确保日志收集系统稳定运行。

七、常见问题排错（小白必看）

EFK/ELK的部署和配置相对复杂，小白在实操过程中，很容易遇到组件启动失败、日志收集不到、Kibana无法访问等问题。本节整理了7个最常见的问题，给出详细的原因分析和解决方法，帮你快速排错。

  1. 问题1：Elasticsearch Pod启动失败，报错“insufficient memory”
    原因：Elasticsearch对内存要求较高，当前节点可用内存不足，或资源限制设置过小。

解决：1. 选择内存≥4Gi的节点部署Elasticsearch；2. 提高Elasticsearch的资源限制（如设置memory=4Gi）；3. 关闭节点上的其他占用内存的应用，释放资源。

  1. 问题2：Fluentd/Logstash无法收集日志，日志中报错“connection refused”
    原因：1. Elasticsearch未正常启动，或端口未暴露；2. Fluentd/Logstash配置的Elasticsearch地址错误；3. 网络策略限制，Fluentd/Logstash无法访问Elasticsearch。

解决：1. 查看Elasticsearch状态，确保Pod正常运行，端口9200可访问；2. 核对Fluentd/Logstash配置中的Elasticsearch地址，确保正确；3. 检查网络策略，允许Fluentd/Logstash所在命名空间访问Elasticsearch所在命名空间。

  1. 问题3：Kibana无法访问，或提示“Elasticsearch connection failed”
    原因：1. Kibana Pod未正常启动；2. Kibana配置的Elasticsearch地址错误；3. Elasticsearch集群状态异常（如red状态）。

解决：1. 查看Kibana Pod状态和日志，排查启动失败原因；2. 核对Kibana配置中的Elasticsearch地址，确保正确；3. 查看Elasticsearch集群状态（kubectl exec -it – curl http://localhost:9200/_cluster/health），若为red状态，修复Elasticsearch。

  1. 问题4：Kibana中查询不到日志，但Fluentd/Logstash日志显示收集正常
    原因：1. Kibana索引模式配置错误（未匹配Elasticsearch中的日志索引）；2. 日志索引未创建（Fluentd/Logstash未成功将日志发送到Elasticsearch）；3. 时间范围选择错误（日志时间与当前时间不匹配）。
    解决：1. 检查Kibana索引模式，确保索引模式（如k8s-logs-*）匹配Elasticsearch中的日志索引；2. 查看Elasticsearch索引（curl http://localhost:9200/_cat/indices），确认日志索引已创建；3. 调整Kibana的时间范围，选择日志产生的时间范围。

  2. 问题5：日志收集重复（同一条日志被多次收集）
    原因：1. Fluentd/Logstash以DaemonSet方式部署，但配置错误，导致多个节点重复收集同一Pod的日志；2. 日志文件被多次挂载，导致Fluentd/Logstash重复采集。

解决：1. 检查Fluentd/Logstash配置，确保只采集本节点的日志；2. 避免日志文件被多次挂载，确保每个Pod的日志只被一个Fluentd/Logstash Pod采集。

  1. 问题6：Elasticsearch日志占用过多存储空间，导致磁盘满
    原因：1. 未配置日志清理策略，日志长期积累；2. 日志过滤不彻底，无用日志过多；3. 未开启索引生命周期管理（ILM）。

解决：1. 手动清理过期日志（删除旧的日志索引）；2. 配置Fluentd/Logstash过滤无用日志；3. 开启Elasticsearch的ILM，自动清理过期日志（如保留7天日志）。

  1. 问题7：Fluentd Pod启动失败，报错“permission denied”
    原因：Fluentd需要访问节点的/var/log/containers/目录，获取容器日志，但权限不足。

解决：1. 编辑Fluentd DaemonSet，添加权限配置（如添加securityContext字段，设置privileged: true）；2. 确保节点的/var/log/containers/目录权限为755，允许Fluentd访问。

八、总结及下一篇预告

本文详细讲解了K8s日志收集的核心——EFK/ELK部署与配置，从日志收集核心原理、EFK与ELK的区别，到EFK完整部署（重点）、ELK部署（备选），再到日志过滤、Kibana日志查询与可视化、生产环境最佳实践和常见问题排错，全程实操、命令可复制，帮你彻底解决了“日志分散、无法快速排查故障”的难题，掌握了K8s应用日志的集中收集、存储、查询方法，为应用故障排查、监控告警打下了坚实基础。

重点记住3点：

  1. 日志收集的核心是“集中化”，EFK和ELK都是“收集→存储→可视化”三层架构，EFK轻量易部署（生产环境首选），ELK功能强大（适用于复杂日志处理）；

  2. EFK部署顺序为Elasticsearch→Fluentd→Kibana，Fluentd以DaemonSet方式部署，确保采集所有节点的日志，Kibana用于日志可视化和查询；

  3. 生产环境中，需配置日志过滤、索引生命周期管理、组件监控和告警，确保日志收集系统稳定、可靠，同时避免日志泄露和存储空间不足。

下一篇文章，我们将学习K8s监控告警的核心——《K8s 监控告警实战：Prometheus + Grafana 部署与配置》，带你深入掌握K8s集群、应用的监控方法，配置告警规则，解决“无法实时监控集群状态、故障无法及时发现”的问题，进一步完善K8s运维体系，贴合生产环境需求，敬请关注！

最后，如果你觉得这篇文章对你有帮助，欢迎点赞、收藏、关注，后续会持续更新K8s系列实战文章（共15篇），从入门到精通，带你轻松搞定K8s！

# kubernetes # elk # docker
Logo
https://edu.csdn.net/learn/39067/627173?utm_source=2019755004

汇聚全球AI编程工具，助力开发者即刻编程。

更多推荐

cover

一个 API 入口调用多个大模型：AiiOnly客户端 + CC Switch 打通 Codex AI编程流程

avatar AI编程社区
cover

VSCode Claude Code + MiMo 中转免登录完整配置教程（解决原生登录弹窗 + 模型报错）

avatar AI编程社区
cover

从零开始做一个属于自己的 Skill（保姆级教程）

avatar AI编程社区