16.9.1 生产级集群规划与容量评估

本节围绕生产级 Kubernetes 集群在实际落地中的规划与容量评估方法展开，目标是在满足业务增长、性能与成本之间取得平衡。通过业务负载模型、SLO/SLA、峰值流量、资源消耗与冗余策略的系统化分析，形成可执行的集群规模规划与持续容量管理策略，避免“过度配置”与“资源不足”的双重风险。

生产级规划需要覆盖控制面与数据面，并将网络、存储、监控、自动扩缩容纳入整体评估。以下为简化的规划链路原理草图：

文章图片

1) 容量评估计算模型与示例#

容量评估应基于“资源请求总量 / 节点可用资源 × 利用率”的模型，同时考虑 kube-reserved、system-reserved、DaemonSet 常驻资源。以下示例使用 Prometheus 指标估算 95 分位内存与 CPU。

# 前置：已安装 kube-prometheus-stack
# 统计最近 7 天中，命名空间 prod 的 CPU/内存请求总量
# 1) CPU requests (核数)
promql_cpu='sum(kube_pod_container_resource_requests{namespace="prod",resource="cpu"})'
# 2) Memory requests (字节)
promql_mem='sum(kube_pod_container_resource_requests{namespace="prod",resource="memory"})'

# 通过 curl 查询（假设 Prometheus 地址为 http://prometheus.monitoring:9090）
curl -G http://prometheus.monitoring:9090/api/v1/query \
  --data-urlencode "query=$promql_cpu"

curl -G http://prometheus.monitoring:9090/api/v1/query \
  --data-urlencode "query=$promql_mem"

容量估算示例（假设数据面节点规格：32vCPU/128GiB，预留 2vCPU/4GiB，DaemonSet 预留 1vCPU/2GiB，目标利用率 70%）：

节点可用 CPU = 32 - 2 - 1 = 29 vCPU
节点可用 Mem = 128 - 4 - 2 = 122 GiB
有效可用 CPU = 29 * 0.7 = 20.3 vCPU
有效可用 Mem = 122 * 0.7 = 85.4 GiB

集群需求：
CPU requests 总量 = 406 vCPU
Mem requests 总量 = 1620 GiB

所需节点数（取大值）：
CPU 维度：406 / 20.3 = 20.0 -> 20
Mem 维度：1620 / 85.4 = 19.0 -> 19
最终节点数 = 20（再加冗余）

2) 控制面与数据面规划示例#

生产级控制面至少 3 节点，部署在不同故障域；数据面按工作负载划分节点池。示例为三类节点池：

# 文件: /etc/kubernetes/cluster-pool-plan.yaml
controlPlane:
  count: 3
  instanceType: c4.large
  zones: ["az-a","az-b","az-c"]
dataPlanes:
  - name: general
    instanceType: c6.2xlarge
    count: 20
    labels: { "nodepool": "general" }
  - name: memory
    instanceType: r6.2xlarge
    count: 6
    labels: { "nodepool": "memory" }
  - name: storage
    instanceType: i3.2xlarge
    count: 4
    labels: { "nodepool": "storage" }

将应用绑定到节点池的调度示例：

# 文件: /srv/manifests/app-deploy.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-api
  namespace: prod
spec:
  replicas: 6
  selector:
    matchLabels:
      app: order-api
  template:
    metadata:
      labels:
        app: order-api
    spec:
      nodeSelector:
        nodepool: general
      containers:
      - name: order-api
        image: registry.example.com/order-api:v1.2.0
        resources:
          requests:
            cpu: "500m"
            memory: "512Mi"
          limits:
            cpu: "1000m"
            memory: "1024Mi"

3) 网络与存储容量规划示例#

网络容量评估应考虑 CNI、节点带宽、Ingress/LB 处理能力。存储评估要关注 IOPS 与吞吐。

网络容量检查示例：

# 查看节点网络带宽与丢包
ip -s link show eth0

# 简单带宽测试（示例：两节点间）
# NodeA:
iperf3 -s
# NodeB:
iperf3 -c <NodeA_IP> -t 30

存储性能评估示例（PVC 读写性能）：

# 创建测试 Pod
cat >/tmp/fio-pod.yaml <<'EOF'
apiVersion: v1
kind: Pod
metadata:
  name: fio-test
  namespace: prod
spec:
  containers:
  - name: fio
    image: ghcr.io/axboe/fio
    command: ["sleep","3600"]
    volumeMounts:
    - name: data
      mountPath: /data
  volumes:
  - name: data
    persistentVolumeClaim:
      claimName: prod-pvc
EOF
kubectl apply -f /tmp/fio-pod.yaml

# 运行 fio
kubectl exec -n prod fio-test -- fio --name=randrw \
  --directory=/data --rw=randrw --bs=4k --size=2G --numjobs=4 \
  --iodepth=16 --runtime=60 --time_based --group_reporting

4) 自动扩缩容与容量预警示例#

示例启用 HPA + Cluster Autoscaler（CA）组合，避免在高峰期资源不足。

# 文件: /srv/manifests/hpa.yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: order-api-hpa
  namespace: prod
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: order-api
  minReplicas: 6
  maxReplicas: 20
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 60

kubectl apply -f /srv/manifests/hpa.yaml
kubectl get hpa -n prod

CA 典型参数说明（以 kubeadm 方案为例）：

# 文件: /etc/kubernetes/addons/cluster-autoscaler.yaml
- --nodes=3:30:general-nodegroup
- --nodes=2:10:memory-nodegroup
- --balance-similar-node-groups=true
- --scale-down-delay-after-add=10m
- --scale-down-utilization-threshold=0.5

5) 安装与工具准备（容量评估常用组件）#

生产容量评估建议安装 Prometheus、Metrics Server、kubectl 插件（kubectl top）。

# 安装 Metrics Server（kubeadm 示例）
kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

# 安装 kube-prometheus-stack（Helm）
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update
helm install kps prometheus-community/kube-prometheus-stack -n monitoring --create-namespace

验证指标是否可用：

kubectl top nodes
kubectl top pods -A

6) 排错清单（容量规划常见问题）#

  • 问题 1：节点资源看似充足，但 Pod 无法调度
  • 检查资源请求是否过大、或存在反亲和/污点阻止调度。
kubectl describe pod <pod> -n prod
kubectl describe node <node>
  • 问题 2：HPA 不生效
  • 检查 Metrics Server 是否正常。
kubectl get apiservices | grep metrics
kubectl logs -n kube-system deploy/metrics-server
  • 问题 3：扩容后仍无资源
  • 检查 CA 节点组限制与云资源配额。
kubectl logs -n kube-system deploy/cluster-autoscaler | tail -n 100

7) 练习题#

  1. 统计当前 prod 命名空间 CPU/内存 requests，按 70% 利用率估算节点数量（给出计算过程）。
  2. 构建一个 memory 节点池并将某个 StatefulSet 绑定到该节点池。
  3. 使用 fio 对 PVC 进行 4k 随机读写压测，记录 IOPS 与延迟。
  4. 触发 HPA 扩容并观察 CA 是否拉起新节点，记录时间线。

通过以上方法与示例，可以形成可执行的生产级集群规划与容量评估流程，并在持续监控与迭代中优化性能与成本。