1. 问题现象与初步排查那天凌晨3点我被刺耳的告警声惊醒。监控系统显示生产环境的K8S集群出现大面积Pod异常重启API Server响应延迟飙升至5秒以上。作为这个拥有200节点的集群负责人我立即打开终端开始这场破案之旅。首先检查集群整体状态kubectl get nodes -o wide kubectl get pods -A --field-selectorstatus.phase!Running发现约30%的节点处于NotReady状态且故障节点没有明显地域分布规律。更奇怪的是这些节点本身的kubelet进程都正常运行SSH连接也无异常。2. 关键线索收集与分析2.1 etcd集群健康检查考虑到API Server的高延迟首先怀疑etcd集群ETCDCTL_API3 etcdctl --endpointshttps://etcd1:2379,https://etcd2:2379 \ --cert/etc/kubernetes/pki/etcd/server.crt \ --key/etc/kubernetes/pki/etcd/server.key \ --cacert/etc/kubernetes/pki/etcd/ca.crt endpoint status -w table输出显示三个etcd节点中有两个的Raft Term异常增长且leader频繁切换。这解释了API Server的延迟问题但还需要找到根本原因。2.2 网络性能分析使用ping和mtr工具检测节点间网络mtr -rwzc 60 etcd1发现部分worker节点到etcd集群的包丢失率高达15%且存在30ms以上的抖动。进一步用tcpping检查2379端口tcpping -x 5 etcd1 2379确认部分TCP连接建立需要重试多次。3. 根因定位3.1 网络拓扑验证通过对比网络设备日志和K8S节点部署图发现所有故障节点都连接在同一个TOR交换机上。该交换机CPU利用率持续在90%以上且存在CRC错误计数增长。3.2 磁盘IO压力测试对etcd节点进行磁盘基准测试fio --namerandom-write --ioenginesync --rwrandwrite \ --bs4k --numjobs1 --size4G --runtime60 --time_based --end_fsync1发现一个etcd节点的NVMe SSD写入延迟波动极大p99从1ms到500ms不等smartctl检查显示该磁盘已进入只读保护模式。4. 解决方案实施4.1 紧急恢复措施隔离故障磁盘的etcd节点etcdctl member remove member-id临时调整kubelet节点状态更新频率# /var/lib/kubelet/config.yaml nodeStatusUpdateFrequency: 10s4.2 长期改进方案网络架构优化将etcd集群迁移到专用网络分区配置QoS策略保证etcd流量优先级部署BGP ECMP实现多路径负载均衡存储层加固# etcd manifest增加健康检查 livenessProbe: exec: command: - /bin/sh - -ec - ETCDCTL_API3 etcdctl --write-outtable endpoint status initialDelaySeconds: 60 periodSeconds: 305. 验证与监控增强部署改进后的监控看板重点关注以下指标etcd磁盘写入延迟histogram_quantile(0.99, rate(etcd_disk_wal_fsync_duration_seconds_bucket[5m]))网络设备错误计数increase(ifInErrors{device~sw.*}[5m])Raft提案失败率rate(etcd_server_proposals_failed_total[5m])配置对应的告警规则- alert: HighEtcdFSyncLatency expr: histogram_quantile(0.99, rate(etcd_disk_wal_fsync_duration_seconds_bucket[5m])) 0.5 for: 5m6. 经验总结关键发现底层网络设备故障会表现为K8S控制面不稳定etcd对网络抖动极其敏感50ms以上的延迟就会导致leader切换必须对存储设备进行定期健康检查排查技巧当出现集群级故障时先画物理拓扑图使用etcdctl endpoint hashkv比较各节点数据一致性在非业务高峰定期执行kubectl drain --ignore-daemonsets测试节点恢复能力推荐工具链网络诊断mtr tcpping wireshark存储分析fio smartctl iotopK8S调试kubectl-debug ephemeral containers
1. 问题现象与初步排查那天凌晨3点我被刺耳的告警声惊醒。监控系统显示生产环境的K8S集群出现大面积Pod异常重启API Server响应延迟飙升至5秒以上。作为这个拥有200节点的集群负责人我立即打开终端开始这场破案之旅。首先检查集群整体状态kubectl get nodes -o wide kubectl get pods -A --field-selectorstatus.phase!Running发现约30%的节点处于NotReady状态且故障节点没有明显地域分布规律。更奇怪的是这些节点本身的kubelet进程都正常运行SSH连接也无异常。2. 关键线索收集与分析2.1 etcd集群健康检查考虑到API Server的高延迟首先怀疑etcd集群ETCDCTL_API3 etcdctl --endpointshttps://etcd1:2379,https://etcd2:2379 \ --cert/etc/kubernetes/pki/etcd/server.crt \ --key/etc/kubernetes/pki/etcd/server.key \ --cacert/etc/kubernetes/pki/etcd/ca.crt endpoint status -w table输出显示三个etcd节点中有两个的Raft Term异常增长且leader频繁切换。这解释了API Server的延迟问题但还需要找到根本原因。2.2 网络性能分析使用ping和mtr工具检测节点间网络mtr -rwzc 60 etcd1发现部分worker节点到etcd集群的包丢失率高达15%且存在30ms以上的抖动。进一步用tcpping检查2379端口tcpping -x 5 etcd1 2379确认部分TCP连接建立需要重试多次。3. 根因定位3.1 网络拓扑验证通过对比网络设备日志和K8S节点部署图发现所有故障节点都连接在同一个TOR交换机上。该交换机CPU利用率持续在90%以上且存在CRC错误计数增长。3.2 磁盘IO压力测试对etcd节点进行磁盘基准测试fio --namerandom-write --ioenginesync --rwrandwrite \ --bs4k --numjobs1 --size4G --runtime60 --time_based --end_fsync1发现一个etcd节点的NVMe SSD写入延迟波动极大p99从1ms到500ms不等smartctl检查显示该磁盘已进入只读保护模式。4. 解决方案实施4.1 紧急恢复措施隔离故障磁盘的etcd节点etcdctl member remove member-id临时调整kubelet节点状态更新频率# /var/lib/kubelet/config.yaml nodeStatusUpdateFrequency: 10s4.2 长期改进方案网络架构优化将etcd集群迁移到专用网络分区配置QoS策略保证etcd流量优先级部署BGP ECMP实现多路径负载均衡存储层加固# etcd manifest增加健康检查 livenessProbe: exec: command: - /bin/sh - -ec - ETCDCTL_API3 etcdctl --write-outtable endpoint status initialDelaySeconds: 60 periodSeconds: 305. 验证与监控增强部署改进后的监控看板重点关注以下指标etcd磁盘写入延迟histogram_quantile(0.99, rate(etcd_disk_wal_fsync_duration_seconds_bucket[5m]))网络设备错误计数increase(ifInErrors{device~sw.*}[5m])Raft提案失败率rate(etcd_server_proposals_failed_total[5m])配置对应的告警规则- alert: HighEtcdFSyncLatency expr: histogram_quantile(0.99, rate(etcd_disk_wal_fsync_duration_seconds_bucket[5m])) 0.5 for: 5m6. 经验总结关键发现底层网络设备故障会表现为K8S控制面不稳定etcd对网络抖动极其敏感50ms以上的延迟就会导致leader切换必须对存储设备进行定期健康检查排查技巧当出现集群级故障时先画物理拓扑图使用etcdctl endpoint hashkv比较各节点数据一致性在非业务高峰定期执行kubectl drain --ignore-daemonsets测试节点恢复能力推荐工具链网络诊断mtr tcpping wireshark存储分析fio smartctl iotopK8S调试kubectl-debug ephemeral containers
知识建站
内容驱动
阅读友好版式
SEO 精细化
线索转化