centos k8s部署如何实现故障恢复

CentOS环境下Kubernetes部署故障恢复指南

Kubernetes（K8s）的高可用性与自愈能力是其核心优势，但在CentOS环境中部署时，仍可能因节点故障、Pod崩溃、存储问题或网络异常等场景导致服务中断。以下是常见故障类型的恢复步骤及长效预防机制，覆盖从快速应急到根本解决的完整流程。

一、常见故障类型及快速恢复步骤

1. Pod崩溃或未就绪

Pod是K8s中最小的调度单元，其故障直接影响应用可用性。常见原因包括容器进程崩溃、健康检查失败、资源不足等。

自动恢复：K8s通过**控制器（Deployment/ReplicaSet）**实现Pod自愈。若Pod因异常退出，控制器会自动创建新Pod替代（需确保replicas数量充足）。可通过kubectl get pods -w观察Pod状态变化，确认是否自动恢复。

手动介入：若自动恢复失败，需检查Pod详情定位原因：

kubectl describe pod <pod-name>  # 查看Pod事件（如CrashLoopBackOff、ImagePullBackOff）
kubectl logs <pod-name> -n <namespace>  # 查看容器日志（若容器已退出，添加--previous查看上次日志）
kubectl exec -it <pod-name> -n <namespace> -- /bin/sh  # 进入容器内部调试（若容器仍在运行）

配置优化：通过健康检查（Liveness/Readiness Probe）告知K8s应用状态，避免无效重启。例如，为Nginx配置HTTP探针：

livenessProbe:
  httpGet:
    path: /healthz
    port: 80
  initialDelaySeconds: 10  # 容器启动后等待10秒再开始探测
  periodSeconds: 5         # 每5秒探测一次
readinessProbe:
  httpGet:
    path: /ready
    port: 80
  initialDelaySeconds: 5
  periodSeconds: 3

若Liveness Probe失败，K8s会自动重启容器；若Readiness Probe失败，K8s会将Pod从Service的Endpoints中摘除，避免流量转发至未就绪的Pod。

2. 节点NotReady或宕机

节点状态异常（如NotReady）会导致其上的Pod无法正常调度或运行，常见原因包括kubelet崩溃、网络中断、磁盘空间不足等。

紧急恢复：
- 重启kubelet：若节点因kubelet故障无法通信，可通过systemctl restart kubelet重启服务，随后检查节点状态：kubectl get nodes（若状态恢复为Ready，则问题解决）。
- 排空节点（Drain）：若节点需长时间维修，需将节点上的Pod安全驱逐至其他健康节点，避免服务中断：
```
kubectl drain <node-name> --ignore-daemonsets --delete-emptydir-data
```
  --ignore-daemonsets忽略DaemonSet管理的Pod（如日志收集组件），--delete-emptydir-data删除EmptyDir卷中的数据（若Pod无需持久化）。
根源修复：
- kubelet配置优化：调整资源阈值（如内存、磁盘），避免因资源压力导致kubelet崩溃。编辑/etc/kubernetes/kubelet-config.yaml，修改以下参数：
```
evictionHard:  # 触发Pod驱逐的资源阈值
  memory.available: "10%"  # 内存剩余10%时触发驱逐（默认85%）
oomScoreAdj: -999  # 降低kubelet被系统OOM Killer终止的概率
```
  修改后重启kubelet：systemctl daemon-reload && systemctl restart kubelet。
- 网络修复：若节点因网络中断导致NotReady，需检查网络链路（如交换机端口、网线）、节点IP配置及防火墙规则，确保节点与API Server通信正常。
- 节点替换：若节点硬件故障无法修复，需添加新节点并加入集群：
```
# 在新节点上安装Kubernetes组件（kubelet、kubeadm）
kubeadm join <master-ip>:<port> --token <token> --discovery-token-ca-cert-hash <hash>
```
  加入后，K8s会自动调度Pod至新节点。

3. 存储问题（PV/PVC异常）

持久化存储故障（如PV无法绑定、PVC Pending）会导致有状态应用（如数据库）无法运行，常见原因包括存储后端不可用、存储类（StorageClass）配置错误等。

恢复步骤：
- 检查PV/PVC状态：kubectl get pv、kubectl get pvc -n <namespace>，查看是否绑定成功（STATUS为Bound）。
- 验证存储后端：若使用NFS/Ceph等外部存储，检查存储服务是否正常运行（如systemctl status nfs-server），并确认存储路径权限正确。
- 重建PV：若PV丢失，可通过备份恢复（如NFS共享中的数据），或重新创建PV并关联PVC：
```
apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-pv
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  nfs:
    server: nfs-server-ip
    path: /data/k8s
```
- 使用Velero备份：为避免存储数据丢失，建议使用Velero定期备份PVC数据。安装Velero后，执行velero backup create <backup-name> --include-namespaces <namespace>即可备份指定命名空间的PVC。

4. 网络异常（Pod/Service无法通信）

网络问题是K8s集群的常见故障，表现为Pod无法访问其他Pod、Service无法解析或转发流量，常见原因包括CNI插件故障、网络策略限制、DNS配置错误等。

排查步骤：
- 检查CNI插件：若使用Calico/Flannel，查看插件Pod状态：kubectl get pods -n kube-system | grep calico（若状态为CrashLoopBackOff，需重启插件Pod或修复插件配置）。
- 测试网络连通性：进入Pod内部，使用ping、curl或nslookup测试与其他Pod/Service的通信：
```
kubectl exec -it <pod-name> -n <namespace> -- ping <other-pod-ip>
kubectl exec -it <pod-name> -n <namespace> -- nslookup <service-name>
```
- 检查网络策略：若配置了NetworkPolicy，确认是否限制了Pod间的通信：kubectl get networkpolicy -n <namespace>。
- 验证DNS配置：检查CoreDNS/Kube-DNS是否正常运行（kubectl get pods -n kube-system | grep coredns），并通过nslookup测试域名解析：
```
kubectl run -it --rm --image=busybox:1.28 dns-test --restart=Never -- nslookup kubernetes.default
```
  若解析失败，需检查CoreDNS配置（kubectl get configmap -n kube-system coredns -o yaml）或重启CoreDNS Pod。

二、长效故障预防机制

监控与告警：部署Prometheus+Grafana监控集群状态（节点资源、Pod状态、网络流量），设置告警阈值（如节点内存使用率>80%、Pod重启次数>3次/分钟），及时发现潜在问题。
备份策略：定期备份etcd数据（K8s核心存储）、PVC数据（持久化卷），使用etcdctl snapshot save命令备份etcd，使用Velero备份PVC。
版本兼容性：确保K8s组件（kubelet、kube-apiserver、kube-controller-manager）与CentOS版本兼容，参考Kubernetes官方文档的版本矩阵选择稳定版本。
测试环境验证：所有配置变更（如升级K8s版本、修改网络插件）需先在测试环境验证，避免直接应用于生产环境。

通过以上步骤，可快速恢复CentOS环境下K8s部署的常见故障，并通过长效机制降低故障复发概率，保障集群稳定运行。