离线环境下设备内置K8s集群架构设计咨询

问题1：控制平面与工作节点同节点部署的潜在问题及最佳实践 #

潜在问题 #

• 资源竞争失控：控制平面组件（kube-apiserver、etcd、kube-controller-manager等）和业务Pod共享节点资源，业务高负载时会挤占控制组件的CPU、内存，导致集群响应延迟、甚至控制平面崩溃，整个服务集群完全失控。
• 单点故障放大：节点一旦宕机，控制平面和所有业务负载同时失效，没有备用节点接管控制功能，集群恢复依赖节点硬件/系统的恢复，容错能力极低。
• 安全边界模糊：工作节点通常需要挂载宿主机设备、配置业务相关的权限，控制平面组件在同一节点上运行，若业务Pod被攻破，攻击者可直接接触到控制平面的敏感组件和数据，大幅提升集群被接管的风险。
• 运维操作风险高：节点升级、补丁安装等操作时，既要保证控制平面不中断，又要兼顾业务可用性，操作容错空间极小，稍有不慎就会引发服务中断。

最佳实践 #

• 隔离控制平面与业务负载：给节点打上污点，阻止普通业务Pod调度到该节点：

  kubectl taint nodes <your-node-name> node-role.kubernetes.io/control-plane:NoSchedule
  

  同时给控制平面组件添加对应的容忍度，确保它们能正常运行在该节点上，从调度层面减少资源竞争。
• 强制资源预留与QoS保障：
  • 为控制平面组件配置Guaranteed级别的QoS，将requests和limits设为相同值，确保kubelet优先分配资源给控制组件。
  • 通过kubelet参数--reserved-cpus、--reserved-memory为控制平面预留固定资源，比如--reserved-cpus=2 --reserved-memory=4Gi，避免业务Pod耗尽节点核心资源。
• etcd数据独立存储与备份：将etcd数据目录挂载到设备内置的独立SSD分区，避免和业务存储互相影响。同时配置CronJob定时执行etcd快照备份：

  etcdctl snapshot save /var/lib/etcd/snapshots/etcd-snapshot-$(date +%Y%m%d%H%M).db
  

  确保节点故障后能快速恢复etcd数据。
• 轻量监控告警：在设备内置监控脚本，定期采集控制组件的CPU、内存使用率以及etcd磁盘状态，一旦触发阈值（比如etcd磁盘使用率超过85%），自动触发本地告警（比如设备指示灯闪烁、本地日志标记），提前排查风险。

问题2：控制器Pod/节点故障的自动重分配与重建方案 #

控制器Pod故障自愈 #

• 利用K8s原生控制器自愈：控制平面组件（kube-apiserver、kube-controller-manager等）通过Deployment部署，K8s会自动监控Pod状态。配置livenessProbe和readinessProbe实现故障自动重启，比如kube-apiserver的探针配置：

  livenessProbe:
    httpGet:
      path: /healthz
      port: 6443
      scheme: HTTPS
    initialDelaySeconds: 15
    periodSeconds: 10
    failureThreshold: 3
  

  当探针检测到组件异常时，kubelet会立即重启Pod，无需人工干预。
• etcd故障自动恢复：将etcd用StatefulSet部署并绑定持久化存储，一旦Pod崩溃，StatefulSet会自动重建Pod。同时在Pod启动脚本中添加逻辑：如果数据目录为空，自动从最近的etcd快照恢复数据，确保控制平面能快速恢复状态。

节点故障自动恢复 #

• 节点级自动重启：利用设备的硬件/系统级机制实现节点故障恢复，比如通过BIOS设置自动重启、内置远程管理模块监控节点状态，当节点无响应时强制重启。同时配置systemd监控kubelet服务，一旦kubelet崩溃，自动重启kubelet服务。
• 集群自动重建：节点重启后，kubelet会自动向集群重新注册，控制平面组件会自动重建之前运行的Pod。etcd依赖持久化存储恢复数据后，整个集群会自动恢复到故障前的状态，业务Pod也会被重新调度（单节点场景下直接在本地重建）。
• 隐藏运维细节：将所有K8s故障检测、恢复逻辑封装到设备的内置管理服务中，客户无需接触任何K8s命令行工具，所有故障处理在设备后台自动完成，对外只暴露业务服务的状态。

内容的提问来源于stack exchange，提问作者jAckOdE