Kubernetes

Kubernetes计算资源管理

本文主要是介绍Kubernetes计算资源管理,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!

在Almatar,与Kubernetes(k8s)进行了大规模合作,在极少数情况下,我们的某些服务遇到意外行为,导致我们提出了很少的问题,以使事情变得更加稳定和可靠。 其中之一是当一个Pod停止运行时该怎么办,因为k8无法满足特定节点上该Pod所需的资源(就内存和CPU而言),我们是否应该在这种情况下重新启动Pod? 有没有更聪明的方法来管理资源分配? 让我们看看我们如何遇到这种情况以及如何更好地控制它。

Kubernetes,大图景Kubernetes计算资源管理

> Image from Dzone

在容器化的世界中,Kubernetes在其控制平面中又有多个组件,即一个主节点,其中之一就是kube-scheduler。 是组件/流程,负责监视集群中的Pod,将工作负载分配给相应的节点,以及跟踪每台正在运行的主机上的资源利用率,以使工作负载与可用资源匹配。

资源限制是Kubernetes用于获取信息的信息的参数,该信息是Pod正常运行所需的资源是什么以及Pod可以利用的最大允许资源是多少。

调度程序还负责根据计算资源利用率(内存/ CPU)与可用节点匹配容器需求,即:对于需要X内存和Y CPU的新创建的Pod,调度程序将确保分配容器。 装到可以处理分配给它的工作负载的节点上,否则会发生什么? 默认的k8s分配没有针对内存/ CPU的强制资源限制,因此,容器可以与同一个节点中的其他Pod一起使用尽可能多的资源,从而相互影响,可能会出现拥塞状态。

负载测试背景Kubernetes计算资源管理

> Photo by Thomas Kelley on Unsplash

在发布我们的航班产品之前,我们开始使用Apache JMeter进行一些负载测试,并通过Grafana收集少量指标,以确保在高流量期间一切稳定。

如果容器超出了其允许的内存限制(在我们的情况下为无限制),则kubelet(在每个节点上运行的守护程序)将开始采取措施以重启有问题的Pod(如果可能的话),否则,如果其超出了请求的内存(在我们的情况下) 它也处于打开状态),如果Pod导致节点内存不足(或基于内核发出信号的方式杀死了oom),则该Pod将被驱除,或者同一节点中的其他Pod也可能被驱逐,从而导致更多混乱和 这些服务不稳定,会间歇性停止运行。

在此阶段,一切可能仍然很好,Kubernetes将重新启动Pod,Linux内核将回收一些空间,然后调度程序将Pod重新调整到其他节点(请记住,尚无分配策略),但是我们仍然有风险 在其他节点上再次发生相同的行为。 我们需要根据每个服务的当前消耗率对Kubernetes进行检测,以便在当前基础架构下可以做出更好的分配决策。

K8中的这些请求/限制是什么?

在kube-scheduler决定在哪个节点上放置容器/容器之后,重要的是容器具有可在该节点上运行的足够资源,这是kubelet守护程序在每个负责节点运行状况的节点上运行的角色。 豆荚。 例如,如果您的应用程序需要8 GB的内存(RAM),而主机上允许的最大容量为<8 GB,则将导致该文凭节点内存不足,并且一切将停止工作。 设置这些需求很重要,这样调度程序才能在放置步骤中做出更好的决策。 但是这些指标如何设置以及设置什么?

请求(例如:8 GB内存,0.1 CPU):告诉Kubernetes仅在具有这些资源可用的节点上分配容器。

限制(例如:10 GB内存,0.2 CPU):告诉Kubernetes调度程序在消耗资源时不要让Pod超过这些阈值(达到这些限制然后限制它)。

spec:

containers:

- image: php

imagePullPolicy: IfNotPresent

name: flights-x-service

ports:

- containerPort: 80

protocol: TCP

resources:

limits:

cpu: 800m

memory: 2000Mi

requests:

cpu: 700m

memory: 1000Mi

简而言之,上面的示例描述了一个Pod的部署,其中包含一个正在运行的PHP映像容器,并按以下方式指定了请求:

· 要求cpu:700m(以毫米为单位)

· 请求内存:1000Mi(以兆字节为单位)

· 限制cpu:800m(最高可达800毫米)

