共计 3899 个字符，预计需要花费 10 分钟才能阅读完成。
作者：Kim Wuestkamp
翻译：Bach（才云）
校对：bot（才云）、星空下的文仔（才云）
在生产环境中应用 Kubernetes 之前，咱们应该理解 K8s 的资源管理，资源管理的外围就是 Kubernetes 调度器解决资源申请和限度。
K8sMeetup
Pod 资源
在 K8s 中，一个 Pod 能够蕴含一个或多个容器，这些容器通常由 Docker 运行。
Pod 能够看做是容器的外包装，这二者会在同一台机器或节点上运行。一般来说，总的 Pod 资源就等于容器资源的总和。
资源申请和限度
为每个容器制订资源申请和限度，例如：
申请是保障失去的资源，其余 Pod 不能够应用这些资源。限度是容许应用比申请更多的资源。如果容器达到规定的限度，会被 CPU 超售并驱赶出内存。
K8sMeetup
调度器
K8s 调度器负责确定 Pod 能够在哪个节点上运行，它通过查看各种配置（例如亲和度、taints、tolerations）来实现。这里咱们仅关注次要配置：闲置资源（free resources）。当调度器做出无关“闲置资源”的决定时，它会查看两个数据：Node Allocatable 和 Node Requests。
节点的 Allocatable 与容量
调度器会查看节点的 Allocatable，它是整个节点减去 Kubelet 的保留资源。
咱们能够这样查看 Allocatable 和容量：kubectl get node worker1 -oyaml。
重要的是，无论节点上运行多少个 Pod，这些数字都不会扭转。只有节点通过 kubelet 注册，它们就是固定不变的。
依据调度器开释资源
free = node allocatable — sum(all pod resource requests)这意味着调度器实际上不会间接查看节点或 Pod 的 CPU 和内存应用状况，而只会思考已申请的内容。
K8sMeetup
调度器启动
让咱们看一下调度器决策工作流程示例，其中有两个节点，它们在刚启动时为空。
蓝色 Pod1 有资源申请，在节点 1 上调度
绿色 Pod 在节点 2 上调度
紫色 Pod 在节点 1 上调度
调度器尝试调度节点 2 上的红色 Pod
然而没有更多可用资源，因而处于 Pending 状态
当初咱们再看一下下面的图像，其中 node1 有两个 Pod，node2 有一个 Pod 在运行。节点上显示的所有色彩均示意资源申请，但没有限度，因为调度器会疏忽它们。当初我能够进一步了解低利用率（slack）和适度应用（overcommitment）。
K8s 中的低利用率（slack）和适度应用（overcommitment）
下图显示了示例指标，以可视化低利用率和适度应用。
上面咱们将更具体地探讨此示例指标和其余指标，但首先，咱们要更加深入研究低利用率和适度应用以彻底理解这些内容。
低利用率（slack）
节约的资源成为了低利用率。K8s 中的低利用率指申请了但未应用的资源。咱们先看上面的例子：
在这里，咱们看到 node1 上调度了两个 Pod。蓝色的所有内容均显示对 Pod1 的资源申请，然而 Pod1 实际上只应用了它所申请内容的 1/3，这意味着其余部分闲置了。呈现这种状况是因为 K8s 调度器不查看理论的应用状况，它仅查看指定的申请值。
适度应用 （overcommitment）**
适度应用意味着，如果所有节点都开始应用资源，节点上会安顿更多的 Pod。但只有不是所有的 Pod 同时在耗费所有的可用资源，它就能够起作用。让咱们看一个例子：
在这里，咱们看到蓝色 Pod 的 CPU 使用率实际上曾经超出了申请，这意味着它应用了适度应用的资源。这可能是因为咱们指定的限度高于要求。
然而 K8s 调度程序只会查看申请，还会认为依然有足够的可用资源，并可能在该节点上调度新的 Pod。
CPU 适度应用
只有适度应用不超过节点的容量，CPU 适度应用就不会有问题。让咱们来看看这种状况：
理论使用量超出容量，导致 CPU 超售
在这种状况下，节点上的两个 Pod 都将被驱赶，每个 Pod 都能够调回其申请的值。CPU 适度应用个别不会造成太重大的结果，因为它只会导致。
然而即便在这种状况下，k8s 调度器仍可能认为 node1 有足够的“闲暇 CPU”可用于另一个 Pod，因为 K8s 调度器只会查看申请。
内存适度应用
内存会有点不同，因为它无奈像 CPU 一样被限度。它不是基于工夫的值，它蕴含了无奈放大或扩大的理论数据。
理论使用量超出容量，导致 Pod 被驱赶、杀死或 OOM 异样
Kubelet 是在 VM 上运行并通过与 K8s API 通信将其注册为节点的过程。之后，它会从 API 接管 Pod 标准以运行。
Kubelet 具备一些解决 OOM 状况的机制，如上图所示。它能够留神到 Pod 是否开始应用超出要求的内存，是否很快用完，这样它能够依据优先级驱赶 Pod。
然而，咱们无奈保障 kubelet 有足够的工夫留神到这一点并驱赶 Pod。节点自身可能就会遇到内存不足的问题，操作系统自身还会开始杀死随机过程（源）。
这就是不容许内存适度应用的起因，所以最好始终设置 requests=limits。
基于优先级的 Kubelet Pod 驱赶
Kubelet 思考了 QoS（服务质量）和优先级，来决定驱赶哪些 Pod 以开释资源。
同时思考 QoS 和 Pod 优先级的惟一组件是 kubelet out-of-resource eviction。kubelet 首先判断 Pod 的资源使用量是否超过申请，而后通过优先级，计算 Pod 调度申请耗费的计算资源，最初将 Pod 逐出。
K8sMeetup
CPU 限度导致不必要的 CPU 超售
如果咱们为 Pod 设置了任何 CPU 限度，那么即便使用量不靠近限度，它也会受到限制。就算 Pod 的使用量为 200 millicpu，限度为 1000 millicpu，它仍可能会受到限制并导致提早或性能问题。
因而，倡议不定义 CPU 限度或通过禁用 kubelet 中的 CPU 限度 –cpu-cfs-quota=false。
那么如何避免 Pod 应用过多的 CPU？
- 监督 Pod 的应用状况，如果使用量超出申请，就创立警报。
- 通过 HPA/VPA 实现扩大。
K8sMeetup
设置适当的申请和限度
让咱们看一些场景，并探讨它们的优劣。这里只是一般性察看，对于特定用例可能有所不同。
场景 1
咱们有低利用率并容许适度应用，这不好。
场景 2
咱们没有低利用率，但应用了适度应用的资源，这也不是很好。
比拟靠近最佳计划
咱们为资源设置了 requests=limits。对于 CPU，咱们能够在 Kubelets 中禁用限度执行（cpuCfsQuota=false）。
对于 CPU，没必要设置限度
更现实情况
事实应用状况永远不会很好，还会一直地变动。在这种状况下，咱们仍应确保使用率始终低于咱们的要求。为了可预测性和稳定性，这将导致低利用率。
通过缩放缩小低利用率
为了抚平曲线并使之放弃在要求之下，咱们能够应用 HPA 这样的伸缩。一旦留神到使用量趋向于申请和限度，它将创立更多实例来扩散负载。
上图显示了单个 Pod 的资源应用状况。如果创立更多正本，那么所有 Pod 应用的资源总数将减少。应用 HPA，能够将单个 Pod 的应用曲线抚平，从而能够更无效地进行调度。
Pod 在初始化期间会应用更多资源
这是最难的一个问题，如果 pod 在初始化期间应用更多资源，那就将申请设置为较高的初始化使用率，但这在后续运行期间会导致较高的提早。因而，在这种状况下容许 CPU 适度应用是能够的，但不容许应用内存。
有人认为应该能够将 init-logic 移到 initContainer 中，该容器在理论应用程序容器之前运行，如下所示：
总的 Pod 资源申请会是 initContainer 资源申请
然而，这实际上并没有升高 Pod 的总资源申请，因为调度计算这样的：
pod requests = max(max(initContainers), sum(containers))K8sMeetup
VPA
HPA（Pod 程度主动伸缩）非常适合无状态（stateless）和古代（modern）服务。然而如果是有状态（stateful）服务或整体（monolithic）服务，可能就没那么容易了。
VPA（Pod 垂直主动伸缩）能够调整正在运行的 Pod 的资源申请，无需创立更多正本，它也能够用于举荐最佳申请值。
K8sMeetup
节点压力
本文中常常提到，K8s 调度程序不会查看节点上的理论资源应用状况，仅查看节点 Allocatable 和 Pod 申请。但一个节点能够给本人相似 MemoryPressure 或 DiskPressure 的 conditions。如果节点具备此 conditions，调度程序就会将其视为非最佳候选者。但有一点须要留神，如果没有 CpuPressure conditions，也就没有基于 CPU 的容器驱赶。
K8sMeetup
为什么会有资源限度？
为了获得最佳的可预测性和安全性，最好永远不要适度应用 requests=limits，那为什么还会存在限度呢？
简略来说
尽管咱们目前不晓得理论的用处，但有了宽泛的申请和限度后，开始开发应用程序变得更加容易。
优化资源应用
从实践上讲，让非关键 Pod 利用适度应用来缓解低利用率是一个好主见。如果节点能够接受压力（QoS），那么适度应用的 Pod 将与第一个容器一起被驱赶。
如果 kubelet 在未来能够完满预测 OOM 问题并驱赶正确的 Pod，那么容许内存适度应用可能会可行。
K8sMeetup
论断
深刻理解 K8s 治理资源可能非常复杂。通常，为了获得最佳的可预测性和稳定性，咱们总是让使用量低于要求。一旦利用在生产环境中稳固运行，咱们就能够尝试优化。
原文地址：https://mp.weixin.qq.com/s/NnutG4dDnm2zWY5MDiSGpQ