master资源不足导致pods被驱逐-The node had condition: [DiskPressure].

此文主要内容为新建一个盘,创建软链接,查找大文件,批量删除驱逐状态的pod

查看demo环境发现跑在master上的pods都是Evicted 被驱逐的状态-如图
在这里插入图片描述

deacribe被驱逐的pod,发现是硬盘资源不足导致。The node had condition: [DiskPressure].

查看硬盘资源,发现根目录下资源已经使用97%。
在这里插入图片描述
准备了一块新盘,但是没有使用,于是来新建一块盘。
可以使用disk -l 查看所有的盘。这里因为记录已经过掉了,故无截图。

增加一个硬盘

#新建一个分区
fdisk -l   #查看硬盘
fdisk /dev/sdc    # .dev/sdb为挂载需要的硬盘
m   #查看帮助信息
n    # 添加一个新的分区
p   #输出分区表
1  #这里的数字要看情况,一般使用默认的就好 
enter    #默认就好
enter    #默认就好
w  #将刚做的配置写入内核

#格式化硬盘
mkfs.ext4 /dev/sdc1   #格式化  1 是上面步骤的
mkdir /data
mount  /dev/sdc1 /data   #将硬盘挂载到data目录下

#永久挂载
vi /etc/fstab 永久挂载 按照文本的写法
/dev/sdc1  /data   ext4    defaults 0 0 

挂载好文件后,查看是否挂载成功

[root@demo-master ~]# mount | grep /dev/sdc
/dev/sdc1 on /data type ext4 (rw,relatime,data=ordered)

df -h 查看很多的文件都是docker的,于是想着将docker的东西存到data目录下,如果要修改docker文件的额默认地址,会比较麻烦,可以使用软链接连过去。

创建软链接

cp -a /var/lib/dokcer /tmp/    #备份
cp -a docker /data/    #注意此处需要-a
ln -s /data/docker/ ./       #创建软链接 

在这里插入图片描述
软链接创建完成,可以尝试往/var/lib/docker里面写入文件,你会在/data/docker目录下看到这个文件。
在这里插入图片描述
将文件移除后,发现磁盘占用还是大于80%,再继续查看有哪些文件是占了很大空间的。

后来觉得日志文件也比较大,于是把日志文件也移到/data目录下了,这样根目录下的磁盘空间不回持续增加

查找大文件
find . -type f -size +500M  -print0 | xargs -0 du -h | sort -nr

查找大于500M的文件,然后按数值大小排倒序

最后删除一些东西之后,根目录磁盘占比为75,将处于驱逐状态的pod删除,然后运行成功。

