《使用 Kubernetes 实现云原生 DevOps（第二版）》

第 5 章 资源管理 资源管理

本作品已使用人工智能进行翻译。欢迎您提供反馈和意见：[e-mail]

对一个人来说，没有什么是足够的，因为对他来说，足够的东西太少了。

伊壁鸠鲁

在本章中，我们将探讨如何充分利用集群：如何管理和优化资源使用，如何管理容器的生命周期，以及如何使用命名空间对集群进行分区。我们还将概述一些技术和最佳实践，以降低集群成本，实现物有所值。

您将了解如何使用资源请求、限制和默认值，以及如何使用 Vertical Pod Autoscaler 对其进行优化；如何使用就绪探针、有效性探针和 Pod 中断预算来管理容器；如何优化云存储；以及如何和何时使用可抢占式或保留实例来控制成本。

了解资源

假设你有一个 Kubernetes 集群，容量一定，节点数量合理，大小合适。如何才能物尽其用？也就是说，如何在确保有足够的余量应对需求高峰、节点故障和糟糕部署的同时，尽可能充分利用可用集群资源来满足工作负载的需求？

要回答这个问题，请把自己放在 Kubernetes 调度器的位置上，试着从它的角度看问题。调度器的工作是决定在哪里运行某个 Pod。是否有节点有足够的空闲资源来运行 Pod？

除非调度程序知道 Pod 运行需要多少资源，否则无法回答这个问题。需要 1 GiB 内存的 Pod 无法调度到只有 100 MiB 可用内存的节点上。

同样，当一个贪婪的 Pod 占用了太多资源，导致同一节点上的其他 Pod 陷入饥饿时，调度程序必须能够采取行动。但多少才算多？为了有效地调度 Pod，调度程序必须知道每个 Pod 的最小和最大允许资源需求。

这就是 Kubernetes 资源请求和限制的作用所在。Kubernetes 知道如何管理两种资源：CPU 和内存。还有其他一些重要的资源类型，比如网络带宽、磁盘 I/O 操作数（IOPS）和磁盘空间，这些资源可能会在集群中造成争用，但 Kubernetes 还没有办法描述 Pod 对这些资源的要求。

资源单位

如您所料，Pod 的 CPU 使用量是以 CPU 为单位表示的。一个 Kubernetes CPU 单位相当于一个 AWS 虚拟 CPU（vCPU）、一个 Google Cloud Core、一个 Azure vCore 或支持超线程的裸机处理器上的一个超线程。换句话说，1 CPU在 Kubernetes 术语中的含义就是你所想的那样。

由于大多数 Pod 不需要整个 CPU，因此请求和限制通常以毫微微（millicpus）为单位（有时也称为毫核）。内存以字节为单位，更方便的说法是兆字节（MIB）。

资源申请

Kubernetes资源请求指定了 Pod 运行所需的最低资源量。例如，资源请求为100m （100 毫pus）和250Mi （250 MiB 内存），这意味着 Pod 不能在可用资源少于这些资源的节点上调度。如果没有足够容量的节点可用，Pod 将保持pending 状态，直到有足够容量为止。

例如，如果所有集群节点都有两个 CPU 内核和 4GB 内存，那么请求 2.5 个 CPU 的容器将永远不会被调度，请求 5GB 内存的容器也不会被调度。

让我们来看看我们的演示程序中的资源请求是什么样的：

spec:
  containers:
  - name: demo
    image: cloudnatived/demo:hello
    ports:
    - containerPort: 8888
    resources:
      requests: