k8s核心组件API Server与Scheduler高可用方案

Kubernetes核心组件高可用实战：API Server与Scheduler的生存法则

在生产环境中，API Server和Scheduler的高可用设计直接决定集群的稳定性。本文将用运维视角解析这两个关键组件的"保命机制"，并附赠生产环境调优指南。

---

一、API Server高可用：集群的"不死心脏"

1. 多活部署架构（Active-Active）

• 部署模式：
  至少部署3个API Server实例，组成无状态服务集群

  # kubeadm配置示例（/etc/kubernetes/manifests/kube-apiserver.yaml）
  replicas: 3
  

• 流量入口：
  通过负载均衡器（LB）对外暴露服务，常见方案：
  • 云厂商LB（如AWS NLB、阿里云SLB）
  • 自建HAProxy+Keepalived（裸金属环境）

  frontend k8s-api
      bind *:6443
      mode tcp
      default_backend api-servers
  backend api-servers
      balance roundrobin
      server master1 10.0.0.1:6443 check
      server master2 10.0.0.2:6443 check
      server master3 10.0.0.3:6443 check
  

2. 数据一致性保障

• 共享存储：所有API Server连接同一etcd集群

  # API Server启动参数
  --etcd-servers=https://etcd1:2379,https://etcd2:2379,https://etcd3:2379
  

• 读写分离：通过etcd proxy实现读操作负载均衡

3. 自我修复机制

• 健康检查：
  LB定期探测/livez端点（默认端口8001）

  curl -k https://localhost:6443/livez
  

• 自动恢复：
  kubelet监控static pod状态，异常时自动重启

4. 生产调优参数

# 限制并发请求防止过载
--max-requests-inflight=1500
--max-mutating-requests-inflight=500

# 启用请求优先级
--enable-priority-and-fairness=true

# 缓存优化
--watch-cache=true
--watch-cache-sizes=secrets=500,configmaps=500

---

二、kube-scheduler高可用：智能调度官的"备胎计划"

1. Leader选举机制

• 选举原理：
  通过Lease对象进行分布式锁竞争

  kubectl get leases -n kube-system co.k8s.io
  NAME          HOLDER          AGE
  kube-scheduler   master1   15m
  

• 故障转移：Leader失联15秒后触发重新选举

2. 多副本部署方案

# 典型部署结构（3 master节点）
apiVersion: apps/v1
kind: Deployment
metadata:
  name: kube-scheduler
  namespace: kube-system
spec:
  replicas: 3
  strategy:
    rollingUpdate:
      maxUnavailable: 1

3. 生产环境注意事项

• 选举参数调优：

  --leader-elect-lease-duration=15s    # Leader任期
  --leader-elect-renew-deadline=10s    # 续约超时
  --leader-elect-retry-period=2s       # 重试间隔
  

• 调度性能监控：

  # 查看调度延迟
  kubectl get --raw /metrics | grep scheduler_scheduling_algorithm_duration_seconds
  

---

三、生产环境避坑指南

1. 脑裂问题预防

• etcd集群必须保持奇数节点（3/5/7）
• 设置合理心跳参数：

  # etcd配置
  --heartbeat-interval=500
  --election-timeout=2500
  

2. 网络分区应对

• 配置Pod反亲和性：

  affinity:
    podAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: component
            operator: In
            values: ["kube-apiserver"]
        topologyKey: "kubernetes.io/hostname"
  

3. 监控指标关键点

组件	关键指标	报警阈值
API Server	apiserver_request_duration_seconds	P99 > 1s
	apiserver_requests_total	5xx错误率>1%
Scheduler	scheduler_pending_pods	持续增长超过5分钟
	scheduler_scheduling_attempts	单Pod尝试>5次

4. 灾难恢复演练

• 模拟故障场景：

  # 随机终止API Server
  kubectl delete pod -n kube-system kube-apiserver-master1 --force
  
  # 观察流量切换时间（应<30秒）
  watch -n 1 'kubectl get endpoints -n default kubernetes'
  

---

四、高可用架构演进路线

1. 基础版（小型集群）

   • 3 Master节点
   • API Server + etcd混合部署

2. 进阶版（中型集群）

   • 独立etcd集群（5节点）
   • 分离API Server负载均衡层

3. 企业版（超大规模）

   • 区域化部署（多AZ）
   • 分层API Server（聚合层+核心层）
   • 调度器分片（Scheduler Framework）

---

五、写在最后

高可用不是简单的多副本部署，而需要从多个维度构建防御体系：

1. 冗余设计：至少N+1副本，跨故障域部署
2. 快速故障检测：多层健康检查机制
3. 优雅降级：在部分组件故障时保持基本功能
4. 自动化恢复：结合Operator实现自愈

建议每季度执行一次全链路故障演练，真正检验高可用设计的有效性。记住：没有经过实战考验的高可用架构都是纸老虎！