📚 课程目录第2章云原生基础回顾

2. 云原生基础回顾：Kubernetes核心组件、命名空间与资源配额、服务网格(Service Mesh)简介

2.1 Kubernetes 核心组件架构

Kubernetes（K8s）是云原生灾备平台的基础编排层。理解其核心组件是设计准入策略与流量路径的前提。集群由 控制平面（Control Plane） 与 工作节点（Worker Nodes） 组成，各组件通过 API Server 进行松耦合通信。

  灾备视角要点： 控制平面组件的高可用部署（多副本 etcd、多 API Server 实例）直接决定 RTO 中集群恢复的启动速度；工作节点上的 kubelet 与 kube-proxy 状态一致性影响应用迁移后的流量可达性。

层级	组件	核心职责	灾备关联性
控制平面	kube-apiserver	所有组件与 CLI 的唯一入口，提供 RESTful API 与认证授权	准入策略（Admission Webhook）在此生效，控制资源创建与变更
	etcd	集群状态持久化存储，键值数据库	灾备恢复的核心数据源，需定期备份；RTO 受 etcd 恢复速度影响
	kube-scheduler	将 Pod 绑定到合适的 Worker Node	灾备切换后调度策略需重新评估节点资源与拓扑约束
	kube-controller-manager	运行各类控制器（Deployment、StatefulSet、Node 等）	控制器循环驱动自愈，灾备场景下需避免脑裂
工作节点	kubelet	管理 Pod 生命周期，与容器运行时交互	节点故障时 kubelet 心跳超时触发 Pod 驱逐
	kube-proxy	维护节点网络规则，实现 Service 负载均衡	流量路径的核心转发层，灾备切换后需重建 iptables/IPVS 规则
	容器运行时	运行容器（containerd、CRI-O 等）	镜像拉取策略与本地缓存影响 Pod 启动时间

2.2 命名空间与资源配额

命名空间（Namespace） 是 Kubernetes 实现多租户隔离的逻辑分区。在灾备场景中，命名空间用于划分环境（生产/灾备/测试）、隔离应用组、控制资源配额与准入策略的作用域。

2.2.1 命名空间的核心作用

资源隔离： 不同命名空间内的 Pod、Service、ConfigMap 相互不可见（通过 NetworkPolicy 可进一步控制网络隔离）。
策略作用域： 准入 Webhook、RBAC、资源配额（ResourceQuota）均以命名空间为粒度生效。
灾备单元： 通常将一组关联微服务部署在同一命名空间，作为灾备切换的最小单元。

2.2.2 资源配额（ResourceQuota）与 LimitRange

资源配额防止单个命名空间耗尽集群资源，是灾备场景下保障关键业务资源预留的关键机制。

资源对象	作用范围	灾备配置建议
ResourceQuota	命名空间级别，限制 CPU、内存、PVC、Pod 总数等	灾备命名空间应预留与生产等额的配额，避免切换后资源不足
LimitRange	命名空间级别，设置 Pod/Container 默认资源请求与限制	确保灾备环境 Pod 启动时具有合理的资源下限，防止被低优先级任务抢占

最佳实践： 使用 kubectl describe quota -n <namespace> 定期审计资源使用率。在灾备演练前，通过 kubectl apply 同步 ResourceQuota 配置，确保目标集群的配额不低于生产集群。

# ResourceQuota 示例：限制命名空间总资源
apiVersion: v1
kind: ResourceQuota
metadata:
  name: dr-quota
  namespace: production-dr
spec:
  hard:
    requests.cpu: "20"
    requests.memory: "40Gi"
    limits.cpu: "40"
    limits.memory: "80Gi"
    persistentvolumeclaims: "10"
    pods: "50"

# LimitRange 示例：设置默认资源请求
apiVersion: v1
kind: LimitRange
metadata:
  name: dr-limit-range
  namespace: production-dr
spec:
  limits:
  - default:
      cpu: "500m"
      memory: "512Mi"
    defaultRequest:
      cpu: "250m"
      memory: "256Mi"
    type: Container

2.3 服务网格（Service Mesh）简介

服务网格是云原生微服务通信的基础设施层，通常以 Sidecar 代理 模式部署。在灾备场景中，服务网格提供流量管理、可观测性与安全通信能力，直接影响 RTO 期间的流量切换路径与灰度验证效率。

2.3.1 核心组件与数据流

数据平面（Data Plane）： 由与每个服务实例一同部署的 Sidecar 代理（如 Envoy）组成，负责拦截、路由、负载均衡服务间流量。
控制平面（Control Plane）： 集中管理代理配置，下发路由规则、故障注入策略与 TLS 证书（如 Istio 的 Pilot、Mixer、Citadel）。

2.3.2 服务网格在灾备中的核心价值

能力	灾备场景应用	RTO 影响
流量路由	基于权重、Header、区域（Region）将流量切至灾备集群	秒级切换，无需修改 DNS 或重新部署
故障注入	在灾备演练中注入延迟/异常，验证降级策略	提前暴露问题，避免真实故障时 RTO 超期
可观测性	分布式追踪、指标、日志统一采集	快速定位灾备切换后的流量异常点
安全通信	mTLS 自动加密服务间通信，证书轮换自动化	减少灾备环境安全配置时间

注意： 服务网格本身也是基础设施组件，在灾备规划中需考虑控制平面的跨集群部署方案。例如，Istio 的多集群主-远程（Primary-Remote）模式可让灾备集群的控制平面独立运行，避免单点故障影响全局流量管理。

2.4 本章小结

Kubernetes 控制平面组件（etcd、API Server、Scheduler、Controller Manager）的 HA 部署是灾备 RTO 的基础保障。
命名空间与资源配额是灾备资源隔离与预留的核心手段，需在灾备集群中保持与生产集群一致的配额配置。
服务网格通过 Sidecar 代理实现流量精细化管理，在灾备切换、灰度验证与安全通信中发挥关键作用。