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