K8S资源管理之计算资源管理

最新推荐文章于 2024-05-18 09:12:06 发布

wyx学习k8s

最新推荐文章于 2024-05-18 09:12:06 发布

阅读量1.2k

点赞数 26

分类专栏： K8S学习文章标签： kubernetes 容器云原生

本文链接：https://blog.csdn.net/qq_37278522/article/details/137601236

版权

K8S学习专栏收录该内容

22 篇文章 0 订阅

订阅专栏

1.详解Requests和Limits参数

以CPU为例，下图显示了未设置Limits与设置了Requests和Limits的CPU使用率的区别

尽管Requests和Limits只能被设置到容器上，但是设置了Pod级别的Requests和Limits能大大提高管理Pod的便利性和灵活性，因此在Kubernetes中提供了对Pod级别的Requests和Limits的配置。对于CPU和内存而言，Pod的Requests或Limits指该Pod中所有容器的Requests或Limits的总和（对于Pod中没有设置Requests或Limits的容器，该项的值被当作0或者按照集群配置的默认值来计算）。下面对CPU和内存这两种计算资源的特点进行说明。

（1）CPU

CPU的Requests和Limits是通过CPU数(cpus)来度量的。CPU的资源值是绝对值，而不是相对值，比如O.1CPU在单核或多核机器上是一样的，都严格等于0.1CPU core。

（2）Memory

内存的Requests和Limits计量单位是字节数。使用整数或者定点整数加上国际单位制来表示内存值。国际单位制包括十进制的E、P、T、G、M、K、m或二进制的Ei、Pi、Ti、Gi、Mi、Ki。KiB与MiB是以二进制表示的字节单元，常见的KB与MB则是以十进制表示的字节单位，简而言之：

1KB=1000Bytes=8000Bits

1KiB= $2^{10}$ Bytes=1024Bytes=8192Bits

2.基于Requests和Limits的Pod调度机制

当—个Pod创建成功时，Kubernetes调度器(Scheduler)会为该Pod选择一个节点来执行。对于每种计算资源(CPU和Memory)而言，每个节点都有一个能用于运行Pod的最大容量值。调度器在调度时，首先要确保调度后该节点上所有Pod的CPU和内存的Requests 总和，不超过该节点能提供给Pod使用的CPU和Memory的最大容量值。

例如：某个节点上的CPU资源充足，而内存为4GB,其中3GB可以运行Pod,而某Pod的Memory Requests为1GB、Limits为2GB,那么在这个节点上最多可以运行3个这样的Pod。

有个情景：可能某个节点上的实际资源使用量非常低，但是已运行Pod配置的Requests值的总和非常高，如果要新调度Pod的Requests值+已运行所有Pod配置的Requests值>节点提供给Pod资源容量上限，这是该Pod不会在该节点上运行。

用数字量化来说就是3个Pod实际使用内存都不足500M，但是3个Pod的Request值相加已经达到了节点可用内存上限3G，故K8S不会在调度Pod到该节点上了

3.Requests和Limits的背后机制

kubelet在启动Pod的某个容器时，会将容器的Requests和Limits值转化为相应的容器启动参数传递给容器来执行，传递参数给Docker的过程如下：

1.spec.container[].resources.requests.cpu

这个参数值会被转化为core数（比如配置100m会转化成0.1），然后乘以1024，再将这个结果作为--cpu-shares参数的值传递给docker run命令，在docker run命令中，--cpu-share参数是一个相对权重值（Relative Weight），这个相对权重值会决定Docker在资源竞争时分配给容器的资源比例。

这里举例说明--cpu-shares参数在Docker中的含义：比如将两个容器的CPU Requests分别设置为1和2,那么容器在docker run启动时对应的--cpu-shares参数值分别为1024和2048，在主机CPU资源产生竞争时，Docker会尝试按照1:2的配比将CPU资源分配给这两个容器使用。

