k8s已经删除pod,但是node节点的容器还存在的排错记录(集群使用NAS存储)

在Kubernetes环境下,发现tdh03节点缺少hdfs-datanode服务,但Docker容器仍显示运行。进一步排查发现,NFS挂载出现卡顿,容器进程处于D状态,且机器日志显示NAS曾断开。分析认为,Pod未重建可能是由于残留的容器清理不彻底,而NAS问题需要服务器重启来解决。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

现象

使用k8s查询节点的pod情况,显示tdh03没有hdfs-datanode服务
在这里插入图片描述
进入tdh03节点 使用docker ps 查询hdfs-datanode 容器还在running,没有被删除
在这里插入图片描述

排错

查看对应docker进程,nfs卡住了。容器的进程 已经是D状态了。
在这里插入图片描述
查看机器日志:dmesg -T查看NAS挂载有断开过
在这里插入图片描述

问题分析

删除了Pod 没有重建,应该就和残留的container 清理不掉有关,NAS之前有断开的情况,挂载问题是客户的没办法直接解决,需要重启服务器解决问题。

<think>嗯,用户问的是在Kubernetes使用Filebeat收集容器日志,但Pod可能分布在不同的节点上,如何区分这些日志,并在Kibana中查看。我需要先理解用户的问题核心。他们可能遇到了日志来源不清晰的问题,想知道如何根据节点Pod信息来区分日志,方便在Kibana中筛选和查看。 首先,用户提到了Filebeat,所以需要确认Filebeat在K8s中的常见部署方式。通常Filebeat会以DaemonSet形式运行在每个节点上,收集该节点所有容器的日志。那么,每个节点的Filebeat实例会收集该节点上的日志,但用户可能想知道如何区分不同节点Pod的日志。 接下来,关键点在于日志的元数据。Filebeat在收集容器日志时,应该能够自动添加一些元数据,比如容器ID、Pod名称、命名空间等。但可能需要确认这些元数据是否默认被添加,或者是否需要额外配置。例如,Filebeat的autodiscover功能可能需要配置来获取Kubernetes的元数据。 然后,用户提到在Kibana中如何查看,这就需要确保收集的日志中包含了足够的字段,如host.name(节点名称)、kubernetes.pod.name等。这些字段需要被正确解析并存储在Elasticsearch中,才能在Kibana中作为过滤条件使用。 可能的步骤包括配置Filebeat的autodiscover,添加annotations或fields来标识应用,以及确保Elasticsearch的索引模式包含这些字段。此外,用户可能需要了解如何通过Kibana创建可视化或仪表盘,基于这些字段进行过滤和查询。 还需要考虑用户可能遇到的常见问题,例如日志字段未正确解析,或者元数据未被捕获,导致无法区分节点Pod。这时候需要检查Filebeat的配置,确保Kubernetes的元数据被正确添加,并验证Elasticsearch中的日志结构。 另外,用户可能对如何高效查询和展示日志感兴趣,比如使用Kibana的Discover功能,输入特定字段进行筛选,或者保存搜索条件以便快速访问。还有可能需要指导如何根据不同的业务需求定制视图,比如按环境、应用或错误级别分类。 最后,总结一下,解决方案应包括配置Filebeat以捕获Kubernetes元数据,确保这些元数据在Elasticsearch中正确索引,并在Kibana中利用这些字段进行过滤和可视化。同时,提供一些验证步骤和最佳实践,帮助用户确保配置正确,并能够高效地管理和查询日志。</think>以下是针对 Kubernetes 环境下使用 Filebeat 收集跨节点容器日志的完整解决方案: --- ### 一、核心原理架构 ```text [Pod1(nodeA)] --> /var/log/containers/*.log [Pod2(nodeB)] --> Filebeat(DaemonSet) --> Elasticsearch --> Kibana ``` **核心元数据自动注入**: - `host.name`:物理节点名称(自动采集) - `kubernetes.pod.name`:Pod 名称(需 Filebeat 配置解析) - `kubernetes.namespace`:所属命名空间 --- ### 二、关键配置步骤 #### 1. **启用 Filebeat Kubernetes 元数据** 修改 `filebeat.yml` 配置文件: ```yaml filebeat.autodiscover: providers: - type: kubernetes node: ${NODE_NAME} # 自动注入节点名变量 templates: - condition: equals: kubernetes.namespace: "prod" config: - type: container paths: - /var/log/containers/*-${data.kubernetes.pod.uid}.log processors: - add_kubernetes_metadata: # 关键配置 host: ${NODE_NAME} matchers: - logs_path: logs_path: "/var/log/containers/" ``` #### 2. **添加自定义字段区分业务**(可选) 在 Pod 定义中增加 annotations: ```yaml metadata: annotations: filebeat/environment: "production" filebeat/app_type: "payment-service" ``` Filebeat 会自动将 `annotations` 中 `filebeat/` 前缀的标签转为字段 --- ### 三、Kibana 查询实战技巧 #### 1. **基础过滤方法** 在 Discover 界面使用 KQL 语法: ```kql # 按节点过滤 host.name : "node-01" # 按业务Pod过滤 kubernetes.pod.name : "payment-service-*" # 组合查询 kubernetes.namespace : "prod" and log.level : "ERROR" ``` #### 2. **可视化维度设计 ```text 垂直字段布局建议: 1. 第一层级:kubernetes.namespace 2. 第二层级:host.name(物理节点) 3. 第三层级:kubernetes.pod.name 4. 业务维度:自定义的 app_type 等字段 ``` #### 3. **保存常用视图** 通过 `Save` 功能创建快速访问入口: - "生产环境错误日志":`kubernetes.namespace:prod AND log.level:ERROR` - "节点资源异常":`host.name:node-03 AND message:/(OOM|CPU limit)/` --- ### 四、高级排错手段 #### 1. **验证元数据完整性** ```bash # 查看Elasticsearch中单条日志的元数据 GET filebeat-*/_search { "query": {"match": {"message": "特定错误关键词"}}, "_source": ["host.name","kubernetes.*"] } ``` #### 2. **字段映射检查** 在 Kibana 中执行: ```text 路径:Management -> Stack Management -> 索引模式 -> filebeat-* -> 查看字段列表 关键验证字段: - host.name (类型:keyword) - kubernetes.pod.name (类型:keyword) - kubernetes.node.name (类型:keyword) ``` --- ### 五、性能优化建议 1. **分片策略** Elasticsearch 索引按 `kubernetes.namespace` 分片: ```json { "settings": { "index.number_of_shards": 5, "index.routing_partition_size": 3 }, "routing": { "required": true, "path": "kubernetes.namespace" } } ``` 2. **冷热数据分离** 通过 ILM 策略实现: ```text Hot层(7天):3副本,SSD存储 Warm层(30天):1副本,HDD存储 删除策略:生产环境保留6个月 ``` --- ### 六、典型故障场景处理 **场景**:某个节点的日志在 Kibana 中缺失 **排查步骤**: 1. 检查 Filebeat Pod 状态:`kubectl logs -n kube-system filebeat-xxxx` 2. 确认节点存储空间:`df -h /var/lib/docker`(需保持>20%剩余空间) 3. 验证 Elasticsearch 索引状态: ```bash curl -XGET 'http://es-host:9200/_cat/indices?v' | grep filebeat ``` --- ### 七、与 EFK 方案的对比优势 | 特性 | Filebeat方案 | Fluentd方案 | |---------------------|-----------------------|----------------------| | 内存占用 | ~100MB/节点 | ~300MB/节点 | | 日志解析能力 | 需配合Ingest Node | 内置强大Filter | | K8s元数据处理 | 自动注入 | 需要额外filter配置 | | 协议支持 | Lumberjack专属协议 | 支持Forward/TCP等 | --- 通过上述配置,可实现跨节点日志的精准区分和高效查询。建议每月检查一次字段映射,确保新增业务日志的元数据能被正确解析。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值