kubectl get pod -o wide --all-namespaces | awk '{if($4=="Evicted"){cmd="kubectl -n "$1" delete pod "$2; system(cmd)}}'
<think>好的,用户提供了一个关于Rook Ceph的日志条目,需要我帮忙解析。日志内容是: 2025-03-29 14:24:23.248871 W | op-mon: failed to check mon health. failed to get mon quorum status: mon quorum status failed: exit status 1 首先,我需要理解这个日志的结构和内容。时间戳是2025年,不过这可能只是示例时间。日志级别是警告(W),来自op-mon模块,说明是监控相关的组件。信息是检查mon的健康状态失败,无法获取quorum状态,退出状态1。 接下来,我需要分解这个错误的原因。可能的原因有几个方向:Monitors(mon)进程本身有问题,比如进程崩溃或未运行;网络问题导致无法连接到mon;身份验证问题,比如证书或密钥错误;或者资源不足,如CPU、内存不足导致mon无法响应。 然后,我需要考虑用户可能的背景。用户可能是在管理一个使用Rook部署的Ceph集群,遇到了监控组件的问题,导致健康检查失败。用户可能对Kubernetes和Ceph有一定了解,但需要具体的故障排除步骤。 用户的需求不仅仅是了解日志的含义,更想知道如何解决这个问题。因此,我需要提供逐步的排查步骤,包括检查mon的Pod状态、查看mon的日志、检查网络连接、验证身份认证文件、检查资源使用情况,以及可能的修复措施,比如重启mon Pod或重新部署Rook Operator。 此外,需要注意用户之前的历史问题,之前有过资源版本冲突的错误,但这次是监控问题,可能两者之间没有直接关联,但都是Rook Ceph集群的常见问题。用户可能需要综合的排错指导,确保他们能够系统地检查和解决问题。 最后,需要确认是否需要进一步的信息,比如具体的命令输出,或者更详细的环境情况,以帮助更精确地定位问题。同时,提醒用户如果问题持续存在,应该收集更多日志或寻求社区支持。</think>以下是针对该警告日志的逐步解析与处理建议: --- ### 一、日志分解 ```log 2025-03-29 14:24:23.248871 W | op-mon: failed to check mon health. failed to get mon quorum status: mon quorum status failed: exit status 1 ``` #### 层级分析: 1. **触发模块**:`op-mon`(Rook Ceph的Monitor管理模块) 2. **警告类型**:`W |`(Warning,表示需要关注但未直接影响核心功能) 3. **错误链**: - 健康检查失败 → 无法获取Mon仲裁状态 → 底层命令执行失败(exit code 1) --- ### 二、核心问题:**Ceph Monitor仲裁状态异常** #### 可能原因: | 类型 | 具体场景 | 检测方法 | |------|----------|----------| | **Mon进程崩溃** | Monitor Pod异常终止 | `kubectl -n rook-ceph get pods -l app=rook-ceph-mon` | | **网络隔离** | Mon节点间通信受阻 | `kubectl exec <mon-pod> -- ceph ping mon.<mon-id>` | | **时钟不同步** | 节点间时间差超过阈值 | `kubectl exec <mon-pod> -- chronyc sources` | | **磁盘空间不足** | Mon数据目录写满 | `kubectl exec <mon-pod> -- df -h /var/lib/ceph/mon` | | **认证失效** | Keyring文件损坏 | `kubectl describe secret rook-ceph-mon -n rook-ceph` | --- ### 三、排查步骤 #### 步骤1:检查Monitor Pod状态 ```bash kubectl -n rook-ceph get pods -l app=rook-ceph-mon -o wide ``` - **期望状态**:所有mon Pod应为`Running`且`READY 1/1` - **异常处理**: -Pod处于`CrashLoopBackOff`,查看日志: ```bash kubectl -n rook-ceph logs <故障mon-pod> -c mon ``` -Pod无法调度,检查节点资源: ```bash kubectl describe pod <故障mon-pod> -n rook-ceph | grep -A 10 Events ``` #### 步骤2:验证Mon仲裁状态 ```bash # 进入任意健康mon Pod执行 kubectl -n rook-ceph exec -it <mon-pod> -- ceph quorum_status ``` - **正常输出**应包含`quorum`列表和选举epoch值: ```json {"election_epoch": 12, "quorum": [0,1,2], ...} ``` - **异常表现**: - 返回`Error EACCES` → 认证问题 - 返回`Connection refused` → 网络问题 #### 步骤3:检查Ceph集群状态 ```bash kubectl -n rook-ceph exec deploy/rook-ceph-tools -- ceph -s ``` 重点关注: ```log health: HEALTH_WARN # 出现健康警告 monmap: ... # Mon数量是否与预期一致 quorum: ... # 仲裁成员是否完整 ``` --- ### 四、修复方案 #### 场景1:单个Mon失效 ```bash # 删除失效Mon Pod(Kubernetes会自动重建) kubectl -n rook-ceph delete pod <故障mon-pod> # 强制刷新Mon部署 kubectl -n rook-ceph rollout restart deploy/rook-ceph-mon-<mon-id> ``` #### 场景2:仲裁永久丢失 当超过半数的Mon不可恢复时: 1. 通过Rook CRD手动修复: ```yaml apiVersion: ceph.rook.io/v1 kind: CephCluster metadata: name: rook-ceph namespace: rook-ceph spec: mon: count: 3 # 确保数量为奇数(3/5/7) allowMultiplePerNode: false ``` 2. 执行强制恢复: ```bash kubectl -n rook-ceph exec deploy/rook-ceph-operator -- rook ceph mon restore ``` --- ### 五、预防措施 1. **Mon部署规范**: - 始终部署**奇数个**Mon(推荐3/5个) - 跨节点分布(使用`PodAntiAffinity`) 2. **监控配置**: ```yaml # rook-ceph-cluster.yaml 片段 monitoring: enabled: true rulesNamespace: rook-ceph ``` 3. **资源预留**: ```yaml resources: mon: limits: cpu: "2" memory: "4Gi" requests: cpu: "1" memory: "2Gi" ``` --- ### 六、深度原理 #### Ceph Mon仲裁机制 - **法定人数算法**:要求超过半数的Mon节点达成共识(例如3节点需至少2个在线) - **状态同步**:通过Paxos协议保证数据一致性 - **故障检测**: - 每个Mon通过`heartbeat_interval`(默认1s)检测邻居状态 - 超时`mon_lease`(默认5s)后触发重新选举 数学表达式: 法定人数最低要求为 $Q = \left\lfloor \frac{N}{2} \right\rfloor + 1$,其中$N$为Mon总数。 --- 请根据实际排查结果选择对应修复方案。若问题持续,建议附上`ceph -s`完整输出和mon Pod日志进一步分析。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值