在实际工作中，优化 Kubernetes 的性能和成本通常需要结合资源利用率分析、集群配置调整以及自动化工具的整合。以下是我在项目中实践过的一些典型优化场景和解决方案：
一、资源利用率优化
1. 合理配置 Requests/Limits
-
问题：许多团队未准确设置 Pod 的
requests和limits，导致资源浪费或频繁 OOM。 -
优化方法：
-
使用 Prometheus + Grafana 监控 Pod 的实际 CPU/内存使用量。
-
根据历史数据动态调整
requests（如设置为平均使用量的 120%），limits设置为峰值使用量的 1.5 倍。 -
工具支持：
-
Vertical Pod Autoscaler (VPA)：自动调整 Pod 的
requests和limits（注意 VPA 需避免与 HPA 冲突）。 -
kubectl top pods/node：快速查看资源消耗。
-
-
2. 节点资源碎片整理
-
问题：节点资源碎片化导致无法调度大资源需求的 Pod，被迫扩容新节点。
-
优化方法：
-
使用 Descheduler 驱逐低优先级 Pod，重新平衡节点负载。
-
配置 Pod 亲和性/反亲和性，避免同类 Pod 集中到同一节点。
-
二、成本优化
1. 集群自动扩缩容 (Cluster Autoscaler)
-
场景：非生产环境的测试集群在夜间空闲时仍运行大量节点。
-
优化方法：
-
结合 Horizontal Pod Autoscaler (HPA) 和 Cluster Autoscaler，根据负载动态调整节点数量。
-
使用 时间调度（如 CronJob）在非高峰时段缩减副本数。
-
云厂商功能：AWS 的 Spot 实例、GCP 的 Preemptible VM 降低成本。
-
2. 存储成本控制
-
问题：未清理的 PV/PVC 和快照长期占用存储资源。
-
优化方法：
-
定期清理未使用的存储卷（如通过
TTL控制器自动删除）。 -
根据业务需求选择存储类型（如冷数据使用低性能存储）。
-
使用 Rook/Ceph 自建存储集群替代云厂商存储（适合大规模集群）。
-
三、性能优化
1. API Server 优化
-
问题：频繁的 List 请求导致 API Server 高负载。
-
优化方法：
-
客户端配置 分页查询（如
kubectl --chunk-size=500）。 -
使用 Watch 替代轮询 List。
-
启用 APIServer 的审计日志过滤，减少不必要的日志写入。
-
2. etcd 性能调优
-
问题：大规模集群下 etcd 延迟升高。
-
优化方法：
-
分离 etcd 与 Master 节点，使用 SSD 磁盘并独占 CPU。
-
定期压缩历史版本（
etcdctl compact）和碎片整理（etcdctl defrag）。 -
限制 kube-apiserver 的
--max-requests-inflight和--max-mutating-requests-inflight。
-
3. 网络优化
-
问题：CNI 插件（如 Flannel）的默认 MTU 导致跨云网络性能差。
-
优化方法：
-
根据网络环境调整 CNI 的 MTU（如 AWS VPC 中 MTU 设为 9001）。
-
使用 Cilium 替代传统 CNI，支持 eBPF 加速和更灵活的网络策略。
-
四、运维效率提升
1. 镜像优化
-
场景：镜像体积过大导致 Pod 启动缓慢。
-
优化方法：
-
使用 多阶段构建 剥离编译环境和运行环境。
-
选择轻量级基础镜像（如 Alpine、Distroless）。
-
预热镜像（如 Kraken 或 Dragonfly 加速镜像分发）。
-
2. 日志与监控优化
-
问题：日志和指标数据占用大量存储。
-
优化方法：
-
使用 Loki 替代 Elasticsearch，低成本存储日志。
-
调整 Prometheus 的抓取间隔和存储保留时间。
-
五、实际案例效果
-
案例 1：通过调整
requests/limits和启用 VPA，某生产集群的 CPU 利用率从 30% 提升至 65%，节点数量减少 40%。 -
案例 2：使用 Cluster Autoscaler + Spot 实例后，测试环境的月度成本降低 70%。
-
案例 3：优化 etcd 配置后，API 请求延迟从 1.2s 下降至 200ms。
六、工具推荐
-
成本分析：Kubecost、OpenCost
-
资源监控：Prometheus + Grafana、Datadog
-
自动化调优：Goldilocks（VPA 辅助工具）、Keda（事件驱动的自动扩缩）
关键原则
-
监控先行：没有数据支撑的优化是盲目的。
-
渐进式调整：避免一次性大规模变更导致稳定性问题。
-
平衡性能与成本：过度优化可能增加运维复杂度。
通过以上方法，可以显著提升 Kubernetes 集群的资源利用率，降低成本，同时保障业务稳定性。实际优化时需结合业务特点和基础设施环境灵活调整。
