Kubernetes节点网络失联的影响

当Kubernetes节点因网络问题失联时，集群行为会因配置和组件状态产生连锁反应。以下是关键影响点：

节点状态变为NotReady
kube-controller-manager通过kubelet心跳（默认10秒间隔）检测节点健康状态。若持续失联超过node-monitor-grace-period（默认40秒），节点状态标记为NotReady。此时：

• 节点上的Pod仍显示在API中，但状态不会更新
• 控制平面无法通过kubelet操作该节点上的Pod

Pod驱逐与重新调度
若节点失联超过pod-eviction-timeout（默认5分钟），kube-controller-manager会触发驱逐逻辑：

• DaemonSet Pod会被保留，等待节点恢复
• 其他Pod被标记为Terminating并从API删除
• 若Pod由Deployment等控制器管理，新Pod会在其他健康节点重建

服务流量中断
失联节点上的Service Endpoints会被kube-controller-manager从Endpoint对象中移除：

• 已建立的TCP连接可能继续工作（依赖具体CNI实现）
• 新连接请求会被转发到其他健康节点
• 若所有副本均在同一失联节点，服务完全不可用

存储卷行为
有状态应用可能受影响：

• 使用本地存储的Pod数据可能丢失
• 网络存储（如EBS、NFS）通常能保持数据，但需等待恢复或手动干预
• StatefulSet会等待persistentVolumeReclaimPolicy决定的处理方式

关键配置参数调整建议

延长容忍时间
修改kube-controller-manager参数应对临时网络抖动：

--node-monitor-grace-period=60s      # 默认40秒
--pod-eviction-timeout=10m           # 默认5分钟

配置PDB防止大规模中断
通过PodDisruptionBudget限制驱逐比例：

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: zk-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: zookeeper

使用拓扑分布约束
避免单点故障导致全部副本不可用：

topologySpreadConstraints:
- maxSkew: 1
  topologyKey: kubernetes.io/hostname
  whenUnsatisfiable: DoNotSchedule

网络分区特殊场景处理

控制平面隔离
当部分control-plane节点失联时：

• etcd集群需要多数节点存活才能维持写入
• 存活节点少于(N/2)+1时，集群进入只读模式
• 需要手动干预恢复quorum

工作节点隔离
完全隔离的工作节点会出现：

• kubelet无法上报状态
• Pod可能被误驱逐（若控制平面误判）
• 节点恢复后可能出现资源冲突

解决方案建议

• 部署多区域控制平面（使用--apiserver-count）
• 配置--node-status-update-frequency调整心跳频率
• 使用kubectl cordon手动标记节点避免自动调度

网络恢复后，节点重新加入集群时会经历kubelet重启、容器检查等过程，系统会自动尝试恢复工作负载到期望状态。