K8s成本管控：40%浪费源自这些冗余配置
当我不再把 Kubernetes 看作一个可以自动伸缩的神奇黑盒子时，才开始发现那些你完全能想象到的浪费无处不在：闲置的工作负载、过大的 Pod、海量的日志记录，以及实际上从未真正扩展的自动扩缩器。
我曾经以为我们不断上涨的 Kubernetes 账单只是云端开展业务的必要成本。
每个月，它都在攀升，每个月，都有人说：“Kubernetes 就是这么烧钱的。”
但事实并非如此。
问题不在于 Kubernetes，而在于我们使用它的方式。
当我不再把 Kubernetes 看作一个可以自动伸缩的神奇黑盒子时，我开始发现那些你完全能想象到的浪费无处不在：闲置的工作负载、过大的 Pod、海量的日志记录，以及实际上从未真正扩展的自动扩缩器。
经过几周的清理和调整，我们的账单下降了 40%。
我们没有更换供应商，也没有获得任何秘密折扣，只是更好地利用了现有资源。
真正的问题在于：我们过度设计了一切
我们的设置就是一个典型的“YAML 越多，问题越多”的例子。
数十个用于几乎没有流量的小型服务的命名空间。自动扩缩功能虽已开启，但 CPU 请求量过大，导致自动扩缩功能从未触发。定时任务每小时运行一次，而这些任务原本每天只运行一次。Fluentd 流水线正在向高级存储发送数 GB 的调试日志。
我们把 Kubernetes 搞得很贵，因为我们不相信它简单易用。
第一步：修正您的资源请求
大多数团队要么让资源“饿着肚子”，要么让它们“吃得过饱”。这两种我们都试过。
我们使用 Prometheus 指标和垂直 Pod 自动扩缩器 (VPA) 的推荐模式，对比了实际使用量与声明的限制。
结果发现，大约 70% 的 Pod 请求的 CPU 和内存资源是实际使用量的 2-3 倍。
我们将这些限制降低到了合理的数值。一夜之间，集群自动缩容减少了几个节点。
节省了大约 15%，而且系统运行依然正常。
步骤二：清除幽灵工作负载
接下来，我们查找了那些无人记得创建的工作负载。
使用以下命令快速查询：
kubectl get pods --all-namespaces --sort- by =.metadata.creationTimestamp
……结果揭露出了整个测试集群、旧的批处理作业以及那些早在数月前便不再需要却仍在运行的 PR 预览应用程序。
我们删除了它们，并在自动过期预览环境中添加了 TTL 控制器。
结果：账单又节省了 10%，彻底消除了浪费。
步骤三：使用较小的节点，而不是较大的节点
我们原本以为运行大型节点（32 个 vCPU 以上）可以降低管理开销。
但 Kubernetes 并不擅长将工作负载完美地打包到大型节点中。
半个节点会闲置，白白浪费成本。
我们切换到了更小的实例类型（例如，m6i.large 而不是 m6i.4xlarge），并让自动扩缩程序处理实例容量的调整。
通过混合使用较小的节点，资源利用率大幅提升，并且我们节省了 8% 的成本。
步骤四：让自动扩缩真正发挥作用
启用水平 Pod 自动扩缩 (HPA) 并不意味着它正在执行任何操作。
我们的 CPU 阈值设置得非常高，所以从未触发过。
我们重新调整了自动扩缩目标，使用第 90 百分位使用指标而不是猜测，并根据以下因素进行缩放：自定义指标（例如通过 Prometheus Adapter 请求率）。
结果：在低流量时段，Pod 缩减规模，节点也随之缩减，集群最终恢复了应有的运行状态。
节省：多 5-7%。
步骤五：日志、存储和数据节制
这是最难的一步。
我们在 EBS 卷和存储日志上的花费远远超过了实际计算资源上的花费。
我们发现审计日志、调试跟踪和系统日志都存储在高级块存储中。
然后，我们将这些日志移至 S3 Glacier 进行冷数据存储，将非关键日志的日志保留期从 1 年缩短至 7 天，并完全停止在生产环境中生成调试日志。
节省：约 6%。
残酷的真相
Kubernetes 本身成本不高，成本主要来自运行不善的 Kubernetes 服务。
我们很容易把问题归咎于云费用，而实际上问题出在我们自己以及我们如何利用资源上。
清理之后，我们的集群更小、更快、更易维护，最终成本也达到了它应有的水平。
我现在每周检查一次资源使用情况，积极减少资源占用，并质疑每个新的工作负载是否必须始终运行。
如果您觉得 Kubernetes 的成本难以控制，请不要放弃该平台。
检查您的请求，减少噪音，调整节点大小，并停止记录每一次心跳。
您可能会发现，您账单的 40% 都是自己造成的。
作者｜Mohab 编译｜Rio
来源｜网址：https://aws.plainenglish.io/how-we-cut-our-kubernetes-costs-by-40-without-moving-to-another-platform-25304feb6494
相关攻略
别再把问题归咎于框架，很多坑其实早就写在基础里 做Ja va开发这些年，一个反复出现的场景总让人印象深刻： 系统上线后突然变慢、某个接口时好时坏、对象状态莫名其妙“丢了”、或者从Map里死活取不出值来…… 遇到这种事，第一反应往往是去翻框架文档：是不是Spring Boot配置不对？是不是微服务调用
刚接触K8S环境运维时，经常会遇到pod状态崩溃的情况 相信不少运维工程师都经历过这样的场景：服务容器启动后立即退出，Kubernetes 不断重启，Pod 陷入 CrashLoopBackOff 的死循环。更让人头疼的是，你急着想查看镜像里的配置文件、启动脚本或者日志目录，却发现根本进不去 Pod
今天我们彻底讲清楚：subPath 是什么、怎么工作、什么时候该用、又有哪些坑要避开 处理 Kubernetes 配置时，有没有碰到过这些让人头疼的状况：只想把一个 ConfigMap 里的某个配置文件挂进容器，结果整个目录都被覆盖了；几个服务共享一个 PVC，数据却混作一团，互相干扰；明明更新了
一次性将Kubernetes集群证书续期100年？先别急，小心这个“隐藏”的坑 相信不少运维同学都遇到过这样的头疼事：Kubernetes集群运行得好好的，突然某天就“失联”了。一查日志，证书过期。这事儿还真不是小概率事件，因为K8s默认颁发的组件证书有效期只有一年。一旦几个关键证书（比如apise
当Kubernetes不再是基础设施，而是变成了产品本身 从理论上看，Kubernetes不过是个编排工具。但现实往往不会按照剧本走——它悄无声息地，就成了工作的主角。 回想一下，团队最初的想法总是美好的： “我们需要标准化部署流程。”“要实现合理的自动扩缩容。”“这样能降低运维负担。” 结果呢？六
热门专题
热门推荐
英国工党领袖斯塔默面临公众信任挑战，支持率低迷。类似困境在欧洲多国领导人中普遍存在，德国总理默茨与法国总统马克龙的支持率同样远低于不支持率，反映出欧洲政界广泛的信任危机。
芝麻开门：安全便捷的数字资产交易平台 在数字货币的世界里，选择一个可靠、便捷的交易入口是第一步。芝麻开门作为一款服务于全球用户的知名交易平台，以其多重安全防护、对主流币种的广泛支持以及现货、杠杆等丰富功能，成为了许多交易者的选择。今天，我们就来详细梳理一下如何通过官方渠道，安全地获取并使用芝麻开门平
全球债市因通胀担忧遭剧烈抛售，长期美债收益率升至近三年高位。30年期美债收益率一度突破5%，10年期与2年期收益率同步攀升。日本30年期国债收益率单日飙升20基点创新高。油价上涨加剧通胀忧虑，策略师建议关注美债收益率在5 25%-5 5%区间的后续动向。
欧易（OKX）：您的官方数字资产交易入口 在加密货币的世界里，选择一个可靠、功能全面的交易平台是第一步。欧易（OKX）作为全球领先的数字资产服务商，早已成为数百万用户的首选。它不仅提供比特币、以太坊等主流币种的现货交易，更将业务延伸至衍生品、DeFi以及NFT市场，构建了一个完整的加密生态。其背后，
gate io交易APP官方版 v7 19 1 安卓版下载与安装全指南 对于数字资产交易者来说，一个可靠、顺手的交易工具至关重要。Gate io交易APP，正是这样一款专业的平台，它为全球用户提供比特币、以太坊乃至上千种加密货币的实时行情与交易服务。其最新的安卓v7 19 1版本，在用户体验和系统稳