【kubernetes系列】kubernetes之计算资源管理

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

资源类型

在 Kubernetes 中,Node 提供资源,而 Pod 使用资源。其中资源分为计算(CPU、Memory、GPU)、存储(Disk、SSD)、网络(Network Bandwidth、IP、Ports)。这些资源提供了应用运行的基础,正确理解这些资源以及集群调度如何使用这些资源,对于大规模的 Kubernetes 集群来说至关重要,不仅能保证应用的稳定性,还可以提高资源的利用率。在日常工作中,我们一般比较关心其中的计算资源,包括CPU和内存。CPU 的单位是 core,memory 的单位是 byte。

可压缩资源

目前kubernetes支持的可压缩资源是CPU。它的特点是,当可压缩资源不足时,Pod 只会饥饿少用,但不会退出。CPU 资源的限制和请求以cpu为单位。Kubernetes 中的一个 cpu 就是一个核,就是一个逻辑CPU。一个核相当于1000个微核,即1=1000m,0.5=500m。

不可压缩资源

目前kubernetes支持的不可压缩资源是内存。它的特点是,当不可压缩资源不足时,Pod 就会因为 OOM被内核杀掉。内存的限制和请求以字节为单位。可以使用以下后缀之一作为平均整数或定点整数表示内存:E,P,T,G,M,K。还可以使用两个字母的等效的幂数:Ei,Pi,Ti ,Gi,Mi,Ki。

POD中的资源请求和资源限制

requests 资源请求 pod最低需求(表示Pod对资源的最小需求,因此在调度的时候会如果Node剩余的资源不能满足Pod的需求,则不会调度到对应的Node上。Scheduler调度的时候并不关注在调度时具体的资源使用情况,而是根据现存Pod的资源请求情况来进行调度。调度器首先将不符合请求的Node排除在外,然后在执行优选策略最后在选定pod)

由于 Pod 可以由多个 Container 组成,所以 CPU 和内存资源的限额,是要配置在每个Container的定义上的。这样,Pod 整体的资源配置,就由这些 Container的配置值累加得到。

示例

执行下面yaml的内容:

[root@k8s-m1 k8s-resource]# cat resource-limit-pod.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: resource-limit-pod
  namespace: default
  labels:
    name: myapp
spec:
  containers:
  - name: myapp
    image: ikubernetes/stress-ng
    command: ["/usr/bin/stress-ng","-c 1","--metrics-brief"]
    ports:
    - name: http
      containerPort: 80
    resources:
      requests:
        memory: "128Mi"
        cpu: "200m"
      limits:
        memory: "512Mi"
        cpu: "500m"
[root@k8s-m1 k8s-resource]# kubectl apply  -f resource-limit-pod.yaml 
pod/resource-limit-pod created

查看结果:

[root@k8s-m1 k8s-resource]# kubectl exec -it resource-limit-pod -- top
Mem: 7805096K used, 202092K free, 6444K shrd, 2104K buff, 4575292K cached
CPU:   3% usr   1% sys   0% nic  88% idle   6% io   0% irq   0% sirq
Load average: 0.14 0.55 0.71 3/1509 33
  PID  PPID USER     STAT   VSZ %VSZ CPU %CPU COMMAND
    6     1 root     R     6892   0%  15   2% {stress-ng-cpu} /usr/bin/stress-ng -c 1 --metrics-brief
    1     0 root     S     6244   0%   9   0% /usr/bin/stress-ng -c 1 --metrics-brief
   29     0 root     R     1500   0%   9   0% top

我们看到CPU占用是3%,为什么呢?因为我的集群node都是是16个core。我们最大限制是0.5核。所以应该是0.5/16≈3.1%。

Request和Limits

