K8S 深入理解 Pod 对象

Pod 资源配置

K8S 深入理解 Pod 对象

文章插图
 
实际上上面几个步骤就是影响一个 Pod 生命周期的大的部分,但是还有一些细节也会在 Pod 的启动过程进行设置,比如在容器启动之前还会为当前的容器设置分配的 CPU、内存等资源,我们知道我们可以通过 CGroup 来对容器的资源进行限制,同样的,在 Pod 中我们也可以直接配置某个容器的使用的 CPU 或者内存的上限 。那么 Pod 是如何来使用和控制这些资源的分配的呢?
首先对于 CPU,我们知道计算机里 CPU 的资源是按“时间片”的方式来进行分配的,系统里的每一个操作都需要 CPU 的处理,所以,哪个任务要是申请的 CPU 时间片越多,那么它得到的 CPU 资源就越多,这个很容器理解 。
然后还需要了解下 CGroup 里面对于 CPU 资源的单位换算:
1 CPU =1000 millicpu(1 Core = 1000m)0.5 CPU = 500 millicpu (0.5 Core = 500m)这里的 m 就是毫、毫核的意思,Kube.NETes 集群中的每一个节点可以通过操作系统的命令来确认本节点的 CPU 内核数量,然后将这个数量乘以1000,得到的就是节点总 CPU 总毫数 。比如一个节点有四核,那么该节点的 CPU 总毫量为 4000m,如果你要使用0.5 core,则你要求的是 4000*0.5 = 2000m 。在 Pod 里面我们可以通过下面的两个参数来限制和请求 CPU 资源:
  • spec.containers[].resources.limits.cpu:CPU 上限值,可以短暂超过,容器也不会被停止
  • spec.containers[].resources.requests.cpu:CPU请求值,Kubernetes 调度算法里的依据值,可以超过
这里需要明白的是,如果 resources.requests.cpu 设置的值大于集群里每个节点的最大 CPU 核心数,那么这个 Pod 将无法调度,因为没有节点能满足它 。
到这里应该明白了,requests 是用于集群调度使用的资源,而 limits 才是真正的用于资源限制的配置,如果你需要保证的你应用优先级很高,也就是资源吃紧的情况下最后再杀掉你的 Pod,那么你就把你的 requests 和 limits 的值设置成一致,在后面应用的 Qos 中会具体讲解 。
比如,现在我们定义一个 Pod,给容器的配置如下的资源:
# pod-resource-demo1.yamlapiVersion: v1kind: Podmetadata:name: resource-demo1spec:containers:- name: resource-demo1image: Nginxports:- containerPort: 80resources:requests:memory: 50Micpu: 50mlimits:memory: 100Micpu: 100m【K8S 深入理解 Pod 对象】这里,CPU 我们给的是 50m,也就是 0.05core,这 0.05core 也就是占了 1 CPU 里的 5% 的资源时间 。而限制资源是给的是 100m,但是需要注意的是 CPU 资源是可压缩资源,也就是容器达到了这个设定的上限后,容器性能会下降,但是不会终止或退出 。比如我们直接创建上面这个 Pod:
?~ kubectl Apply -f pod-resource-demo1.yaml创建完成后,我们可以看到 Pod 被调度到 node1 这个节点上:
?~ kubectl get pods -o wideNAMEREADYSTATUSRESTARTSAGEIPNODENOMINATED NODEREADINESS GATESresource-demo11/1Running024s10.244.1.27node1<none><none>然后我们到 node1 节点上去查看 Pod 里面启动的 resource-demo1 这个容器:
?~ crictl psCONTAINERIMAGECREATEDSTATENAMEATTEMPTPOD ID1e4ef680a5a8887a94228f133e41 seconds agoRunningresource-demo10a00af47f2a12e......我们可以去查看下主容器的信息:
?~ crictl inspect 1e4ef680a5a88{"status": {"id": "1e4ef680a5a88af7eae88a6901f12eb103dc3f8e1807f26337cd9bfb3704ca05","metadata": {"attempt": 0,"name": "resource-demo1"},......"linux": {"resources": {"devices": [{"allow": false,"access": "rwm"}],"memory": {"limit": 104857600},"cpu": {"shares": 51,"quota": 10000,"period": 100000}},"cgroupsPath": "kubepods-burstable-poda194c43a_9551_494b_bd72_ab898afdcc0c.slice:cri-containerd:1e4ef680a5a88af7eae88a6901f12eb103dc3f8e1807f26337cd9bfb3704ca05",......实际上我们就可以看到这个容器的一些资源情况,Pod 上的资源配置最终也还是通过底层的容器运行时去控制 CGroup 来实现的,我们可以进入如下目录查看 CGroup 的配置,该目录就是 CGroup 父级目录,而 CGroup 是通过文件系统来进行资源限制的,所以我们上面限制容器的资源就可以在该目录下面反映出来:
?~ cd /sys/fs/cgroup/cpu/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-poda194c43a_9551_494b_bd72_ab898afdcc0c.slice?~ lscgroup.clone_childrencpuacct.statcpu.cfs_period_uscpu.rt_runtime_usnotify_on_releasecgroup.event_controlcpuacct.usagecpu.cfs_quota_uscpu.sharestaskscgroup.procscpuacct.usage_percpucpu.rt_period_uscpu.stat?~ cat cpu.cfs_quota_us10000


推荐阅读