k8s的资源分配

限制每个实例

在创建一个replicationcontroller（以下简称rc）时，我们可以在创建文件中指定pod的资源配额，如下面的json：


 {
    "kind": "ReplicationController",
    "apiVersion": "v1",
    "metadata": {
        "name": "eatcpu",
        "creationTimestamp": null
    },
    "spec": {
        "replicas": 2,
        "selector": {
            "name": "huang"
        },
        "template": {
            "metadata": {
                "name": "cpu",
                "labels": {
                    "name": "huang"
                }
            },
            "spec": {
                "containers": [
                    {
                        "name": "eatcpucontainer",
                        "image": "registry.hub.abc.com.cn/eatcpu:v1.1",
                        "resources": {
                        "request": {
                                "cpu": "1.0",
                                "memory": "1.0Gi"
                            },
                            "limits": {
                                "cpu": "1.2",
                                "memory": "1.1Gi"
                            }
                        },
                        "command": [
                            "/deadloop",
                            "-max_procs=4"
                        ]
                    }
                ]
            }
        }
    },
    "status": {
        "replicas": 0
    }
}

当然实际上json不用写这么复杂，关键是：

 "resources": {
             "limits": {
                      "cpu": "1.0",
                      "memory": "1.0Gi"
            },
            "limits": {
                    "cpu": "1.2",
                    "memory": "1.1Gi"
              }
         },
     

这句的意思是给这个rc的每个pod分配cpu额度的最低要求是1.0（即1个CPU核心），内存的最低要求是1.0Gi，对CPU的限制是不能超过1.2个核心，内存则是1.1Gi。
当我们执行create命令的时候，若scheduler组件检查各个nodes发现没有满足1个空闲cpu核心和1Gi空闲内存的机器，那么这个pod就不能被创建，若rc要创建3个pod，整个集群只能满足创建2个，那么第三个pod会被放入队列中，等待集群有足够资源时再创建出来。

另外，若pod在运行过程中持续地消耗内存，超过了1.1G，pod会被销毁并重启，但当cpu消耗超过配额时，k8s不会做出相应的措施。

k8s1.3左右的版本增加了horizontalAutoScale特性，当CPU在一定时间内高于一个阈值时，会出发控制器对其进行水平扩容。

整个名称空间下的资源配额

利用k8s搭建部署服务，并在正式的场合使用时，几乎是肯定要引入一个“用户”概念的。可以使用namespace来实现用户的隔离。并使用quota为每个用户指定配额。
注：这里差不多是翻译github上原文，引用的几个yaml也出自于彼处，有兴趣的可以直接去看官文。

k8s下默认的namespace是default，我们可以手动添加一个namespace：

$ kubectl create -f namespace.yaml
$ kubectl get namespaces
NAME            LABELS             STATUS
default         <none>             Active
quota-example   <none>             Active

接着我们创建一个quota，quota可以指定某个namespace有多少的资源配额，包括cpu，内存，persistentvolumeclaims（据说是内存），pod数量，rc数量等等。
如下创建一个quota：

$ kubectl create -f quota.yaml --namespace=quota-example
$ kubectl describe quota quota --namespace=quota-example
Name:                   quota
Namespace:              quota-example
Resource                Used    Hard
--------                ----    ----
cpu                     0       20
memory                  0       1Gi
persistentvolumeclaims  0       10
pods                    0       10
replicationcontrollers  0       20
resourcequotas          1       1
secrets                 1       10
services                0       5

创建了quota后我们每次创建一个rc(也即pods)都要指定它的资源配额，否则即便创建成功，容器也不能run起来。
指定配额的方法见标题1，但是那是对一个集群中的pod统一制定，我们也可以统一指定该namespace下的所有pods的配额，即创建一个limits：

$ kubectl create -f limits.yaml --namespace=quota-example
limitranges/limits
$ kubectl describe limits limits --namespace=quota-example
Name:           limits
Namespace:      quota-example
Type            Resource        Min     Max     Default
----            --------        ---     ---     ---
Container       memory          -       -       512Mi
Container       cpu             -       -       100m

现在我们可以正常地run一个rc了，并且，在容器成功跑起来后，我们可以统一地看到该namespace下的资源使用情况：

kubectl describe quota quota --namespace=quota-example
Name:                   quota
Namespace:              default
Resource                Used            Hard
--------                ----            ----
cpu                     100m            20
memory                  536870912       1Gi
persistentvolumeclaims  0               10
pods                    1               10
replicationcontrollers  1               20
resourcequotas          1               1
secrets                 1               10
services                0               5