本文将於赛後同步刊登於笔者部落格

有兴趣学习更多 Kubernetes/DevOps/Linux 相关的资源的读者，欢迎前往阅读

更多相关科技的技术分享，欢迎追踪 矽谷牛的耕田笔记

对於 Kubernetes 与 Linux Network 有兴趣的可以参阅笔者的线上课程

前言

前篇文章探讨为什麽需要 Project 这样的概念，透过 Project 能够带来什麽样的好处，然而前篇文章只有带到简单的操作以及如何使用透过 Rancher 的 UI 来检视 Project 内的各种 Kubernetes 物件。

本篇文章将介绍我认为 Project 最好也最方便的功能， Resource Quotas 与 Container Default Resource Limit 到底是什麽以及如何使用。

资源控管介绍

熟悉 Kubernetes 的读者应该都知道资源控管是一个非常困难的问题，其根本原因是 Container 本身的实作方式导致资源控管不太容器。
很多人使用资源控管最常遇到的问题有

1. 不知道该怎麽设定 Resources Limit， CPU/Memory 到底要用哪种? 三种内建的 QoS 型态有哪些? 有哪些影响?
2. 设定好了 Limit/Request 後结果运作不如预期，或是某些情况下应用程序效能大幅度降低等

第一点是最容易遇到的，毕竟要如何有效地去分配容器使用的 CPU/Memory 是个很困难的问题，特别是第一次踏入到容器化的团队对於这个问题会有更大的疑惑，不确定该怎麽用。
第二个问题则是部分的 Linux Kernel 版本实作 Container 的资源控管与限制上会有一些 bug，可能会导致你的应用程序被不预期的 throttle，导致效能变得很低。

本篇文章不太探讨这两个问题，反而是探讨最基本的概念，毕竟上述两个概念跟 Rancher 没太大关系，反而是比较进阶使用与除错的内容。

Kubernetes 中针对 CPU/Memory 等系统资源有两种限制，称为 Request 与 Limit。
Request 代表的是要求多少，而 Limit 代表的是最多可以使用多少。
这些资源是以 Container 为基本单位，而 Pod 本身是由多个 Container 组成的，所以 CPU/Memory 的计算上就相对繁琐。

Kubernetes 本身有一个特别的物件称为 ResourceQuota，透过该物件可以针对特定 namespace 去限定该 namespace 内所有 Container 的资源上限。譬如可以设定 default namespace 最多只能用 10颗 vCPU，超过的话就没有办法继续部署。

Rancher 的 Project 本身就是一个管理多 namespace 的抽象概念，接下来看一下 Project 中有哪些关於 Resource 的管理。

操作

为了方便操作，先将 default namespace 给加入到之前创立的 Project 中，加进去後当前 project 中有三个 namespace，如下图。

接者编辑该 Project 去设定 Resource 相关的资讯，如下图

Project 中有两种概念要设定，第一种是 Resource Quota，第二个是 Container Default Resource Limit.
Resource Quota 是更高阶层的概念，是用来控管整个 Project 能够使用的 CPU/Memory 用量。
由於 Project 是由多个 namespaces 所组成的，所以设定上还要去设定每个 namespace 的用量，如上述范例就是设定
整个 Project 可以使用 100个 vCPU，而每个 namespace 最多可以使用 10 vCPU。
但是因为 namespace 本身就是使用 kubernetes ResourceQuota 来实作，而这个功能本身会有一个限制就是。
一但该 namespace 本身设定了 ResourceQuota，则所有部署到该 namespace 的容器都必须要明确的写出 CPU/Memory 用量。

这个概念也满容易理解的，毕竟你要去计算 namespace 的使用上限，那 namespace 内的每个 container 都需要有 CPU/Memory 等相关设定，否则不能计算。
如果你的容器没有去设定的话，你的服务会没有办法部署，会卡到 Scheduler 那个层级，连 Pending 都不会有。
但是如果要求每个容器部署的时候都要设定 CPU/Memory 其实会有点烦人，为了让这个操作更简单，Project 底下还有 Container Default Resource Limit 的设定。
该设定只要打开，所有部署到该 namespace 内的 Container 都会自动的补上这些设定。
如上图的概念就是，每个 Container 部署时就会被补上 CPU(Request): 3颗, CPU(Limit): 6颗

这边有一个东西要特别注意，Project 设定的 Container Default Resource Limit 本身有一个使用限制，如果 namespace 是再设定 Resource Quota 前就已经加入到 Project 的话，设定的数字并不会自动地套用到所有的 namespace 上。
反过来说，设定好这些资讯後，所有新创立的 namespace 都会自动沿用这些设定，但是设定前的 namespace 需要手动设定。

所以这时候必须要回到 namespace 上去重新设定，如下图

namespace 的编辑页面就可以重新设定该 namespace 上的资讯，特别是 Container Default Resource Limit。
当这边重新设定完毕後，就可以到系统中去看相关的物件

首先 Project 设定好 Resource Quota 後，Kubernetes 就会针对每个 namespace 都产生一个对应的 Quota 来设定，如下

因为设定每个 namespace 的 CPU 上限是 10颗，而该 project 总共有三个 namespace，所以系统中这三个 namespace 都产生了对应的 quota，而这些 quota 的设定都是 10颗 CPU。

其中 default namespace 的标示是 5025m/10 代表目前已经用了 5.025颗 CPU，而系统上限是 10颗。

这时候将 default namespace 内的 pod 都清空，接者重新再看一次该 quota 物件就会发现 used 的数值从 5025m 到 0。

由於上述 default namespace 中设定 CPU 预设补上 0.1颗 CPU (Request/Limit)，所以 Kubernetes 会创造相关的物件 Limits

从上述物件可以观察到该 LimitRange 设定了 100m 的 CPU。

最後尝试部署一个简单的 deployment 来测试此功能看看，使用一个完全没有标示任何 Resource 的 deployment，内容如下。

该物件部署到丛集後，透过 kubectl describe 去查看一下这些 Pod 的状态，可以看到其 Resource 被自动的补上 Limits/Requests: 100m。

Resource 的管理一直以来都不容易， Rancher 透过 Project 的管理方式让团队可以更容易的去管理多 namespace 之间的资源用量，同时也可以透过这个机制要求所有要部署的 container 都要去设定资源用量来确保不会有容器使用过多的资源。