5种方法让你知道Kubernetes集群的健康状况


Kubernetes是一种非常智能的技术,但如果操作不当反而弄巧成拙。正如大多数智能化技术一样,它的智能程度取决于操作者。为了建立成功的Kubernetes团队,了解Kubernetes的健康状况至关重要。这里有五种方法,可以让工程师很好的识别出集群的潜在健康风险。

幸运的是,有一些现成的技术可以用来收集Kubernetes集群的日志、各种指标数据、事件和安全威胁,以帮助监视集群的健康状况。这些收集器从Kubernetes集群的各个部分收集数据,然后对数据进行整合,从而生成可视化的高级视图,并实时了解资源利用率,发现错误的配置和其他问题。

为所有的Pod设置CPU的使用上下限

在Kubernetes集群中,Pod的调度机制依赖于requests和limits这两个参数。我们可以为CPU和内存设置requests和limits。对于CPU,它的单位是millicores,1000m等于一个CPU核。requests是你认为容器至少需要多少CPU和内存,而limits则是允许容器使用的实际上限。
requests_limits.png

确保为所有的Pod设置了CPU requests。最佳实践是将其设置为一个CPU核或更少,如果需要更多的计算能力,则添加额外的Pod副本。需要注意的是,如果你的CPU requests过高,比如2000m,但是你只有1个CPU核可用,那么这个Pod将永远不会被调度到Kubernetes集群中。在第5点中,我将向你展示如何检查未被调度的Pod。

确保为所有的Pod设置了CPU limits。如上所述,这个参数限制了Pod使用CPU的上限,因此Kubernetes将不允许Pod使用比limits中定义的更多的CPU。也就是说,CPU是比较宽容的,因为它被认为是一种可压缩资源。如果你的Pod达到了CPU limits,它不会被终止,而是被节流,因此可能会出现性能下降。

为所有的Pod设置内存的使用上下限

requests_limits_-_memory.png

确保为所有的Pod设置了memory requests:memory requests是你认为容器至少需要多少内存。像CPU一样,如果Pod的memory requests大于集群可以提供的内存,Kubernetes不会将Pod调度到Kubernetes集群中。

确保为所有的Pod设置了memory limits: memory limit是允许Pod使用内存的上限。与CPU不同,内存是不可压缩的,也不能进行节流。如果容器超过了它的内存限制,那么它将被终止。

审计资源配置

检查Kubernetes是否有不足或过剩的资源。如果Kubernetes集群中有剩余的可用CPU和内存,那么集群就处于消耗状态,并且消耗可能会持续增长。另一方面,如果CPU和内存的利用率接近100%,那么当集群需要水平扩展或有大量请求到来时,集群可能会遇到问题。

检查Pod的剩余容量,在Kubernetes中有一个指标数据“kube_node_status_allocatable”,这是Kubernetes在给定平均Pod资源利用率的情况下,对一个节点能容纳多少个Pod的估计。我们可以把剩余的Pod容量加起来,粗略地估计一下我们能在不遇到问题的情况下,集群还能扩大多少。
ramaining_Pod_capacity.png

检查CPU总百分比使用率,CPU requests百分比使用率,CPU limits百分比使用率:CPU总百分比使用率可以告诉你现在使用了多少。CPU requests百分比使用率可以告诉你应该需要多少。CPU limits百分比使用率限制了你可以使用多少。

在下面的例子中,我们只使用了可用计算能力的2.5%。我们的剩余资源过多。相比之下,我们定义的CPU requests是46%,所以我们认为Pod需要的比Pod实际使用的多得多。我们的预估不够准确。

最后,我们的CPU limits总和是37%。由于这低于我们的CPU requests,这是一个错误的配置,我们需要重新检查我们的CPU limits。
cpu_percent.png

检查内存的百分比使用率、memory requests百分比使用率,memory limits百分比使用率。就像CPU一样,查看是否有过多的剩余资源。只有3.8%的使用率告诉我们,我们确实资源过剩,但我们可以安全的进行水平扩展。
memory_percent.png

检查节点间的Pod分布

当我们查看Pod在集群中的分布情况时,我们希望得到一个大致均匀的分布。如果某些节点完全超载或负载不足,这可能是一个值得深入研究的问题。

以下是可能导致分布不均匀的一些事项:

Node affinity,亲和性是一种Pod设置,它使Pod更喜欢具有某些属性的节点。例如,Pod可能需要在附加了GPU或SSD的节点上运行,或者Pod可能需要具有特定安全隔离或策略的节点。检查亲和性设置可以帮助分析不均匀分布的原因,并减少可能出现的问题。

Taints and tolerations,污点是亲和性的反义词。Pod不太喜欢被分配到这些被“污染”的节点上。如果你希望为特定的Pod保留节点,或者确保该节点上的Pod可以完全访问可用资源,那么可以使用此方法。
Review_Pod_Distribution_Across_Nodes.png

Limits and requests,查看limit和request的设置。这常常是Pod分布不均匀的原因,因此值得在本节的三个部分中提及。如果Kubernetes调度程序没有Pod需要什么的正确信息,那么调度程序在调度方面就会做得很差。

检查Pod是否处于不良状态

在Kubernetes环境中,Pod的状态时刻在变化,所以过度关注每一个被终止的Pod将会慢慢吞噬你的时间和理智。但是,下面的列表值得你关注,以确保达到期望的集群状态。
Check_for_Pods_in_a_Bad_State.png

  • Nodes not ready:节点可能由许多原因而陷入这种状态,但通常是因为内存或磁盘空间不足。
  • Unscheduled pods:Pod通常以未调度状态结束,由于调度程序无法满足Pod所需要的CPU或内存请求。检查集群是否拥有足够的可用资源。
  • Pods that failed to create:Pod在创建时失败,这通常是由于在Pod的启动脚本中缺少某些依赖项之类的镜像导致的。在这种情况下,回到起点,反复检查Pod的各种参数配置。
  • Container restarts:一些容器重新启动不值得关注,但是看到很多这样的情况,可能意味着Pod处于OOMKill(内存耗尽)状态。内存不足是Kubernetes集群中最常见的错误之一,可能是由镜像问题、下游依赖项问题或各种意外、限制和请求问题引起的。


这些集群健康最佳实践可以限制Kubernetes集群出现意外情况,并确保集群在扩展时不会遇到问题。还为你提供了一个很好的起点,以帮助你回答那些无定形的问题,如“我的Kubernetes集群是否健康?” 如果所有这些检查点都是绿色的,那么你的集群可能处于健康状态,你可以高枕无忧了。

原文链接:Is Your Kubernetes Cluster Healthy? Here are 5 Ways to Find Out(翻译:钟涛)

0 个评论

要回复文章请先登录注册