目标
本篇文章我们将学习，如何为容器设置 CPU request（请求） 和 CPU limit（限制）。 容器使用的 CPU 不能超过所配置的限制。 如果系统有空闲的 CPU 时间，则可以保证给容器分配其所请求数量的 CPU 资源。
一、启动服务
在前面的章节中，有讲解过 metrics-server 服务，在这里，我们再次运行以下命令，启动metrics-server ：
minikube addons enable metrics-server
查看 metrics-server 资源API 是否可用，运行下面命令，则会输出将包含一个对 metrics.k8s.io 的引用。
$ kubectl get apiservices NAME v1beta1.metrics.k8s.io
二、创建命名空间
在进行资源分配之前，我们需要先创建一个命名空间，才能给这个空间分配资源。接下来我们先学习一下创建资源与集群的其余部分资源隔离。
在 Kubernetes 中，“名字空间（Namespace）”提供一种机制，将同一集群中的资源划分为相互隔离的组。 同一名字空间内的资源名称要唯一，但跨名字空间时没有这个要求。 名字空间作用域仅针对带有名字空间的对象，例如 Deployment、Service 等， 这种作用域对集群访问的对象不适用，例如 StorageClass、Node、PersistentVolume 等。
2.1、查看名字空间
初始状态下，Kubernetes 具有三个名字空间：
- default 无名字空间对象的默认名字空间
- kube-system 由 Kubernetes 系统创建的对象的名字空间
- kube-public 自动创建且被所有用户可读的名字空间（包括未经身份认证的）。此名字空间通常在某些资源在整个集群中可见且可公开读取时被集群使用。此名字空间的公共方面只是一个约定，而不是一个必要条件。
我们可以通过使用 kubectl 的命令，来查看现有的命名空间：
$ kubectl get namespaces NAME STATUS AGE default Active 11d kube-system Active 11d kube-public Active 11d
如果想要查看某一个命名空间的详情，也可以使用 kubectl describe namespaces 命令来查看：
$ kubectl describe namespacesName: default Labels: Annotations: Status: Active No resource quota. Resource Limits Type Resource Min Max Default ---- -------- --- --- --- Container cpu - - 100m
请注意，这些详情同时显示了资源配额（如果存在）以及资源限制区间。
资源配额跟踪并聚合 Namespace 中资源的使用情况，并允许集群运营者定义 Namespace 可能消耗的 Hard 资源使用限制。
限制区间定义了单个实体在一个 Namespace 中可使用的最小/最大资源量约束。
名字空间可以处于下列两个阶段中的一个:
- Active 名字空间正在被使用中
- Terminating 名字空间正在被删除，且不能被用于新对象。
2.2、创建名字空间
上面将的命名空间，都是当前集群自带的三个命名空间，那么我们能不能自己创建命名空间呢？答案是，肯定的，下面我们来学习两种创建方式。
新建一个名为 my-namespace.yaml 的 YAML 文件，并写入下列内容：
apiVersion: v1 kind: Namespace metadata: name:
然后运行命令：
kubectl create -f ./my-namespace.yaml
或者，你可以使用下面的命令创建名字空间：
kubectl create namespace
2.3、删除名字空间
可选字段 finalizers 允许观察者们在名字空间被删除时清除资源。 记住如果指定了一个不存在的终结器，名字空间仍会被创建， 但如果用户试图删除它，它将陷入 Terminating 状态。下面是删除命名空间的命令：
$ kubectl delete namespaces
此命令会删除当前命名空间下面的所有内容，删除是异步的，所以有一段时间你会看到名字空间处于 Terminating 状态。
三、指定 CPU 请求和 CPU 限制
要为容器指定 CPU 请求，请在容器资源清单中包含 resources: requests 字段。 要指定 CPU 限制，请包含 resources:limits。
在本练习中，你将创建一个具有一个容器的 Pod。容器将会请求 0.5 个 CPU，而且最多限制使用 1 个 CPU。 pods/resource/cpu-request-limit.yaml 是 Pod 的配置文件：
apiVersion: v1
kind: Pod
metadata:
name: cpu-demo
namespace: cpu-example
spec:
containers:
- name: cpu-demo-ctr
image: vish/stress
resources:
limits:
cpu: "1"
requests:
cpu: "0.5"
args:
- -cpus
- "2"
配置文件的 args 部分提供了容器启动时的参数。 -cpus “2” 参数告诉容器尝试使用 2 个 CPU。
1.创建 Pod：
$ kubectl apply -f https://k8s.io/examples/pods/resource/cpu-request-limit.yaml --namespace=cpu-example
2.验证所创建的 Pod 处于 Running 状态
$ kubectl get pod cpu-demo --namespace=cpu-example
3.查看显示关于 Pod 的详细信息：
$ kubectl get pod cpu-demo --output=yaml --namespace=cpu-example
输出显示 Pod 中的一个容器的 CPU 请求为 500 milli CPU，并且 CPU 限制为 1 个 CPU。
resources:
limits:
cpu: "1"
requests:
cpu: 500m
5.使用 kubectl top 命令来获取该 Pod 的度量值数据，我这里的输出显示 Pod 使用的是 974 milliCPU，即略低于 Pod 配置中指定的 1 个 CPU 的限制。
$ kubectl top pod cpu-demo --namespace=cpu-example NAME CPU(cores) MEMORY(bytes) cpu-demo 974m
3.1、CPU 单位
CPU 资源以 CPU 单位度量。Kubernetes 中的一个 CPU 等同于：
- 1 个 AWS vCPU
- 1 个 GCP核心
- 1 个 Azure vCore
- 裸机上具有超线程能力的英特尔处理器上的 1 个超线程
小数值是可以使用的。一个请求 0.5 CPU 的容器保证会获得请求 1 个 CPU 的容器的 CPU 的一半。 你可以使用后缀 m 表示毫。例如 100m CPU、100 milliCPU 和 0.1 CPU 都相同。 精度不能超过 1m。
CPU 请求只能使用绝对数量，而不是相对数量。0.1 在单核、双核或 48 核计算机上的 CPU 数量值是一样的。
删除 Pod：
$ kubectl delete pod cpu-demo --namespace=cpu-example
3.2、设置超过节点能力的 CPU 请求
CPU 请求和限制与都与容器相关，但是我们可以考虑一下 Pod 具有对应的 CPU 请求和限制这样的场景。 Pod 对 CPU 用量的请求等于 Pod 中所有容器的请求数量之和。 同样，Pod 的 CPU 资源限制等于 Pod 中所有容器 CPU 资源限制数之和。
Pod 调度是基于资源请求值来进行的。 仅在某节点具有足够的 CPU 资源来满足 Pod CPU 请求时，Pod 将会在对应节点上运行：
接下来我们在目录 pods/resource/cpu-request-limit-2.yaml 中创建一个 Pod，该 Pod 的 CPU 请求对于集群中任何节点的容量而言都会过大。 下面是 Pod 的配置文件，其中有一个容器。容器请求 100 个 CPU，这可能会超出集群中任何节点的容量。
apiVersion: v1
kind: Pod
metadata:
name: cpu-demo-2
namespace: cpu-example
spec:
containers:
- name: cpu-demo-ctr-2
image: vish/stress
resources:
limits:
cpu: "100"
requests:
cpu: "100"
args:
- -cpus
- "2"
3.2.1、创建 Pod
执行创建命令
$ kubectl apply -f https://k8s.io/examples/pods/resource/cpu-request-limit-2.yaml --namespace=cpu-example
3.2.2、Pod 的状态
运行下列命令，查看该 Pod 的状态
$ kubectl get pod cpu-demo-2 --namespace=cpu-example
输出显示 Pod 状态为 Pending。也就是说，Pod 未被调度到任何节点上运行， 并且 Pod 将无限期地处于 Pending 状态：
NAME READY STATUS RESTARTS AGE cpu-demo-2 0/1 Pending 0 7m
3.2.3、Pod 详情
可以输入以下命令，查看有关 Pod 的详细信息，包含事件
$ kubectl describe pod cpu-demo-2 --namespace=cpu-example
输出显示由于节点上的 CPU 资源不足，无法调度容器：
Events: Reason Message ------ ------- FailedScheduling No nodes are available that match all of the following predicates:: Insufficient cpu (3).
3.2.4、删除 Pod
当然，我也可以使用命名删除你的 Pod
$ kubectl delete pod cpu-demo-2 --namespace=cpu-example
四、不限制CPU
如果没有为容器指定 CPU 限制，则会发生以下情况之一：
- 容器在可以使用的 CPU 资源上没有上限。因而可以使用所在节点上所有的可用 CPU 资源。
- 容器在具有默认 CPU 限制的名字空间中运行，系统会自动为容器设置默认限制。 集群管理员可以使用 LimitRange 指定 CPU 限制的默认值。
如果为容器指定了 CPU 限制值但未为其设置 CPU 请求，Kubernetes 会自动为其 设置与 CPU 限制相同的 CPU 请求值。类似的，如果容器设置了内存限制值但未设置 内存请求值，Kubernetes 也会为其设置与内存限制值相同的内存请求。
总结
本篇文章通过配置集群中运行的容器的 CPU 请求和限制，你可以有效利用集群上可用的 CPU 资源。 通过将 Pod CPU 请求保持在较低水平，可以使 Pod 更有机会被调度。 通过使 CPU 限制大于 CPU 请求，你可以完成两件事：
- Pod 可能会有突发性的活动，它可以利用碰巧可用的 CPU 资源。
- Pod 在突发负载期间可以使用的 CPU 资源数量仍被限制为合理的数量。
到此这篇关于K8s实战教程之容器和 Pods资源分配的文章就介绍到这了,更多相关K8s 容器和 Pods资源分配内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！