直播回顾 | 为什么说Kubernetes+容器能提升资源利用率？

本文是5月19日“CloudTech 博云说”第三期分享内容《为什么说kubernetes+容器能提升资源利用率？》的回顾整理。扫描上方海报二维码或点击文章末尾的阅读原文，回看精彩视频！

01

为什么应用跑在容器里， 比在虚拟机里资源利用率更高？

根据麦肯锡数据统计显示，整个业界的服务器平均利用率大约为6%，而 Gartner 的估计要乐观一些，大概在12%。国内一些银行的数据中心的利用率大概在 5% 左右 。而 Kubernetes 的资源利用率示例，我们可以看到：

• 应用跑在物理机资源利用率3%-5%

• 虚拟机是15%-20%

• 容器30%-40%

那么，为什么应用跑在容器里，比在虚拟机里资源利用率更高？
第一，虚拟化自身的资源隔离占用 10%，容器自身占用不超过1%。这是因为Docker 利用的是宿主机内核，而不需要Guest OS。因此，当新建一个容器时，Docker 不需要和虚拟机一样重新加载一个操作系统，这就避免了引导、加载操作系统内核这个比较费时费资源的过程。
当新建一个虚拟机时，虚拟机软件需要加载 Guest OS，这个新建过程是分钟级别的，而 Docker 由于直接利用宿主机的操作系统则省略了这个过程，容器的启动只需要它们所必需的运行环境，包括文件系统、系统类库、shell 环境。因此启动比虚拟机更加轻量。

第二，容器与虚拟化的定位和能力上的不同，也使得应用跑在容器中更能充分的利用资源。主要包括如下几点：

• 容器使用资源的时候，可以基于 Limit/Request 机制，给予容器弹性资源配置。
• 容器极度简单/自动的扩缩容能力，可以让应用在部署的时候，可以不用一开始就按照最大资源需要配置资源，而只在需要的时候快速增加实例即可。
• 容器在遇到故障或者资源抢占冲突的时候，可以自动迁移到别的有资源的节点。

基于如上三点，使得资源可以更充分有效地利用。

02

为什么容器更轻量，容器的机制是什么？
容器类似于 VM，但是它们具有被放宽的隔离属性，可以在应用程序之间共享操作系统（OS）。因此，容器被认为是轻量级的。容器与 VM 类似，具有自己的文件系统、CPU、内存、进程空间等。由于它们与基础架构分离，因此可以跨云和 OS 发行版本进行移植。
Docker 是 LXC（Linux Container） 和 AUFS（AnotherUnionFS） 一个组合：LXC 是负责资源管理，AUFS是负责镜像管理；包括 Cgroup， Namespace，Chroot等组件，并通过 Cgroup 资源管理，三者实际上是一环套一环的。Cgroup是在底层落实资源管理，LXC 在 Cgroup 上面封装了一层，随后 Docker 又在 LXC 封装了一层。

03

如何规划容器资源，设置应用的资源限制？
实践就是实践出来的。
所有容器都应该设置 Request 的值并不是指给容器实际分配的资源大小，它仅仅是给调度器看的，调度器会 “观察” 每个节点可以用于分配的资源有多少，也知道每个节点已经被分配了多少资源。
被分配资源的大小就是节点上所有 Pod 中定义的容器 Request 之和，它可以计算出节点剩余多少资源可以被分配(可分配资源减去已分配的 Request 之和)。如果发现节点剩余可分配资源大小比当前要被调度的 Pod 的 Request 还小，那么就不会考虑调度到这个节点，反之，才可能调度。
所以，如果不配置 Request，那么调度器就不能知道节点大概被分配了多少资源出去，调度器得不到准确信息，也就无法做出合理的调度决策，很容易造成调度不合理，有些节点可能很闲，而有些节点可能很忙，甚至 NotReady。
所以，建议是给所有容器都设置 Request，让调度器感知节点有多少资源被分配了，以便做出合理的调度决策，让集群节点的资源能够被合理的分配使用，避免陷入资源分配不均导致一些意外发生。 
尽量避免使用过大的 Request 与 Limit 如果你的服务使用单副本或者少量副本，给很大的 Request 与 Limit，让它分配到足够多的资源来支撑业务，那么某个副本故障对业务带来的影响可能就比较大，并且由于 Request 较大，当集群内资源分配比较碎片化，如果这个 Pod 所在节点挂了，其它节点又没有一个有足够的剩余可分配资源能够满足这个 Pod 的 Request 时，这个 Pod 就无法实现漂移，也就不能自愈，加重对业务的影响。
相反，建议尽量减小 Request 与 Limit，通过增加副本的方式来对你的服务支撑能力进行水平扩容，让你的系统更加灵活可靠。这个过程就是要依靠监控不断了解自己应用情况，来不断优化 Request 和 Limit 值。
避免测试 Namespace 消耗过多资源影响生产业务若生产集群有用于测试的 Namespace，如果不加以限制，可能导致集群负载过高，从而影响生产业务。可以使用 ResourceQuota 来限制测试 Namespace 的 Request 与 Limit 的总大小。

