写在前面
当我开始大范围使用Kubernetes的时候,我开始考虑一个我做实验时没有遇到的问题:当集群里的节点没有足够资源的时候,Pod会卡在Pending状态。你是没有办法给节点增加CPU或者内存的,那么你该怎么做才能将这个Pod从这个节点拿走?最简单的办法是添加另一个节点,我承认我总是这么干。最终这个策略无法发挥出Kubernetes最重要的一个能力:即它优化计算资源使用的能力。这些场景里面实际的问题并不是节点太小,而是我们没有仔细为Pod计算过资源限制。
资源限制是我们可以向Kubernetes提供的诸多配置之一,它意味着两点:工作负载运行需要哪些资源;最多允许消费多少资源。第一点对于调度器而言十分重要,因为它要以此选择合适的节点。第二点对于Kubelet非常重要,每个节点上的守护进程Kubelet负责Pod的运行健康状态。大多数本文的读者可能对资源限制有一定的了解,实际上这里面有很多有趣的细节。在这个系列的两篇文章中我会先仔细分析内存资源限制,然后第二篇文章中分析CPU资源限制。
资源限制
资源限制是通过每个容器containerSpec的resources字段进行设置的,它是v1版本的ResourceRequirements类型的API对象。每个指定了"limits"和"requests"的对象都可以控制对应的资源。目前只有CPU和内存两种资源。第三种资源类型,持久化存储仍然是beta版本,我会在以后的博客里进行分析。大多数情况下,deployment、statefulset、daemonset的定义里都包含了podSpec和多个containerSpec。这里有个完整的v1资源对象的yaml格式配置:
这个对象可以这么理解:这个容器通常情况下,需要5%的CPU时间和50MiB的内存(requests),同时最多允许它使用10%的CPU时间和100MiB的内存(limits)。我会对requests和limits的区别做进一步讲解,但是一般来说,在调度的时候requests比较重要,在运行时limits比较重要。尽管资源限制配置在每个容器上,你可以认为Pod的资源限制就是它里面容器的资源限制之和,我们可以从系统的视角观察到这种关系。
内存限制
通常情况下分析内存要比分析CPU简单一些,所以我从这里开始着手。我的一个目标