其中，这个参数对于Kubernetes来说是绝对值，是多少就会转换后传递给docker的--cpu-shares参数，主要用于Kubernetes的调度和管理，但是对于Docker来说是相对值，按照比例来分配资源

2.spec.container[].resources.limits.cpu

这个参数值会被转化为millicore数（比如配置的1被转化为1000, 而配置的100m被转化为100)，将此值乘以100000,再除以1000,然后将结果值作为--cpu-quota参数的值传递给docker run 命令。docker run命令中的另一个参数--cpu-period 默认被设置为100000,表示Docker重新计算和分配CPU的使用时间间隔为100000µs ( 100ms ) 。

Docker的--cpu-quota参数和--cpu-period参数一起配合完成对容器CPU的使用限制：比如在Kubernetes中配置容器的CPU Limits为0.1, 那么计算后--cpu-quota为10000,而--cpu-period 为 100000, 这意味着Docker在l00ms内最多给该容器分配10ms*core的计算资源用量，10/100=0.1 core 的结果与 Kubernetes 配置的意义是一致的。

3.spec.container[].resources.requests.memory

这个参数值只提供给Kubernetes调度器作为调度和管理的依据，不会作为任何参数传递给Docker

4.spec.container[].resources.limits.memory

这个参数值会被转化为单位为Bytes的整数，值作为--memory参数传递给docker run。

如果一个容器在运行过程中使用了超出其内存Limits配置的内存限制值，那么它可能会被“Kill”掉，如果这个容器的重启策略是always，那么kubernetes会在kill掉后重新拉起，此时应该重新评估设置limits.memory值。

与内存Limits不同的是，CPU在容器技术中属于可压缩资源，因此对CPU的Limits配置一般不会因为偶然超标使用而导致容器被系统”Kill"。

4.计算资源使用情况监控

Pod的资源用量会作为Pod的状态信息一同上报给Master。如果在集群中配置了Heapster来监控集群的性能数据，那么还可以从Heapster中查看Pod的资源用量信息。

5.计算资源常见问题分析

1.Pod状态为Pending,错误信息为FailedScheduling。如果Kubernetes调度器在集群中找不到合适的节点来运行Pod,那么这个Pod会一直处于未调度状态，直到调度器找到合适的节点为止。可以用这个命令来查看pod事件信息：kubelet describe pod $pod,如果有类似FailedScheduling ailed for reason PodExceedsFreeCPU and possibly others的日志，说明是CPU资源不够导致调度失败。解决方法：

1.添加更多的Node节点

2.停止一些非必要的Pod，释放资源

3.检查Pod配置，错误的配置肯可能会导致该Pod永远无法被调度执行。例如：整个集群的所有节点都是1CPU，而Pod的配置CPU Requests为2，这样该Pod永远无法调度

查看节点计算资源命令：

[root@k8s-master ~]# kubectl describe node k8s-node01
Name:               k8s-node01
Roles:              <none>
Labels:             beta.kubernetes.io/arch=amd64
                    beta.kubernetes.io/os=linux
                    kubernetes.io/arch=amd64
                    kubernetes.io/hostname=k8s-node01
                    kubernetes.io/ingress=nginx
                    kubernetes.io/os=linux
Annotations:        kubeadm.alpha.kubernetes.io/cri-socket: unix:///var/run/containerd/containerd.sock
                    node.alpha.kubernetes.io/ttl: 0
                    projectcalico.org/IPv4Address: 11.0.1.13/24
                    projectcalico.org/IPv4IPIPTunnelAddr: 172.16.85.192
                    volumes.kubernetes.io/controller-managed-attach-detach: true
CreationTimestamp:  Wed, 20 Mar 2024 10:42:57 +0800
Taints:             <none>
Unschedulable:      false
Lease:
  HolderIdentity:  k8s-node01
  AcquireTime:     <unset>
  RenewTime:       Fri, 12 Apr 2024 09:21:48 +0800