· 限制内存:2000Mi(最多可占用2000兆字节)

调度程序将首先尝试找到一个可以处理请求阈值的节点(如果找到了该节点,则将其分配给它),但是如果找不到节点会发生什么呢? 如果这些请求阈值太高或运行时超出了这些限制,该怎么办?

· 如果请求值设置得太高,则调度程序将无法在任何节点上调度Pod并挂起。 查看命名空间中引发的事件,我们将看到原因:

$ kubectl get events | grep flights-x-serviceWarning FailedScheduling0/x nodes are available:x Insufficient memory, y Insufficient cpu.

· 对于在运行时Pod超出其内存/ cpu限制的其他情况,kubernetes的行为会有所不同,具体取决于哪种资源类型。 CPU资源是可压缩的,这意味着kubernetes将在CPU达到其极限时对其进行压缩,但不会终止pod,从而导致应用程序性能下降。 另一方面,内存是不可压缩的(无法像cpu一样限制内存),如果内存超出了允许的配额,则pod将终止。

还有其他更深入的文章,讨论kubelet如何处理资源不足的情况

如何定义请求限制阈值(上限)?

在开始时,我们主要采用一种实验方法来在进行负载测试时跟踪资源利用率,然后,我们可以使用分析/监控工具来跟踪Pod的使用情况,并在需要时调整阈值以防止利用率过高或不足 在资源中,结果称为"上限"或简称为" Ulimits":

· 如果我们能够在短时间窗口内模拟成千上万的用户访问平台的行为,那么我们可以对集群中的资源分配进行一些粗略的估算;如果它是一个简单的API,我们可以使用loader.io之类的东西或构建 使用Apache JMeter进行一些更复杂的流程,然后使用kubescope-cli或与Kubernetes集成的任何其他分析/监视工具(如Grafana)监视每个pod上的资源利用率。

Kubernetes计算资源管理

> kubescope-cli

Kubernetes计算资源管理

> grafana

2.一旦记录了已使用的内存/ CPU,就可以开始按其类型对Pod利用率进行分类,还记得我们要回答的下一个问题是:如果我们有一个新的服务部署,那么应该为其分配什么资源阈值? ,贪婪的方法主要有以下三类:

· 高流量:在阿拉木图,这些是沿用户操作(例如搜索,产品选择等)的关键路径的请求的主要消费者。

· 中流量:可能是按概率命中的服务,即:由另一个缓存层支持的服务,该缓存层并未在每个繁忙流量的请求路径上使用。

· 低流量:可能是受到攻击的可能性很小,例如:拥有一些通过某些API为航班/酒店提供静态数据的服务,这些服务可用于将信息植入其他层,例如Elastic Search, 这些甚至在其请求期间也不需要大量消耗。

3.除了上述存储桶之外,其他Pod可以构成其他类别,例如数据库存储,例如,如果一个Pod用于mongodb,则Mongodb的u限制有一个额外的层,例如:docs.mongodb/ manual / reference / ulimit /引用了有关文件大小,内存分配,堆栈大小等的更详细的限制级别。

4.对于请求的任何新服务,默认部署文件应考虑根据服务所属的类别设置一些默认限制。 以后,可以根据需要调整这些限制,重新设计请求的关键路径,等等。

最后的想法

· 可以在名称空间级别上设置一些资源配额,它控制同一名称空间中所有Pod的聚合资源消耗。 可以创建具有不同分类的ResourceQuota Kubernetes对象(将其视为标签),为每个标签设置一些内存/ cpu阈值,然后为每个创建的Pod指定一个标签以引用ResourceQuota对象中定义的资源阈值, 例如:高流量客舱,低流量客舱,等等。

· 生产负载测试可能很棘手,我们需要在非高峰时间在生产环境中连续运行这些定期测试,同时确保不会耗尽资源,从而导致其他服务的停机,设置u-limits非常重要 在进入这个阶段之前。

· 本文介绍了对k8s Pod设置ulimit的重要性,请求和限制如何不同以及Kubernetes在这些阈值方面的行为的基本理解。 可以采用许多其他方法来完善这些阈值,更好地控制(不仅是容器)持久性卷,存储请求等。

这篇关于Kubernetes计算资源管理的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!