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

最新推荐文章于 2024-04-29 14:51:55 发布
最新推荐文章于 2024-04-29 14:51:55 发布
阅读量1.3k 收藏
点赞数
CC 4.0 BY-SA版权
分类专栏： kubernetes docker 文章标签： docker kubernetes 容器
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/kingrootZ/article/details/125916997
在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之前有断开的情况，挂载问题是客户的没办法直接解决，需要重启服务器解决问题。

k8s常见问题大收集
专注基础架构领域
08-21 2462
3.1、问题1：提示/etc/rhsm/ca/redhat-uep.pem no file or dirctory。在搭建好的k8s集群内创建的容器，只能在其所在的节点上curl可访问，但是在其他任何主机上无法访问容器占用的端口。2.1.1、解决方法1：（docker 1.2以上版本解决方法）2.1.2、解决方法2：（docker1.2以下版本解决方法）4.2.2、调试后发现容器状态变为了未开启，尝试删除容器，成功。4.1.1.3、删除容器依旧提示错误（-f强制删除）4.1.1.2、停止容器依旧提示错误。
k8s pod删不掉
zenglingmin8的博客
05-28 1759
问题现象：pod一直删除不掉问题 起因：在pod运行过程中，修改了其deployment，导致pod一直删不掉 操作过程： 删除pod，删不掉 强制删除pod，依然删除不了 删除deployment，旧的pod依然删不掉，因为deployment已经发生变更 查看pod的详情，发现如下内容 kubectl get pods -n architect wx-xxx-luna-5b5755b69-zwrhb -oyaml apiVersion: v1 kind: Pod metadata: annota
k8s为什么删除了pod但是还是没删除掉的问题，deployment在影响
吃素的哈士奇de博客
03-20 1317
我找的时候，还是有dashboard-metrics-scraper-546d6779cb-4x6xf这个pod。但是我想删掉，却告诉我这个pod不存在。执行：kubectl get pods --all-namespaces，获取dashboard相关的pod。
k8s中删除pod后仍然存在问题
weixin_30916125的博客
03-08 1862
分析： 是因为删除了pod，但是没有删除对应的deployment，删除对应的deployment即可 实例如下： 删除pod [root@test2 ~]# kubectl get pod -n jenkins NAME READY STATUS RESTARTS AGE jenkins2-...
解决K8S删除pod后又新建pod
weixin_45387943的博客
02-25 5800
删除指定Pod [root@master ~]# kubectl delete pod nginx -n dev pod "nginx" deleted 此时，显示删除Pod成功，但是再查询，发现又新产生了一个 [root@master ~]# kubectl get pods -n dev NAME READY STATUS RESTARTS AGE nginx 1/1 Running 0 21s 这是因为当前Pod是由Pod控制器创建的，控制器会
k8s环境，服务器重启后，所有节点状态为noready，pod状态为running，但是docker容器一个都没起来
simpleness_的博客
06-11 993
k8s环境，服务器重启后，所有节点状态为noready，pod状态为running，但是docker容器一个都没起来
Kubernetes—k8s中Service实例出现污点
qq_50685659的博客
09-24 830
Service可以看做是一组同类的Pod对外的访问接口，借助Service，应用可以方便的实现服务发现和负载均衡。 Service在很多情况下只是一个概念，真正起作用的其实是kube-proxy服务进 程，每个Node节点上都运行了一个kube-proxy的服务进程。当创建Service的时候会通过API Server向etcd写入创建的Service的信息，而kube-proxy会基于监听的机制发现这种Service的变化，然后它会将最新的Service信息转换为对应的访问规则。
从k8s集群中移除节点后重新加入
init_zq的博客
03-05 1334
从k8s集群中移除节点后重新加入 master节点执行： 1.sudo kubectl get no 查看当前所有node节点 2.sudo kubectl drain <node> --delete-local-data –force –ignore-daemonsets 3.sudo kubectl delete node <your-node> work 节点执行： 4.在被删除节点<node>执...
k8s删除节点后，重启kubelet节点为啥会自动加入集群
任我行的博客
03-16 819
kubelet在创建了 Node或者节点上的kubelet执行了自注册操作之后，控制面会检查新的 Node 对象是否合法。Kubernetes 会在内部创建一个 Node 对象作为节点的表示。Kubernetes 检查kubelet向 API 服务器注册节点时使用的字段是否匹配。如果节点是健康的（即所有必要的服务都在运行中），则该节点可以用来运行 Pod。否则，直到该节点变为健康之前，所有的集群活动都会忽略该节点。Kubernetes 会一直保存着非法节点对应的对象，并持续检查该节点是否已经变得健康。
k8s资源删除顺序
welcome to my world
08-10 521
kubectl delete svc kubectl delete deploy kubectl delete pod
Kubernetes故障排查指南-分析容器退出状态码
热门推荐
qq_24794401的博客
06-23 1万+
问题大家在使用 Kubernetes 时，会遇到创建Pod失败，这时会分析什么原因导致创建Pod失败？Pod status 状态解释 [1]CrashLoopBackOff：容器退出，k...
【k8s】 Pod状态和生命周期管理(Pause容器、Pod的创建过程、探针、livenessProbe、readinessProbe)
m0_45406092的博客
07-22 3887
文章目录1. 什么是Pod？2. Pod中如何管理多个容器？3. 使用Pod4. Pod的持久性和终止5. Pause容器6. init容器7. Pod的生命周期7.1 Pod phase（Pod的相位）7.2 Pod的创建过程7.3 Pod的状态7.4 Pod存活性探测7.6 Pod的重启策略7.7 Pod的生命7.8 livenessProbe解析7.9 资源需求和资源限制参考 1. 什么是Pod？ Pod是kubernetes中你可以创建和部署的最小也是最简的单位。一个Pod代表着集群中运行的一个进
Kubernetes控制平面组件：Kubelet
一点一滴铺就人生
09-04 1573
Kubernetes的node节点大管家
【k8s】k8s容器状态Terminating无法删除
m0_45406092的博客
02-28 1671
若Pod的状态为Terminating，说明此Pod正处于关闭状态。Pod停留在Terminating状态一段时间后会被自动删除。若Pod一直停留在Terminating状态，则：1、判断是否为k8s和docker容器状态不一致问题造成；2、判断 Pod 上是否有 finalizers ，如果有需要确认是否是有防止删除的保护；3、判断节点是否出现 NotReady，节点如果处于NotReady，此节点上出现 Pod 状态 Terminating 是预期中的行为。
K8s Pod优雅关闭，没你想象的那么简单！
关注微信公众号【开源Linux】，后台回复『10T』，领取10T学习资源大放送，涵盖Linux、虚拟化、容器、云计算、网络、Python、Go等书籍和视频
09-27 2349
更新部署服务时，旧的 Pod 会终止，新 Pod 上位。如果在这个部署过程中老 Pod 有一个很长的操作，我们想在这个操作成功完成后杀死这个 pod（优雅关闭），如果无法做到的话，被杀死的...
k8s记录
CheerTan is here
06-18 1357
拉取镜像部署服务 拉镜像： docker pull alpha-harbor.51iwifi.com/video-cloud/dataservice-node-provider:1.0.2.55 编排文件： 启动容器： helm install -n front-gateway ./front-gateway 其中-n为指定namespace，可以选择没有，./front-gateway指的是该服务的编排文件 创建PVC 创建一个固定的文件目录作为存储pvc配置文件，新建yaml文件，内容如下： kind:
K8s 学习笔记—— 数据存储(持久化)
weixin_39802680的博客
12-11 2739
文章目录数据存储基本存储EmptyDirHostPathNFSPV 和PVCConfigMapSecret 数据存储 容器的生命周期可能会很短，会被频繁的创建和销毁。那么容器在销毁的时候，保存在容器中的数据也会被清除。这种结果对于用户来说，在某些情况下是不愿意看到的。为了持久化保存容器中的数据，K8s 引入了Volume 的概念。 Volume 是Pod 中能够被多个容器访问的共享目录，它被定义在Pod 上，然后被一个pod 里面的多个容器挂载在具体的文件目录下，K8s 通过Volume 实现同一个Pod
K8S中删除pod，又被重新创建的问题解决
Brave_heart4pzj的博客
04-13 7734
情况如下： k8s中的default空间中，有个Nginx的pod 执行删除命令： kubectl delete pod nginx-55f8fd7cfc-4wxzp 删除后，又重新创建了一个pod，无法删除。 解决办法： 先查询deployment [root@master ~]# kubectl get deployment NAME READY UP-TO-DATE AVAILABLE AGE nginx 1/1 1 1 3d1
k8s节点踢出重新加入集群
Black794的博客
04-29 350
k8s节点踢出重新加入集群。token 过期的话会加入不成功提示Unauthorized，生成一个新的token就好了。驱逐调节点上的pod。
使用filebeat收集容器日志 但是pod 可能在不通的节点 怎么区分呢 在kibana怎么擦看呢
最新发布
03-31
<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、付费专栏及课程。

余额充值