Kubernetes怎么容量规划？看完就会设计

▌ 技术引导
Kubernetes 的容量规划不是随便填个数字就行，这玩意儿会吃掉你所有想象力。我见过太多人为了省事，直接把节点数翻倍，结果系统崩溃、资源浪费、成本飙升。真正靠谱的容量规划得从节点资源、Pod 拓扑、存储需求、网络带宽、调度策略这些方面下手。知道你得算 CPU、内存、存储这些基础指标，但更关键的是知道怎么算。比如，用 kubectl describe node 查看每个节点的使用率，用 metrics-server 获取实时资源使用数据。别光看 CPU 和内存，得关注存储 IOPS 和延迟。还有调度器的策略，别瞎用，默认的默认啥玩意儿，要根据业务特点手工设置。我还在几个真实场景中用过 Prometheus + Grafana 跟踪资源趋势，这玩意儿能让你提前看到问题。别忘了，autoscaling 也不能全靠它，得多维度评估。

▌ 技术参考
Kubernetes 容量规划的核心在于资源分配与节点管理。每台节点的 CPU 和内存上限是硬性约束，不能随意超配。使用 kubectl describe node 命令可以看到每个节点的资源使用情况，包括 Allocatable、Capacity、Used 等参数。这些参数能直接告诉你当前节点还有多少资源可用，不要被系统默认分配搞蒙。在实际操作中，我习惯用 metrics-server 搭配 kubelet 获取更准确的资源使用数据，尤其是运行时的 CPU 和内存使用曲线。

配置资源请求和限制是关键。每个 Pod 中的容器必须声明 resources.requests 和 resources.limits，比如：
```yaml
resources:
requests:
memory: "512Mi"
cpu: "500m"
limits:
memory: "1Gi"
cpu: "1"
```
这种做法能避免资源争抢，也能让调度器更精准地分配节点。我见过太多人没设置资源限制，结果一个 Pod 占了全部内存，整个节点挂掉。

▌ 技术参考
节点数量不是越多越好。每个节点都有调度开销，同时过多节点也会增加网络延迟。我通常会根据业务负载的峰值和平均值，结合资源利用率来确定节点数。比如，假设平均 CPU 使用率是 30%，峰值是 60%，那么节点数应该覆盖峰值需求的 1.5 倍。这个比例不是死数，得根据具体工作负载调整。

Pod 拓扑也会影响容量。如果一个业务有高亲和性，比如必须部署在同一节点，那么资源利用率会比无亲和性的业务高。我之前遇到一个电商系统，每个订单处理服务都必须绑定同一个数据库节点，结果数据库节点资源被撑爆，不得不手动拆分服务。所以，在设计时，得评估业务之间的相互依赖关系，别盲目设置 Affinity。

▌ 技术参考
存储容量规划往往被忽视，但同样重要。每个 Pod 如果挂载了 PVC，得知道存储的 IOPS 和带宽需求。比如，日志服务如果写入频繁，可能需要高性能的 SSD 存储，而数据库可能需要持久化存储策略。使用 kubectl describe persistentvolume 命令能查看现有 PVC 的使用情况，同时结合 Prometheus 的 csi-nodeplugin 指标监控存储性能。

我通常会用 Prometheus + Grafana 来监控资源使用趋势。这样能提前发现资源瓶颈，比如 CPU 使用率在某个时间段突然上升，说明有潜在的性能问题。监控指标包括 node_memory_usage、node_cpu_usage、node_disk_used 等，定期导出这些数据做趋势分析。

▌ 技术参考
调度器的策略对容量规划有很大影响。默认的调度策略是尽量均匀分布 Pod，但有时候你得强制某些服务部署在特定节点上。比如，用 nodeSelector 把高负载服务绑定到性能更强的节点上。配置示例如下：
```yaml
spec:
nodeSelector:
type: "high-performance"
```
同时，也可以用 Taint 禁止某些服务运行在特定节点，比如：
```yaml
spec:
tolerations:
- key: "high-performance"
operator: "Equal"
value: "true"
effect: "NoSchedule"
```
这种方式能避免资源浪费，也能保障关键服务的稳定性。

▌ 技术参考
Pod 的资源请求和限制需要合理设置。比如，一个后端服务可能需要 1Gi 内存，但不能设置过高的限制，否则容易导致调度失败。我见过有人把 limits 设置成 10Gi，结果整个节点资源被占满，其他服务无法运行。

配置资源请求和限制时，可以使用 Kubernetes 的 HPA（Horizontal Pod Autoscaler）来动态调整副本数。比如：
```yaml
apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
name: my-app-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: my-app
minReplicas: 2
maxReplicas: 10
metrics:
- type: Resource
resource:
name: memory
target:
type: Utilization
averageUtilization: 70
```
这种方式能根据负载自动扩容，但得注意触发阈值的设置，避免频繁扩缩容。

▌ 技术参考
容器的资源请求和限制要结合业务实际。比如，一个数据库容器可能需要更多的内存，但它的 CPU 需求通常不高。我见过有人把数据库 Pod 的 CPU 限制设成 2，结果在高峰期让整个集群无法调度其他服务。所以，要根据业务模式调整这些参数。

此外，资源请求和限制还会影响调度器的分配策略。如果一个 Pod 请求了太多资源，调度器可能会拒绝它，导致服务无法启动。在生产环境中，尽量让资源请求和限制的数值接近实际运行情况，避免资源争抢和资源浪费。

▌ 技术参考
节点资源的分配需要考虑余量。比如，如果一个节点的 CPU 总共有 8 核，但你分配了 7 个 Pod，每个占用 1 核，那么还要留出 1 核应急。我习惯按 20% 的余量配置，这样即使有突发流量也能扛住。

