k8s 是怎么实现故障转移的

<think>好的，用户现在问的是Kubernetes如何实现故障转移。之前他们问过拓扑域的自定义，现在可能是在深入集群管理的问题。首先，我需要回忆一下Kubernetes的故障转移机制，包括自愈能力、控制器、探针这些基本概念。用户可能对Pod的重启、重新调度、负载均衡这些方面感兴趣，需要分步骤解释清楚。 用户可能是一个刚开始接触K8s的开发者或者运维，他们想了解如何确保应用的高可用性。之前的回答里提到了拓扑域和节点标签，这次的问题更偏向于故障恢复机制。需要明确故障转移的不同层面，比如Pod级别、节点级别、服务级别和存储级别，每个层面都有不同的机制。 要确保回答结构清晰，分点说明每个组件的作用。比如，Pod的重启策略由kubelet处理，而节点故障转移则涉及节点控制器和驱逐策略。服务层面的故障转移需要结合Service和Endpoint，而存储部分则涉及PV和PVC的重新绑定。 另外，用户可能对实际配置操作感兴趣，比如如何设置探针、定义PodDisruptionBudget，或者使用StatefulSet管理有状态应用。需要给出具体的配置示例，这样他们可以跟着操作。同时，注意事项部分要提醒用户一些常见问题，比如探针配置不当可能导致的问题，或者存储卷的注意事项。 要检查是否有遗漏的重要机制，比如HPA虽然不是直接的故障转移，但和整体高可用相关，是否需要提及？可能简要提到，但主要聚焦在故障转移本身。另外，用户可能没有考虑到网络分区的情况，或者存储持久化的挑战，这些在注意事项里可以补充。 最后，总结部分要强调K8s的多层次机制，以及需要用户根据应用需求合理配置，结合之前的拓扑域自定义，可能形成完整的解决方案。确保语言通俗易懂，避免过于技术化的术语，但又要准确无误。</think>### Kubernetes 故障转移机制详解 Kubernetes 通过**多层次自愈机制**实现故障转移，确保应用在节点故障、Pod 异常等场景下自动恢复。以下是核心实现方式： --- ### 一、Pod 级别的故障转移 #### 1. **容器重启策略（RestartPolicy）** - **作用**：当容器异常退出时自动重启。 - **配置字段**：在 Pod 的 `spec.restartPolicy` 中定义： - `Always`（默认）：总是重启 - `OnFailure`：仅在非0退出码时重启 - `Never`：不重启 ```yaml apiVersion: v1 kind: Pod metadata: name: myapp spec: restartPolicy: OnFailure # 自定义重启策略 containers: - name: main image: nginx ``` #### 2. **存活探针（Liveness Probe）** - **作用**：检测容器是否存活，若失败则触发重启。 - **探测方式**：HTTP 请求、TCP 端口检查、执行命令。 ```yaml containers: - name: web livenessProbe: httpGet: path: /health port: 8080 initialDelaySeconds: 15 # 容器启动后15秒开始探测 periodSeconds: 10 # 每10秒探测一次 failureThreshold: 3 # 连续失败3次后重启 ``` --- ### 二、节点级别的故障转移 #### 1. **节点状态监控** - **kubelet 心跳机制**：节点上的 kubelet 定期向控制平面发送心跳信号（默认每10秒一次）。 - **节点控制器（Node Controller）**： - 若节点超过 `--node-monitor-grace-period`（默认40秒）未上报状态，标记为 `NotReady`。 - 持续 `--pod-eviction-timeout`（默认5分钟）后，驱逐节点上的 Pod。 #### 2. **Pod 驱逐与重新调度** - **驱逐策略**：节点故障后，调度器将 Pod 重新分配到健康节点。 - **污点与容忍度（Taints/Tolerations）**： - 节点故障时自动添加 `node.kubernetes.io/unreachable` 污点。 - Pod 若无对应容忍度，会被驱逐。 --- ### 三、服务级别的故障转移 #### 1. **Service 负载均衡** - **Endpoint 动态更新**：Service 通过 Endpoint 对象实时跟踪 Pod IP。 - **故障 Pod 自动剔除**：kube-proxy 根据 Endpoint 变化更新 iptables/IPVS 规则，流量不再路由到异常 Pod。 #### 2. **就绪探针（Readiness Probe）** - **作用**：检测 Pod 是否准备好接收流量，若失败则从 Service 的 Endpoint 中移除。 ```yaml readinessProbe: exec: command: ["/bin/check-service-ready"] initialDelaySeconds: 5 periodSeconds: 5 ``` --- ### 四、有状态应用的故障转移 #### 1. **StatefulSet 控制器** - **有序部署**：按顺序创建/删除 Pod，确保唯一网络标识（如 `web-0`, `web-1`）。 - **持久卷（PersistentVolume）绑定**： - Pod 重新调度时自动绑定原有 PV，防止数据丢失。 ```yaml apiVersion: apps/v1 kind: StatefulSet metadata: name: mysql spec: serviceName: "mysql" replicas: 3 template: spec: volumes: - name: data persistentVolumeClaim: claimName: mysql-pvc ``` #### 2. **Operator 模式** - **自定义控制器**：如 etcd-operator、Prometheus-operator，实现复杂有状态应用的自愈逻辑。 --- ### 五、高级容错机制 #### 1. **PodDisruptionBudget（PDB）** - **作用**：限制维护性操作（如节点排水）导致的同时中断的 Pod 数量。 ```yaml apiVersion: policy/v1 kind: PodDisruptionBudget metadata: name: zk-pdb spec: minAvailable: 2 # 至少保持2个Pod可用 selector: matchLabels: app: zookeeper ``` #### 2. **多副本与反亲和性** - **跨节点/区域部署**：通过 `podAntiAffinity` 强制 Pod 分散在不同拓扑域。 ```yaml affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: app operator: In values: ["critical-app"] topologyKey: "kubernetes.io/hostname" # 确保每个节点只运行一个实例 ``` --- ### 六、故障转移流程图解 ``` 节点故障检测 │ ▼ 节点标记为 NotReady（Node Controller） │ ▼ Pod 驱逐（kube-controller-manager） │ ▼ Pod 重新调度（kube-scheduler） │ ▼ 新 Pod 绑定原有存储卷（PV/PVC） │ ▼ 服务流量切换至新 Pod（kube-proxy + Endpoint） ``` --- ### 七、注意事项 1. **存储卷持久化**：无状态应用可直接重建，有状态应用需确保 PV 支持 `ReadWriteOnce` 或 `ReadWriteMany`。 2. **探针配置优化**： - 避免过于敏感的存活探针导致频繁重启 - 就绪探针超时时间需大于服务启动时间 3. **集群规模影响**： - 大规模集群中，故障转移可能引发“惊群效应”（大量 Pod 同时调度） - 可通过 `--large-cluster` 参数调整控制器性能 --- ### 八、总结 Kubernetes 通过以下核心机制实现故障转移： 1. **自愈**：容器重启、探针检测、Pod 驱逐 2. **调度**：自动重新绑定存储、跨节点/区域调度 3. **服务发现**：动态 Endpoint 更新、负载均衡 4. **扩展性**：StatefulSet、Operator 支持复杂场景 实际应用中需结合监控（如 Prometheus）、日志（如 Loki）和告警（如 Alertmanager）构建完整的高可用体系。