K8S之资源管理

        关于资源管理，我们会从计算机资源管理（Computer Resources）、服务质量管理（Qos）、资源配额管理（LimitRange、ResourceQuota）等方面来进行说明

        Kubernetes集群里的节点提供的资源主要是计算机资源，计算机资源是可计量的能被申请、分配和使用的基础资源，这使之区别于API资源（API Resources，例如Pod和Services等）。当前计算机资源主要包括CPU、GPU及Memory，重点介绍CPU和Memory资源管理，GPU除非是一些需要用到算力的服务，否则对这个GPU性能需求不大。

        场景：我们在之前的实验中是没有对CPU和Memory进行定义的，yaml文件如下：

[root@k8s-master k8s-yaml]# cat nginx-deployment.yaml 
apiVersion : apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 2
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80

        这样的话，Kubernetes会认为该Pod所需要的资源很少，可以调度到任何可用的Node，这样一来，当集群中的计算机资源不是很充足的时候，例如集群的Pod负载突然增大，就会使得某得节点的资源严重不足。此时，为了避免系统挂掉，该节点会杀掉某些用户进程来释放资源，避免操作系统崩溃，加入系统崩溃的话，所有的Pod也会被牺牲掉，所以Kubernetes有自己的一套资源配额限制以及对应的Pod服务等级机制。

        1.可以全面的限制一个应用及其中的Pod所能占用的资源配额。

            （1）定义每个Pod上资源配额相关的参数，比如CPU/Memory Request/Limit；

            （2）自动为每个没有定义资源配额的Pod添加资源配额模版（LimitRange);

            （3）从总量上限制一个租户（Namespace层级）或者应用所能使用的资源配额的ResourceQuota。

        2.允许集群的资源被超额分配，以提高集群的资源利用率，同时允许用户根据业务的优先级，为不同的Pod定义相应的保障等级（QoS），Qos就是Pod生存的优先级，当系统资源不足的时候，低等级的Pod会被优先干掉，以确保高等级的Pod稳定运行。

        一个程序所使用的CPU和Memory是一个动态的量，会根据负载情况变化，因此最准确的说法是，某个进程的CPU使用量为0.1个CPU（Request）~1个CPU（Limit），内存占用则为500MB（Request）~1GB（Limit）。对应到Pod容器上，就是如下的4个参数：

        spec.container[].resources.requests . cpu:容器初始要求的CPU数量
        spec.container[].resources.limits.cpu：容器所能使用最大的CPU数量
        spec.container[].resources.requests.memory:容器初始要求的内存大小
        spec.container[].esources.limits.memory:容器所能使用最大的内存大小

其中，limit是对应资源上限，最多允许使用这么大的资源，由于CPU的资源是可压缩的，进程无论如何都不可能突破上限，因此设置起来比较容易。对于Memory这种不可压缩的资源，它的Limit值设置起来就有点复杂，如果设置得小了，则进程在业务繁忙期视图请求超过Limit限制的Memory值时，会被操作系统kill掉，因此，Memory额Request和Limit值需要结合进程实际的需求，或者结合压测结果来谨慎设置。例如：

        Pod A 的 Memory Request 袚设置为 1GB, Node A 当时空闲的 Memory 为 1.2GB, 符合 Pod A 的需求，因此 Pod A 被调度到 Node A 上 。 运行 3 天后， Pod A 的访问讨求大增，内存需要增加到 1.5GB, 此时 Node A 的剩余内存只有 200MB, 由于 Pod A 新增的内存已经超出系统资源范围，所以 Pod A 在这种情况下会被 Kubernetes“ 杀掉" 。
        没有设置Limit的Pod ，或者只设置了CPU Limit或者Memory Limit两者之一的Pod,看起来都是很有弹性的，但实际上，与4个参数都被设置了的Pod相比，它们处于一种不稳定状态，只是稳定一点儿而已。理解了这一点，就很容易理解Resource QoS问题了。如果我们有成百上千个不同的 Pod, 那么先手动设置每个Pod的这4个参数，再检查并确保这些参数的设置，都是合理的。比如不能出现内存超过2GB或者CPU占据两个核心的Pod。最后还得手工检查不同租户（命名空间）下的 Pod 资源使用量是否超过限额 。为此， Kubernetes 提供了另外两个相关对象：LimitRange及ResourceQuota, 前者解决了没有设置配额参数的Pod的默认资源配额问题，同时是Pod资源配额设置的合法性校验参考；后者则约束租户的资源总量配额问题。

        后面我们会分别从计算机资源管理（Computer Resources）、服务质量管理（Qos）、资源配额管理（LimitRange、ResourceQuota）来分析。