基于Requests和Limits的Pod调度机制

  • 调度器在调度时,首先要确保调度后该节点上所有Pod的CPU和内存的Requests总和,不超过该节点能提供给Pod使用的CPU和Memory的最大容量值;
  • 即使某节点上的实际资源使用量非常低,但是已运行Pod配置的Requests值的总和非常高,再加上需要调度的Pod的Requests值,会超过该节点提供给Pod的资源容量上限,这时Kubernetes仍然不会将Pod调度到该节点上。如果Kubernetes将Pod调度到该节点上,之后该节点上运行的Pod又面临服务峰值等情况,就可能导致Pod资源短缺;

Requests和Limits的背后机制

kubelet在启动Pod的某个容器时,会将容器的Requests和Limits值转化为相应的容器启动参数传递给容器执行器。如果是docker 容器:

  • spec.container[].resources.requests.cpu: 转化为docker 的–cpu-share;
  • spec.container[].resources.limits.cpu: 转为docker的–cpu-quota;
  • spec.container[].resources.requests.memory: 提供给Kubernetes调度器作为调度和管理的依据,不会作为任何参数传递给Docker;
  • spec.container[].resources.limits.memory: 会转为–memory;
    【kubernetes系列】kubernetes之计算资源管理,Kubernetes,kubernetes

QoS(服务质量等级)

Kubernetes是根据Pod的Requests和Limits配置来实现针对Pod的不同级别的资源服务质量控制。当 Kubernetes 创建一个 Pod 时,它就会给这个 Pod 分配一个 QoS 等级。

QoS分类

  • Guaranteed:pod里的每一个container都同时设置了CPU和内存的requests和limits 而且值必须相等。(这类的pod是最高优先级)
  • Burstable:pod至少有一个container设置了cpu或内存的requests和limits,且不满足 Guarantee 等级的要求。即内存或CPU的值设置的不同。(中等优先级)
  • BestEffort:没有任何一个容器设置了requests或limits的属性。(最低优先级)

应用场景:当宿主机资源紧张的时候,kubelet会根据服务质量等级对pod进行eviction,即驱逐pod进行资源回收。

Requests和Limits资源配置特点

  • 如果Pod配置的Requests值等于Limits值,那么该Pod可以获得的资源是完全可靠的;
  • 如果Pod的Requests值小于Limits值,那么该Pod获得的资源可分成两部分;

完全可靠的资源,资源量的大小等于Requests值;
不可靠的资源,资源量最大等于Limits与 Requests的差额,这份不可靠的资源能够申请到多少,取决于当时主机上容器可用资源的余量;通过这种机制,Kubernetes可以实现节点资源的超售(Over Subscription),超售机制能有效提高资源的利用率,同时不会影响容器申请的完全可靠资源的可靠性。

调度策略的影响

  • Kubernetes的kubelet通过计算Pod中所有容器的Requests的总和来决定对Pod的调度;
  • 不管是CPU还是内存,Kubernetes调度器和kubelet都会确保节点上所有Pod的Requests的总和不会超过在该节点上可分配给容器使用的资源容量上限;

示例

https://www.cnblogs.com/wtzbk/p/15816291.html

Guaranteed样例

[root@k8s-m1 k8s-resource]# cat   guaranteed-pod.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: guaranteed-pod
  labels:
    name: nginx
spec:
  containers:
  - name: myapp
    image: nginx
    ports:
    - name: http
      containerPort: 80
    resources:
      requests:
        memory: "512Mi"
        cpu: "500m"
      limits:
        memory: "512Mi"
        cpu: "500m"
[root@k8s-m1 k8s-resource]# kubectl apply -f guaranteed-pod.yaml 
pod/guaranteed-pod created

结果:

[root@k8s-m1 k8s-resource]# kubectl describe po guaranteed-pod 
......
Volumes:
  default-token-glxls:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-glxls
    Optional:    false
QoS Class:       Guaranteed
Node-Selectors:  <none>
.....

更详细检查
1)查看该pod被分配到的节点

[root@k8s-m1 k8s-resource]# kubectl get pod -o wide
NAME                 READY   STATUS    RESTARTS   AGE     IP              NODE     NOMINATED NODE   READINESS GATES
guaranteed-pod       1/1     Running   0          8s      10.244.11.39    k8s-m3   <none>           <none>

2)然后到k8s-m3上去查看这个pod里面启动的容器的资源限制是否生效

[root@k8s-m3 ~]# docker ps |grep guaranteed
434a95e67849   nginx                                               "/docker-entrypoint.…"   6 minutes ago   Up 6 minutes             k8s_myapp_guaranteed-pod_default_7095c77a-7c31-4a0a-ba1c-c347c690cfe8_0
32a0053da67b   registry.aliyuncs.com/google_containers/pause:3.2   "/pause"                 6 minutes ago   Up 6 minutes             k8s_POD_guaranteed-pod_default_7095c77a-7c31-4a0a-ba1c-c347c690cfe8_0

#查看主容器的信息
[root@k8s-m3 ~]# docker inspect  434|egrep -i 'cpu|mem'
            "CpuShares": 512,
            "Memory": 536870912,
            "NanoCpus": 0,
            "CpuPeriod": 100000,
            "CpuQuota": 50000,
            "CpuRealtimePeriod": 0,
            "CpuRealtimeRuntime": 0,
            "CpusetCpus": "",
            "CpusetMems": "",
            "KernelMemory": 0,
            "KernelMemoryTCP": 0,
            "MemoryReservation": 0,
            "MemorySwap": 536870912,
            "MemorySwappiness": null,
            "CpuCount": 0,
            "CpuPercent": 0,
关注Memory、CpuPeriod、CpuQuota这三个值

3)通过cgroup的相关信息查看
从上面的结果实际上我们就可以看到这个容器的一些资源情况,Pod 上的资源配置最终也还是通过底层的容器运行时去控制 CGroup 来实现的,我们可以进入如下目录查看 CGroup 的配置,该目录就是 CGroup 父级目录,而 CGroup 是通过文件系统来进行资源限制的,所以我们上面限制容器的资源就可以在该目录下面反映出来:
##查看CPU的限制##

[root@k8s-m3 ~]# docker exec -it 434 /bin/bash
root@guaranteed-pod:/# cd /sys/fs/cgroup/cpu/
root@guaranteed-pod:/sys/fs/cgroup/cpu# cat cpu.cfs_period_us 
100000
root@guaranteed-pod:/sys/fs/cgroup/cpu# cat cpu.cfs_quota_us  
50000
root@guaranteed-pod:/sys/fs/cgroup/cpu# 
#反向计算出--cpus参数
#cpu.cfs_quota_us / cpu.cfs_period_us = cpu的限制
50000/100000=0.5核(也就是500m)

##查看内存的限制##
root@guaranteed-pod:/sys/fs/cgroup/cpu# cd /sys/fs/cgroup/memory/
root@guaranteed-pod:/sys/fs/cgroup/memory# cat memory.limit_in_bytes 
536870912
root@guaranteed-pod:/sys/fs/cgroup/memory# 

内存的计算方法为:536870912÷1024÷1024÷1024 = 0.5(G)

Burstable样例

[root@k8s-m1 k8s-resource]# cat  burstable-pod.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: burstable-pod
  labels:
    name: nginx
spec:
  containers:
  - name: myapp
    image: nginx
    ports:
    - name: http
      containerPort: 80
    resources:
      requests:
        memory: "256Mi"
        cpu: "200m"
      limits:
        memory: "512Mi"
        cpu: "500m"

[root@k8s-m1 k8s-resource]# kubectl apply  -f burstable-pod.yaml 
pod/burstable-pod created

结果:

[root@k8s-m1 k8s-resource]# kubectl describe po burstable-pod 
......
Volumes:
  default-token-glxls:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-glxls
    Optional:    false
QoS Class:       Burstable
Node-Selectors:  <none>
......

上面Burstable的示例中,可以看到limit和Request都设置了的,且limit大于Request。大家可以自行测试只设置其中一个的Qos等级。当只设置Request时,系统是不会补全limit的相关配置,也是Burstable。而当只设置limit时,系统会自动补全Request的相关配置和limit一样,Qos是Guaranteed类型。

