云，哪里贵了？

问题的根源就在于我们有没有告诉Kubernetes该如何扩展新节点。

N1 预定义实例Core/RAM方面，当前使用的是n1-standard-8节点，它们根据使用情况自动缩放。在进行修正之前，了解 Kubernetes 如何扩展新节点非常有必要。

当定义 Pod 时，需要告诉 Kubernetes 一个信息：Pod 需要多少 RAM 和 CPU 才能正常工作；这就是 Kubernetes 所说的 Request。

假设我的 API 的 pod A 需要 400mo RAM 和 0.2 vCPU 才能正常工作，而 Kubernetes 节点容量为 30 GB RAM 和 8 个 vCPU。可以在该节点中容纳 40 个 Pod，因为 8 个 vCPU 除以 0.2 vCPU 等于 40 个 Pod，而 30,000mo 除以 400mo 等于 75 个 Pod。

所以，于K8s集群而言，明确预期的和未使用的资源，是一个技术活儿。

表示请求的 CPU 与节点实际容量的架构

通过这几项更改，搞定了 N1 预定义实例Core/RAM的成本问题，从4,235.43 欧元增加到 1,973.28 欧元。

问题4：区域间网络出口的数据交互费用

这方面是非常棘手的，可用区域之间的网络的数据交互会产生很大的云费用

我们有四十多个微服务，但好处是它们做得很好，而且它们之间几乎没有直接通信，但我们在所有这些服务前面有一个GraphQL 网关。这个网关接到很多调用。

笔者也采取了两种方式解决了这个问题： 

第一个是使用 Flow Logs追踪哪些调用对于返回的数据最大。

第二种方法，也是我们最有信心的方法，是检查哪个 API 收到的调用最多，以及该 API 中的哪个端点非常适合缓存。我们已经使用 Redis 作为发布/订阅解决方案，因此我们也可以轻松地将它用作缓存。

我们决定先做缓存，因为我们无论如何都需要它，而且一切都已经设置好了。但这仍然是一个错误——因为我们只是将问题转移到缓存系统中，而不知道数据是否太大是因为代码问题还是因为调用次数过多。

使用Kiali，我们可以看到哪个 API 收到的调用最多。

根据此信息和应用程序的功能方面，我们决定应缓存哪个端点。这样，GraphQL 网关将实现缓存，并且不必对服务进行 HTTP 调用来获取数据，从而降低了 Egress 成本。

仅通过实施第一个解决方案，我们就成功地将出口成本从 2.712,34 欧元降低到 1,095.19 欧元。

遗憾的是，我们尚未实现第二种解决方案来追踪传输大量数据的剩余 HTTP 调用。

云存储哪里贵了？

没错，云存储的成本，大部分还是与容量本身有关，而并非存储桶中传输的数据产生的成本。解决的方法自然就很简单：删。

临时环境的成本也很惊人

进一步削减云成本的思路

（1）微调 Kubernetes 请求，以更加精确地了解我们的微服务需要运行的内容；

（2）按照我们最初的计划追踪剩余的出口成本

（3）继续在我们的归档 cron 中实施新规则，从存储桶中删除不必要的文件；

（4）将我们的视频处理从 CPU 切换到 GPU（笔者实测速度更快且成本更低）；

（5）清理生产中的 SQL 数据库，存储可存档的 TB 级事件数据。

写在最后

C++“中年危机”有救了！C++之父新动作！

Instagram 仅 3 名工程师，如何做到 1400 万用户？

ChatGPT企业版，基本凉了！