在实际工作中，优化 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 集群的资源利用率，降低成本，同时保障业务稳定性。实际优化时需结合业务特点和基础设施环境灵活调整。