BestEffort样例

[root@k8s-m1 k8s-resource]# cat  besteffort-pod.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: besteffort-pod
  labels:
    name: myapp
    tier: appfront
spec:
  containers:
  - name: http
    image: nginx
    ports:
    - name: http
      containerPort: 80

[root@k8s-m1 k8s-resource]# kubectl apply -f besteffort-pod.yaml 
kupod/besteffort-pod created

结果:

[root@k8s-m1 k8s-resource]# kubectl describe po besteffort-pod 
......
Volumes:
  default-token-glxls:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-glxls
    Optional:    false
QoS Class:       BestEffort
Node-Selectors:  <none>
.....

总结:
CPU是可以压缩资源,所以在CPU不够的时候会压缩限流。而内存是不可压缩资源,所以QoS主要用于内存限制。

  • BestEffort Pod的优先级最低,在这类Pod中运行的进程会在系统内存紧缺时被第一优先杀掉。当然,从另外一个角度来看,BestEffort Pod由于没有设置资源Limits,所以在资源充足时,它们可以充分使用所有的闲置资源;
  • Burstable Pod的优先级居中,这类Pod初始时会分配较少的可靠资源,但可以按需申请更多的资源。当然,如果整个系统内存紧缺,又没有BestEffort容器可以被杀掉以释放资源,那么这类Pod中的进程可能会被杀掉;
  • Guaranteed Pod的优先级最高,而且一般情况下这类Pod只要不超过其资源Limits的限制就不会被杀掉。当然,如果整个系统内存紧缺,又没有其他更低优先级的容器可以被杀掉以释放资源,那么这类Pod中的进程也可能会被杀掉;

OOM计分系统

【kubernetes系列】kubernetes之计算资源管理,Kubernetes,kubernetes
如果kubelet无法在系统OOM之前回收足够的内存,则oom_killer 会根据内存使用比率来计算oom._score, 将得出的结果和oom_score_adj相加,最后得分最高的Pod会被首先驱逐。这个策略的思路是,QoS最低且相对于调度的Request来说消耗最多内存的Pod会被首先清除,来保障内存的回收。这意味着与Burstable或Guaranteed QoS类别的容器相比,BestEffort这种类别的容器被杀死的可能性更高。
与Pod驱逐不同,如果一个Pod的容器被oom杀掉,是可能被 kubelet根据restartpolicy重启的。

容器中的JVM资源限制

在Kubernetes环境中部署Java程序不一会就重启了,这意味着你的pod是不健康的。然后我们可以通过describe去查看一下重启的原因。发现是因为Pod超出了资源限制被kill掉,在日志最后一行会出现一个kill的字段。为什么Kubernetes会kill掉,因为它超出了Kubernetes对Pod的资源限制。默认情况下Docker容器会使用宿主机所有的资源,但如果不做资源限制,会影响整个宿主机。然后整个宿主机资源不够会实现飘移,会转移到其他主机上,然后再异常,可能会起到一种雪崩的效应,所以一般我们都是要做Pod资源限制。如果Java容器中未设置JVM的-Xmx(最大的堆内存使用)参数,一旦这个Pod的使用内存超出Kubernetes的limits限制,Kubernetes就会把它杀掉并重启一个新的Pod。所以在实际使用中,JVM中的这个值建议要比limits要小一点,小个10%左右,因为超过这个limits限制就可能会被杀死掉再重新起一个Pod。

更多关于kubernetes的知识分享,请前往博客主页。编写过程中,难免出现差错,敬请指出文章来源地址https://www.toymoban.com/news/detail-583876.html

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

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

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

