📚 课程目录第4章集群核心组件资源配置

4. 集群核心组件资源配置：kube-apiserver 资源需求分析、etcd 性能与资源调优、kube-scheduler 与 kube-controller-manager 资源配置

Kubernetes 控制平面的四个核心组件——kube-apiserver、etcd、kube-scheduler 与 kube-controller-manager——构成了集群的“大脑”与“中枢神经”。它们的资源配置直接决定了集群的吞吐上限、故障恢复速度以及误差预算的消耗速率。本章将逐一分析每个组件的资源需求特征，并给出基于误差预算台账的调优策略。

4.1 kube-apiserver：集群的流量网关与状态存储前端

kube-apiserver 是所有控制平面操作的唯一入口。它的资源消耗主要由并发请求数、请求复杂度（List vs Watch vs Create）以及 etcd 的响应延迟决定。

4.1.1 资源需求分析

资源维度	关键影响因素	典型基线（500节点集群）	调优方向
CPU	请求认证、鉴权、准入控制链、请求序列化/反序列化	4-8 核（2-4 副本）	增加副本数分散读请求；启用 APF（API 优先级与公平性）
内存	Watch 缓存、对象反序列化后的内存占用、etcd 响应缓存	8-16 GiB	调整 `--watch-cache-size`；监控 `etcd_request_duration_seconds`
网络	客户端连接数、List/Watch 流量、Webhook 回调	1-2 Gbps 入口带宽	启用 TLS 会话复用；使用 HTTP/2 连接池

  误差预算关联： kube-apiserver 的请求延迟直接计入控制平面 SLO。当 P99 请求延迟超过 1s 时，误差预算消耗速率将急剧上升。建议将 --max-requests-inflight 与 --max-mutating-requests-inflight 设置为集群节点数的 3-5 倍，并配合 APF 配置保障高优先级请求（如 kubelet 心跳、Pod 状态更新）不被低优先级 List 请求饿死。

4.1.2 关键配置参数

# kube-apiserver 核心资源配置示例（kube-apiserver.yaml）
spec:
  containers:
  - name: kube-apiserver
    resources:
      requests:
        cpu: "4"
        memory: "8Gi"
      limits:
        cpu: "8"
        memory: "16Gi"
    command:
    - kube-apiserver
    - --advertise-address=10.0.0.1
    - --allow-privileged=true
    - --max-requests-inflight=1500
    - --max-mutating-requests-inflight=750
    - --watch-cache-size=200
    - --enable-admission-plugins=NodeRestriction,PodNodeSelector
    - --request-timeout=60s
    - --v=2

调优建议： 在误差预算台账中记录 apiserver_request_duration_seconds_bucket 的 P99 与 P50 分位数。当 P99 持续超过 500ms 时，优先增加 kube-apiserver 副本数（水平扩展），而非盲目增加单副本的 CPU 限制。

4.2 etcd：集群状态的持久化基石

etcd 是 Kubernetes 的“单点真理源”。它的性能瓶颈通常出现在磁盘 I/O、网络延迟和内存使用上。etcd 的延迟直接决定了 kube-apiserver 的响应速度，进而影响整个控制平面的误差预算。

4.2.1 性能瓶颈与资源调优

资源维度	瓶颈特征	推荐配置	监控指标
磁盘 I/O	WAL 写入延迟高、fsync 耗时	NVMe SSD，独立数据盘与 WAL 盘	`etcd_disk_wal_fsync_duration_seconds`
内存	缓存命中率低、DB 大小超过内存	8-16 GiB（DB 大小建议 < 2 GiB）	`etcd_mvcc_db_total_size_in_bytes`
网络	Raft 心跳延迟、Leader 选举抖动	1-10 Gbps 低延迟网络	`etcd_network_peer_round_trip_time_seconds`
CPU	Raft 协议处理、TLS 加密	4-8 核	`etcd_server_leader_changes_seen_total`

4.2.2 关键调优参数

# etcd 资源配置示例（etcd.yaml）
spec:
  containers:
  - name: etcd
    resources:
      requests:
        cpu: "4"
        memory: "8Gi"
      limits:
        cpu: "8"
        memory: "16Gi"
    command:
    - etcd
    - --data-dir=/var/lib/etcd
    - --wal-dir=/var/lib/etcd/wal
    - --quota-backend-bytes=8589934592  # 8 GiB
    - --auto-compaction-mode=revision
    - --auto-compaction-retention=1000
    - --max-request-bytes=1572864       # 1.5 MiB
    - --snapshot-count=100000
    - --heartbeat-interval=100
    - --election-timeout=1000

避坑指南： 不要将 etcd 数据盘与系统盘共用。etcd 对磁盘延迟极其敏感，即使 10ms 的 fsync 延迟也会导致 Leader 选举频繁触发，直接消耗集群误差预算。建议使用独立 NVMe 盘，并监控 etcd_disk_wal_fsync_duration_seconds 的 P99 是否超过 10ms。

4.2.3 etcd 性能与误差预算的关联