04

Kubernetes集群优化 kubelet配置资源预留
为了更好地使用集群，避免因为业务占用过多资源，而需要给集群系统预留资源公式如下，为kubelet配置。

Node Allocatable Resource = Node Capacity - Kube-reserved - system-reserved - eviction-thresholdNode Capacity：Node的所有硬件资源Kube-reserved：kube 组件预留的资源system-reserved：给system进程预留的资源eviction-threshold（阈值）：kubelet eviction(收回)的阈值设定
假设节点拥有 32Gi memeory，16 CPU 和 100Gi Storage 资源--enforce-node-allocatable=pods,kube-reserved,system-reserved--kube-reserved-cgroup=/kubelet.service--system-reserved-cgroup=/system.slice--kube-reserved=cpu=1,memory=2Gi,ephemeral-storage=1Gi--system-reserved=cpu=500m,memory=2Gi,ephemeral-storage=1Gi--eviction-hard=memory.available<500Mi,nodefs.available<10%

在这个场景下，Node Allocatable 将会是 14.5 CPUs、27.5Gi 内存以及 88Gi 本地存储。调度器保证这个节点上的所有 Pod 的内存 requests 总量不超过 27.5Gi， 存储不超过 88Gi。当 Pod 的内存使用总量超过 27.5Gi 或者磁盘使用总量超过 88Gi 时， kubelet 将会驱逐它们。如果节点上的所有进程都尽可能多地使用 CPU，则 Pod 加起来不能使用超过 14.5 CPUs 的资源。
当没有执行 kube-reserved 和/或 system-reserved 策略且系统守护进程 使用量超过其预留时，如果节点内存用量高于 31.5Gi 或存储大于 90Gi， kubelet 将会驱逐 Pod。

05

通过博云容器云平台BOC资源使用报表 来校正应用资源限制
博云容器云平台 BOC 可以使用报表功能来逐步校正资源限制，通过定期下载报表，关注应用使用情况，来优化参数。
可以基于博云容器云平台 BOC 的统计报表来看长期的应用资源占用趋势，比如某个应用配置了 4C8G 的资源占用，但是通过统计分析发现，其日常资源占用基本都在 1C2G-2C4G 之间，那么就可以调整更改应用功能的资源占用为2C4G。通过这类优化来提升资源利用率。

综上所述，Kubernetes+容器通过如下几个方式来提升资源利用率，可以将整体资源利用率从5%-10%提升到30%-40%：

1. 相对虚拟化，容器自身的资源占用更少（ 容器1% VS 虚拟化10%）。

2. 通过Limit/Request配置，为单容器提供资源弹性供给，提升单容器资源使用效率通过弹性伸缩、故障自愈、冲突迁移等机制，使得应用实例日常可以按照较少规模配置，仅在需要的时候扩容，并在使用高峰过去之后，再恢复至常规状态。

3. 通过长期的实例资源使用统计分析，优化资源配置，提升资源利用率。

/ END /

推荐阅读

直播回顾｜浅谈：云原生和容器的定义与关系

直播回顾｜多云时代如何定义企业云管理平台

   点击 阅读原文 ，回顾课程实录！

{{o.name}}

{{m.name}}