k8s的资源分配

awkj 发布于2019-07-01 16:18 / 993人阅读

摘要：整个名称空间下的资源配额利用搭建部署服务，并在正式的场合使用时，几乎是肯定要引入一个用户概念的。如下创建一个创建了后我们每次创建一个也即都要指定它的资源配额，否则即便创建成功，容器也不能起来。

限制每个实例

在创建一个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                      Active
quota-example                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

云服务器 GPU云服务器 etcd存储k8s资源对象分配的内存不够管理客户资源的系统 jsp的静态资源

文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。

转载请注明本文地址：https://www.ucloud.cn/yun/32428.html

利用K8S技术栈打造个人私有云（连载之：K8S资源控制）

摘要：将用户命令通过接口传送给，从而进行资源的增删改等操作。要使用编写应用程序，当下大多语言都可以很方便地去实现请求来操作的接口从而控制和查询资源，但本文主要是利用已有的客户端来更加优雅地实现的资源控制。 showImg(https://segmentfault.com/img/remote/1460000013517345); 【利用K8S技术栈打造个人私有云系列文章目录】利用K8S...

Reducto 2019-06-28 17:55 评论0 收藏0
利用K8S技术栈打造个人私有云（连载之：K8S资源控制）

摘要：将用户命令通过接口传送给，从而进行资源的增删改等操作。要使用编写应用程序，当下大多语言都可以很方便地去实现请求来操作的接口从而控制和查询资源，但本文主要是利用已有的客户端来更加优雅地实现的资源控制。 showImg(https://segmentfault.com/img/remote/1460000013517345); 【利用K8S技术栈打造个人私有云系列文章目录】利用K8S...

Render 2019-07-01 16:39 评论0 收藏0
Kubernetes在混合云架构下的应用

摘要：但考虑到该用户在跨集群模式下的困扰，开始策划将托管云物理机纳入现有集群统一管理的方案，即在混合云架构下仅需部署管理一套集群。托管云物理机纳入UK8S集群统一管理后，可实现托管云物理机保障平峰时业务正常运行，高峰时期利用UK8S快速扩容公有云资源的理想应用场景，继而提升混合云的可用性。 ——海豹他趣技术负责人张嵩混合云的业务模式厦门海豹他趣信息技术股份有限公司于2012年4...

BenCHou 2019-07-02 12:18 评论0 收藏0
使用 Kubernetes 部署一个记事本项目

摘要：简称，是在年发布的一个开源项目。网络要能够通信，必须部署网络，是其中一个可选方案。最常使用，可以管理多个副本，并确保按照期望的状态运行，底层调用。用于每个最多只运行一个副本的场景。 Kubernetes 简称 k8s，是 google 在 2014 年发布的一个开源项目。 Kubernetes 解决了哪些问题？真实的生产环境应用会包含多个容器，而这些容器还很可能会跨越多个服务器主机部...

null1145 2019-08-23 18:32 评论0 收藏0
K8S的apiVersion该用哪个

摘要：如版本之前版本到版本之间版本之后一各种的含义该软件可能包含错误。启用一个功能可能会导致随时可能会丢弃对该功能的支持，恕不另行通知软件经过很好的测试。启用功能被认为是安全的。本篇文章来自Terraform与Kubernetes中关于Deployment apps/v1的吐槽 Kubernetes的官方文档中并没有对apiVersion的详细解释，而且因为K8S本身版本也在快速迭代，有些...

ziwenxie 2019-07-01 16:56 评论0 收藏0
k8s之CRD--为自定义资源生成代码

摘要：看过的应该都知道项目中有大量代码工具生成的代码。执行即脚本将自动生成下面的文件和路径脚本运行后大体会建立如下的包管理结构是不是很简单代码是被完全生成的，就像包含我们的语言类型的文件下面的文件一样然后你就可以基于生成的代码写自己的了。 CRD简介和使用姿势 CustomResourceDefinition（CRD）是 v1.7 + 新增的无需改变代码就可以扩展 Kubernetes AP...

jkyin 2019-07-01 17:28 评论0 收藏0