另外，节点的内存分配也要留出缓冲。比如，一个节点有 16Gi 内存，但实际分配的内存不能超过 12Gi，这样就能应对内存泄露、临时缓存等突发情况。内存的余量比 CPU 更重要，因为内存不足会导致服务崩溃。

▌ 技术参考
Kubernetes 的调度器默认不会考虑存储性能，这很容易踩坑。比如，某个业务 Pod 需要高性能存储，但被调度到普通节点，导致服务响应变慢。我之前就用过 node-affinity 和 node-selector 两个机制，让需要高性能存储的 Pod 只能部署在特定节点上。

另外，可以通过 kube-scheduler 的配置文件来调整调度策略。比如，设置 nodeResourcesBalancedAllocation 参数，让调度器尽量平衡资源分配。这个参数在 kube-scheduler 的 config.yaml 文件中配置，能有效避免资源浪费。

▌ 技术参考
多租户场景下，容量规划要更谨慎。每个租户的服务资源不能交叉影响。我之前用过 Kubernetes 的 resourceQuota 来限制每个命名空间的资源使用。比如：
```yaml
kind: ResourceQuota
apiVersion: v1
metadata:
name: my-quota
spec:
hard:
pods: "10"
requests.memory: "10Gi"
requests.cpu: "10"
```
这种方式能防止某个租户占用过多资源，影响其他业务。

但 resourceQuota 也有局限性，比如不能限制单个 Pod 的资源使用。这时候可以结合 LimitRange 来做更细粒度的控制。比如：
```yaml
kind: LimitRange
apiVersion: v1
metadata:
name: my-limitrange
spec:
limits:
- type: Container
maxMemory: 2Gi
minMemory: 1Gi
```
这种方式能确保每个 Pod 的资源请求和限制在合理范围内。

▌ 技术参考
在实际部署中，我还会用 scale-down 策略来优化资源。比如，设置 HPA 的 minReplicas 为 2，maxReplicas 为 10，同时设置 scaleDown 策略，让 Kubernetes 能在空闲时自动缩减节点。比如：
```yaml
spec:
scaleDown:
enabled: true
anticipatedScaleDownDelaySeconds: 60
```
这种方式能节省资源，但要注意延迟问题，避免服务中断。

另外，还可以使用 kubelet 的 --max-pods 参数来限制每个节点可以运行的 Pod 数量。比如：
```bash
--max-pods=100
```
这个参数能防止节点过载，同时也能影响调度器的决策。我之前因为没设置这个参数，导致一个节点被数十个 Pod 塞满，结果整个集群因调度失败宕机。

▌ 技术参考
监控工具对容量规划至关重要。我通常会用 Prometheus + Grafana 可视化资源使用情况，同时用 alertmanager 设置预警规则。比如，当 CPU 使用率超过 80%，或者内存使用率超过 90%，就触发警报。

监控资源趋势时，可以使用 kubectl top node 和 kubectl top pod 命令快速查看当前的资源使用情况。同时，也可以用 cAdvisor 来获取容器级别的资源使用数据。这些工具能帮你更准确地评估实际资源消耗。

▌ 技术参考
容量规划要结合业务峰值和平均负载。比如，一个用户系统可能在促销时流量暴增，这时候得预留足够的资源。我之前在设计电商系统时，先用压测工具模拟高峰流量，再根据实际资源需求调整节点数量和资源配置。

此外，还要考虑不同业务的优先级。比如，数据库和关键业务服务应该优先分配资源，而不是普通的服务。这可以通过 Pod 的 priorityClass 来实现。比如：
```yaml
spec:
priorityClassName: "high-priority"
```
然后在 kube-scheduler 中设置优先级调度策略，确保关键服务始终有资源可用。

▌ 技术参考
在某些场景下，动态扩容比静态规划更灵活。我用过 Kubernetes 的 HorizontalPodAutoscaler 来根据负载自动扩展副本数，但发现这种方式在高并发场景下容易出现资源争抢。所以，我会结合 Cluster Autoscaler 来调整节点数量。比如，设置一个负载阈值，当节点资源不足时自动扩容。

Cluster Autoscaler 的配置文件中，可以调整 maxNodes 和 minNodes 参数，比如：
```yaml
apiVersion: autoscaling.k8s.io/v1beta1
kind: ClusterAutoscaler
metadata:
name: my-cluster-autoscaler
spec:
maxNodes: 20
minNodes: 5
```
这种方式能动态调整集群规模，但也需要你有充足的基础资源来支撑。

▌ 技术参考
资源隔离也是容量规划的一部分。比如，使用命名空间来划分资源。每个 namespace 都可以设置资源配额，这样能避免资源争抢。

监控资源隔离时，可以用 kubectl get namespace 和 kubectl describe namespace 命令查看每个命名空间的资源使用情况。同时，也可以在 kube-scheduler 中设置 namespace 的调度策略，让某些高负载的业务优先使用特定节点。

▌ 技术参考
最后，别忘了资源的回收问题。当一个 Pod 被删除时，它的资源会立即释放，但有些服务可能需要一定时间才能释放资源。这时候，可以通过设置 eviction 策略来优化资源回收。比如，在 Pod 的 spec 中设置：
```yaml
spec:
evictionSoftGracePeriodSeconds: 300
```
这种方式能防止资源浪费，同时也能保证服务的稳定性。

在真实环境中，我还会用 kubelet 的 --eviction-hard 参数来设置硬性驱逐规则，比如：
```bash
--eviction-hard=memory.available<100Mi,nodefs.available<10%,nodefs.inodesFree<5%
```
这样能及时释放资源，避免节点过载。