Conditions:
  Type                 Status  LastHeartbeatTime                 LastTransitionTime                Reason                       Message
  ----                 ------  -----------------                 ------------------                ------                       -------
  NetworkUnavailable   False   Wed, 10 Apr 2024 08:30:50 +0800   Wed, 10 Apr 2024 08:30:50 +0800   CalicoIsUp                   Calico is running on this node
  MemoryPressure       False   Fri, 12 Apr 2024 09:20:17 +0800   Fri, 12 Apr 2024 09:15:11 +0800   KubeletHasSufficientMemory   kubelet has sufficient memory available
  DiskPressure         False   Fri, 12 Apr 2024 09:20:17 +0800   Fri, 12 Apr 2024 09:15:11 +0800   KubeletHasNoDiskPressure     kubelet has no disk pressure
  PIDPressure          False   Fri, 12 Apr 2024 09:20:17 +0800   Fri, 12 Apr 2024 09:15:11 +0800   KubeletHasSufficientPID      kubelet has sufficient PID available
  Ready                True    Fri, 12 Apr 2024 09:20:17 +0800   Fri, 12 Apr 2024 09:15:11 +0800   KubeletReady                 kubelet is posting ready status
Addresses:
  InternalIP:  11.0.1.13
  Hostname:    k8s-node01
Capacity:
  cpu:                2
  ephemeral-storage:  18121Mi
  hugepages-1Gi:      0
  hugepages-2Mi:      0
  memory:             1862816Ki
  pods:               110
Allocatable:
  cpu:                2
  ephemeral-storage:  17101121099
  hugepages-1Gi:      0
  hugepages-2Mi:      0
  memory:             1760416Ki
  pods:               110
System Info:
  Machine ID:                 770cecbd0b4543279b46495d03f3e1d7
  System UUID:                83374D56-C17C-C044-73D5-E8B739FCF790
  Boot ID:                    69a2e659-996e-4876-8324-5413b3880695
  Kernel Version:             3.10.0-1160.108.1.el7.x86_64
  OS Image:                   CentOS Linux 7 (Core)
  Operating System:           linux
  Architecture:               amd64
  Container Runtime Version:  containerd://1.6.28
  Kubelet Version:            v1.27.1
  Kube-Proxy Version:         v1.27.1
Non-terminated Pods:          (3 in total)
  Namespace                   Name                                        CPU Requests  CPU Limits  Memory Requests  Memory Limits  Age
  ---------                   ----                                        ------------  ----------  ---------------  -------------  ---
  kube-system                 calico-kube-controllers-6c99c8747f-lth46    0 (0%)        0 (0%)      0 (0%)           0 (0%)         2d
  kube-system                 calico-node-2jq57                           250m (12%)    0 (0%)      0 (0%)           0 (0%)         2d
  kube-system                 kube-proxy-bvrr7                            0 (0%)        0 (0%)      0 (0%)           0 (0%)         22d
Allocated resources:
  (Total limits may be over 100 percent, i.e., overcommitted.)
  Resource           Requests    Limits
  --------           --------    ------
  cpu                250m (12%)  0 (0%)
  memory             0 (0%)      0 (0%)
  ephemeral-storage  0 (0%)      0 (0%)
  hugepages-1Gi      0 (0%)      0 (0%)
  hugepages-2Mi      0 (0%)      0 (0%)
Events:
  Type    Reason                   Age                  From     Message
  ----    ------                   ----                 ----     -------
  Normal  NodeHasSufficientMemory  6m45s (x8 over 14d)  kubelet  Node k8s-node01 status is now: NodeHasSufficientMemory
  Normal  NodeHasNoDiskPressure    6m45s (x8 over 14d)  kubelet  Node k8s-node01 status is now: NodeHasNoDiskPressure
  Normal  NodeHasSufficientPID     6m45s (x8 over 14d)  kubelet  Node k8s-node01 status is now: NodeHasSufficientPID
  Normal  NodeReady                6m45s (x8 over 14d)  kubelet  Node k8s-node01 status is now: NodeReady