相关文章

  • (kubernetes)k8s常用资源管理

    目录 k8s常用资源管理 1、创建一个pod 1)创建yuml文件 2)创建容器 3)查看所有pod创建运行状态 4)查看指定pod资源 5)查看pod运行的详细信息 6)验证运行的pod 2、pod管理 1)删除pod 2)查看删除pod无法找到 3)创建pod 4)发现最先创建的pod运行在k8s-master节点上,下载镜像速度太

    2024年02月13日
    浏览(49)
  • 【Kubernetes资源篇】ConfigMap配置管理中心详解

    1、ConfigMap配置中心简介 官方中文参考文档: ConfigMap是API对象,用于存放明文(非机密性)数据保存到键值对中,可以使用环境变量、命令行参数或者存储卷方式应用到Pod中,ConfigMap相当于Pod中程序的配置文件,通过修改ConfigMap内容来修改程序的配置。 2、ConfigMap局限性 ConfigM

    2024年02月13日
    浏览(44)
  • 云原生Kubernetes:K8S配置资源管理

    目录 一、理论 1.Secret 2.Secret创建 3.Secret使用 4.Configmap 5.Configmap创建 6.Configmap使用 二、实验 1.Secret创建 2.Secret使用 3.Configmap创建 4.Configmap使用 三、问题 1.变量引用生成资源报错 2.查看pod日志失败 3.创建configmap报错 4.YAML创建configmap报错 5. 生成资源报错 6.文件挂载pod报错Error 四

    2024年02月07日
    浏览(68)
  • 【Kubernetes资源篇】StatefulSet无状态服务管理入门实战详解

    官方中文参考文档 1、StatefulSet Pod控制器特性 StatefulSet(简写sts)也是K8S集群中的一种Pod资源管理器,与deployment Pod控制器不同的是,StatefulSet用于管理无状态程序,特性如下: 稳定的网络标识符:管理的Pod都拥有一个稳定的网络标识符。可以通过网络标识符进行访问。 有序部署

    2024年02月13日
    浏览(38)
  • 在CSDN学Golang云原生(Kubernetes声明式资源管理Kustomize)

    在 Kubernetes 中,我们可以通过 YAML 或 JSON 文件来定义和创建各种资源对象,例如 Pod、Service、Deployment 等。下面是一个简单的 YAML 文件示例,用于创建一个 Nginx Pod: 该文件包含了以下信息: apiVersion :指定 Kubernetes API 的版本。 kind :指定资源类型,这里为 Pod。 metadata :定义

    2024年02月15日
    浏览(38)
  • yum部署kubernetes(k8s)集群、k8s常用资源管理

    目录 一、环境搭建 1、准备环境 1)计算机说明,建议系统版本7.4或者7.6 2)修改所有主机的计算机名设置host文件  2、安装master节点 1)安装etcd配置etcd 2)安装k8s-master节点 3)配置apiserver 4)配置controller和scheduler 5)启动k8s服务 3、安装k8s-master上的node 1)安装node 2)配置kube

    2024年02月13日
    浏览(64)
  • Kubernetes(K8s)与虚拟GPU(vGPU):实现高效管理和利用GPU资源的最佳实践

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

    2024年04月13日
    浏览(47)
  • K8S资源管理之计算资源管理

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

    2024年04月15日
    浏览(56)
  • 水资源管理:云计算在水资源管理中的优势

    水资源是人类生存和发展的基础,同时也是一个国家或地区的重要战略资源。随着人口增长、经济发展和工业化进程,水资源的紧缺和污染问题日益严重。为了有效地管理水资源,提高水资源利用效率,降低污染水体的成本,云计算技术在水资源管理领域发挥着重要作用。本

    2024年04月16日
    浏览(45)
  • 【kubernetes系列】Kubernetes之资源限制ResourceQuota

    当多个用户或团队共享具有固定节点数目的集群时,人们会担心有人使用超过其基于公平原则所分配到的资源量。我们可以通过ResourceQuota来解决这个问题,对每个namespace的资源消耗总量提供限制。它可以限制命名空间中某种类型的对象的总数目上限,也可以限制命名空间中的

    2024年02月16日
    浏览(44)

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

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

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

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

二维码1

领取红包

二维码2

领红包