etcd 的延迟直接映射到 kube-apiserver 的请求延迟。以下 SVG 展示了 etcd 性能下降如何逐级放大误差预算消耗：

4.3 kube-scheduler：调度决策的实时性保障

kube-scheduler 负责将新创建的 Pod 分配到合适的节点。它的资源消耗主要来自调度队列管理、节点预选/优选算法以及抢占逻辑。

4.3.1 资源需求与调优

资源维度	消耗特征	推荐配置（500节点）	调优手段
CPU	调度算法计算（节点过滤、打分）	2-4 核	启用 `PercentageOfNodesToScore` 减少计算量
内存	调度队列、Pod 缓存、节点缓存	2-4 GiB	调整 `--permit-wait-timeout` 减少队列积压
调度延迟	从 Pod 创建到调度成功的时间	P99 < 1s	监控 `scheduler_scheduling_algorithm_duration_seconds`

4.3.2 关键配置参数

# kube-scheduler 资源配置示例（kube-scheduler.yaml）
spec:
  containers:
  - name: kube-scheduler
    resources:
      requests:
        cpu: "2"
        memory: "2Gi"
      limits:
        cpu: "4"
        memory: "4Gi"
    command:
    - kube-scheduler
    - --config=/etc/kubernetes/scheduler-config.yaml
    - --v=2
---
# scheduler-config.yaml 关键配置
apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
profiles:
- schedulerName: default-scheduler
  percentageOfNodesToScore: 50
  podMaxBackoffSeconds: 10
  podInitialBackoffSeconds: 1

误差预算关联： 调度延迟直接影响 Pod 启动时间，进而影响应用部署的误差预算。当集群规模超过 1000 节点时，建议将 percentageOfNodesToScore 从默认的 50% 降低到 30%，以平衡调度精度与延迟。

4.4 kube-controller-manager：状态收敛的节拍器

kube-controller-manager 包含数十个控制器（Deployment、ReplicaSet、Node、Endpoint 等），它们通过 Informer 监听资源变化并执行调和循环。

4.4.1 资源需求与调优

资源维度	消耗特征	推荐配置（500节点）	调优手段
CPU	调和循环并发、List/Watch 处理	2-4 核	调整 `--concurrent-deployment-syncs` 等并发参数
内存	Informer 缓存、对象队列	4-8 GiB	监控 `workqueue_depth` 避免队列积压
调和延迟	从资源变更到控制器响应的时间	P99 < 5s	启用 `--enable-taint-manager` 优化节点状态处理

4.4.2 关键配置参数

# kube-controller-manager 资源配置示例（kube-controller-manager.yaml）
spec:
  containers:
  - name: kube-controller-manager
    resources:
      requests:
        cpu: "2"
        memory: "4Gi"
      limits:
        cpu: "4"
        memory: "8Gi"
    command:
    - kube-controller-manager
    - --concurrent-deployment-syncs=10
    - --concurrent-replicaset-syncs=10
    - --concurrent-service-syncs=5
    - --concurrent-endpoint-syncs=10
    - --node-monitor-period=5s
    - --node-monitor-grace-period=40s
    - --pod-eviction-timeout=5m
    - --v=2

避坑指南： 不要将所有控制器并发数设置得过高。例如 --concurrent-deployment-syncs 超过 20 时，可能导致 kube-apiserver 的 List 请求激增，反而增加控制平面延迟。建议从默认值开始，逐步调高并监控 workqueue_depth 与 apiserver_request_duration_seconds。

4.5 核心组件资源配置总结

以下 SVG 展示了四个核心组件的资源需求与误差预算的关联关系：

4.6 基于误差预算的调优决策矩阵

当误差预算消耗异常时，可以通过以下矩阵快速定位核心组件的资源瓶颈：

误差预算消耗特征	可能瓶颈组件	优先检查指标	推荐操作
Pod 创建延迟高	kube-apiserver / kube-scheduler	`apiserver_request_duration_seconds` / `scheduler_scheduling_algorithm_duration_seconds`	增加 apiserver 副本；降低 `percentageOfNodesToScore`
节点状态更新延迟	etcd / kube-controller-manager	`etcd_disk_wal_fsync_duration_seconds` / `workqueue_depth`	优化 etcd 磁盘；增加 controller-manager 并发数
控制平面间歇性不可用	etcd（Leader 选举）	`etcd_server_leader_changes_seen_total`	检查磁盘延迟；增加 `election-timeout`
API 响应超时	kube-apiserver（过载）	`apiserver_current_inflight_requests`	启用 APF；增加 `max-requests-inflight`

  核心结论： 在误差预算台账体系中，etcd 的磁盘延迟是“第一性原理”级别的指标。只要 etcd_disk_wal_fsync_duration_seconds 的 P99 超过 10ms，无论其他组件如何调优，控制平面的 SLO 都无法保障。建议将 etcd 磁盘延迟作为集群健康度的“红线指标”，纳入误差预算台账的自动告警规则。