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

这篇具有很好参考价值的文章主要介绍了K8S资源管理之计算资源管理。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

1.详解Requests和Limits参数

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

K8S资源管理之计算资源管理,K8S学习,kubernetes,容器,云原生

       尽管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=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

         文章来源地址https://www.toymoban.com/news/detail-852716.html

到了这里,关于K8S资源管理之计算资源管理的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • Kubernetes(K8s)与虚拟GPU(vGPU):实现高效管理和利用GPU资源的最佳实践

    目录 第一节:Kubernetes简介 第二节:虚拟GPU(vGPU)简介 第三节:Kubernetes中的GPU资源管理 第四节:虚拟GPU(vGPU)的部署和配置 第五节:GPU资源调度和负载均衡 第六节:GPU资源监控和调优 结论: 可先阅读一下参考: kubernetes如何将异构GPU(如NVIDIA、海光、寒武纪)统一协同

    2024年04月13日
    浏览(46)
  • K8s学习(二)Kubernetest的资源管理及五大资源介绍

    本文是k8s学习系列文章,前后串起来是一个完整的课程(学习笔记),本文记录k8s的资源管理方式及五大类资源的具体管理命令,看完本文基本上就能实现k8s的基本操作,可以独立部署小型项目了。 前期文章连接: 从零开始搭建kubernetes集群环境(虚拟机/kubeadm方式) 总结:

    2024年01月16日
    浏览(36)
  • 【K8S 】K8S配置资源管理

    1、概念 用来保存密码。token,敏感的K8S资源 这类数据可以直接存放在镜像中,但是放在Secret中可以更方便的控制,减少暴露的风险 Secret:保存加密的信息 2、Secret类型: docker-registry:存储docker仓库的认证信息,以及docker的组件认证信息(私有) generic:是Secret的默认模式,

    2024年01月17日
    浏览(45)
  • k8s---配置资源管理

    目录 内容预知 secret资源配置 secert的几种模式 pod如何来引用secret 陈述式创建secret 声明式+base64编码配置secret 将secret用vlumes的方式挂载到pod中 传参的方式将环境变量导入pod 如何通过secret加密方式获取仓库密码 configmap的资源配置 陈述式创建configmap资源配置 声明式配置configma

    2024年01月21日
    浏览(55)
  • k8s配置资源管理

    Secret Configmap Secret :保存密码,token,敏感的k8s资源 这类数据可以存放在镜像当中,但是防止secret当中可以更方便控制,减少暴露的风险 保存加密的信息 Docker-registry: 存储docker仓库认证信息,以及docker组件认证成功(私有) Generic: 是secret的默认模式,opaque base64加密编码的

    2024年01月21日
    浏览(47)
  • k8s 资源管理方式

    k8s中资源管理方式可以划分为下面的几种:命令式对象管理、命令式对象配置、声明式对象配置。 命令式对象管理 命令式对象管理:直接使用命令的方式来操作k8s资源, 这种方式操作简单,但是无法审计和追踪。 命令式对象配置 通过命令和配置文件来操作k8s资源,这种方式

    2024年02月07日
    浏览(42)
  • k8s- 配置资源管理

    配置资源管理 //Secret Secret 是用来保存密码、token、密钥等敏感数据的 k8s 资源,这类数据虽然也可以存放在 Pod 或者镜像中,但是放在 Secret 中是为了更方便的控制如何使用数据,并减少暴露的风险。 Secret 有四种类型:  ●kubernetes.io/service-account-token:由 Kubernetes 自动创建,

    2024年02月16日
    浏览(44)
  • K8S资源管理方式

    1.基础命令操作 2.创建pod 3.查看资源状态 4.查看pod中的容器日志 5.进入pod中的容器 6.删除pod资源 7.pod扩容 8.项目生命周期管理(创建–发布–更新–回滚–删除) 8.1创建service service类型 service端口 8.2发布 8.3更新 8.4回滚 8.5删除 如何获取资源配置清单文件模板(yaml配置文件)

    2024年02月13日
    浏览(51)
  • k8s常用资源管理

    目录 Pod(容器组):Pod是Kubernetes中最小的部署单元,可以包含一个或多个容器。Pod提供了一种逻辑上的封装,使得容器可以一起共享网络和存储资源 1、创建一个pod 2、pod管理 pod操作 目录 创建Pod会很慢 Pod(容器组):Pod是Kubernetes中最小的部署单元,可以包含一个或多个容

    2024年02月13日
    浏览(38)
  • K8s-资源管理(二)

    2. 资源管理 2.1 资源管理介绍 在kubernetes中,所有的内容都抽象为资源,用户需要通过操作资源来管理kubernetes。 kubernetes的本质上就是一个集群系统,用户可以在集群中部署各种服务,所谓的部署服务,其实就是在kubernetes集群中运行一个个的容器,并将指定的程序跑在容器中

    2024年02月15日
    浏览(42)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包