我们细致的来看这两条配置：

Capacity:
cpu: 2
ephemeral-storage: 18121Mi
hugepages-1Gi: 0
hugepages-2Mi: 0
memory: 1862816Ki
pods: 110
Allocatable:
cpu: 2
ephemeral-storage: 17101121099
hugepages-1Gi: 0
hugepages-2Mi: 0
memory: 1760416Ki
pods: 110

超过可用资源容量上限(Capacity)和已分配资源量(Allocated resources)差额的Pod无法运行在该Node上。

2.容器被强行终止（Terminated）。如果容器使用的资源超过了它配置的Limits，那么该容器可能被强行终止。可以用这个命令来查看pod事件信息：kubelet describe pod $pod,如果有类似Last Termination State：Terminated 以及Restart Count：5，说明容器上个状态是终止的并且已经根据重启策略重启了5次

kubectl get pod -o go-template='{{range.status.containerStatuses}} {{"Container Name:" }} {{.name}}{{"\r\nLastState: "}} {{.lastState}} {{end}}' -n kube-system $POD

可以查看是否有OOM

6.对大内存页 (Huge Page) 资源的支持

我们可以将Huge Page理解为一种特殊的计算资源：拥有大内存页的资源。而拥有Huge Page资源的Node也与拥有GPU资源的Node一样，属于一种新的可调度资源节点（Schedulable Resource Node）。

Huge Page类似于CPU或者Memory资源，但不同于CPU或者Memory,Huge Page资源属于不可超限使用的资源，也支持ResourceQuota实现配额限制。

举例说明：

1.节点规划分配多种规格的巨页

在etc/default/grub 中添加

[root@k8s-master ~]# cat /etc/default/grub 
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="crashkernel=auto spectre_v2=retpoline rhgb quiet hugepagesz=1G hugepages=2 hugepagesz=2M hugepages=512"
GRUB_DISABLE_RECOVERY="true"

代表了分配了 2*1GiB 的 1 GiB 页面和 512*2 MiB 的 2 MiB 页面。

2.查看节点计算资源

kubectl describe node $node

Capacity:
  cpu:                ...
  ephemeral-storage:  ...
  hugepages-1Gi:      2Gi
  hugepages-2Mi:      1Gi
  memory:             ...
  pods:               ...
Allocatable:
  cpu:                ...
  ephemeral-storage:  ...
  hugepages-1Gi:      2Gi
  hugepages-2Mi:      1Gi
  memory:             ...
  pods:               ...

3.创建pod yaml文件

apiVersion: v1
kind: Pod
metadata:
  name: huge-pages-example
spec:
  containers:
  - name: example
    image: fedora:latest
    command:
    - sleep
    - inf
    volumeMounts:
    - mountPath: /hugepages-2Mi
      name: hugepage-2mi
    - mountPath: /hugepages-1Gi
      name: hugepage-1gi
    resources:
      limits:
        hugepages-2Mi: 100Mi
        hugepages-1Gi: 2Gi
        memory: 100Mi
      requests:
        memory: 100Mi
  volumes:
  - name: hugepage-2mi
    emptyDir:
      medium: HugePages-2Mi
  - name: hugepage-1gi
    emptyDir:
      medium: HugePages-1Gi

wyx学习k8s

关注

26
点赞
踩
30

收藏

觉得还不错? 一键收藏
0
评论
K8S资源管理之计算资源管理

以CPU为例，下图显示了未设置Limits与设置了Requests和Limits的CPU使用率的区别尽管Requests和Limits只能被设置到容器上，但是设置了Pod级别的Requests和Limits能大大提高管理Pod的便利性和灵活性，因此在Kubernetes中提供了对Pod级别的Requests和Limits的配置。
复制链接

扫一扫