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

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

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

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

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

确保为所有的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设置内存的使用上下限

确保为所有的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容量加起来,粗略地估计一下我们能在不遇到问题的情况下,集群还能扩大多少。

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

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

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

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

检查节点间的Pod分布

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

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

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

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

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

检查Pod是否处于不良状态

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

  • Nodes not ready:节点可能由许多原因而陷入这种状态,但通常是因为内存或磁盘空间不足。
  • Unscheduled pods:Pod通常以未调度状态结束,由于调度程序无法满足Pod所需要的CPU或内存请求。检查集群是否拥有足够的可用资源。
  • Pods that failed to create:Pod在创建时失败,这通常是由于在Pod的启动脚本中缺少某些依赖项之类的镜像导致的。在这种情况下,回到起点,反复检查Pod的各种参数配置。

Container restarts:一些容器重新启动不值得关注,但是看到很多这样的情况,可能意味着Pod处于OOMKill(内存耗尽)状态。内存不足是Kubernetes集群中最常见的错误之一,可能是由镜像问题、下游依赖项问题或各种意外、限制和请求问题引起的。

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

 

责任编辑:未丽燕 来源: Dockone.io
相关推荐

2022-06-28 13:25:19

K8sPrometheusGrafana

2022-08-09 09:10:43

Kubernetes容器

2022-06-27 19:16:12

KubernetesK8s 集群

2022-07-18 14:45:22

Kubernetes暴露方案

2022-07-11 09:46:43

Kubernetes开源Linux

2022-01-12 11:55:43

2020-04-02 15:10:57

Kubernetes集群安全

2022-01-03 07:49:04

2020-08-04 07:58:36

Kubernetes集群工具

2021-06-01 08:00:43

KubernetesCentOS版集群

2015-07-17 10:25:43

kubernetesDocker集群系统

2021-05-12 10:59:39

Kubernetes容器集群

2019-07-29 08:03:20

Kubernetes集群服务架构

2021-02-18 09:28:32

Kubernetes开源SaaS

2022-02-25 11:51:11

KubeScrape开源监控工具

2022-02-23 09:00:00

Kubernetes集群容器

2021-07-27 11:31:29

2021-09-08 10:05:17

2022-05-07 08:23:57

KubernetesDockershim

2014-12-24 09:35:29

同话题下的热门内容

虚拟电厂调度国际竞赛:阿里达摩院求解器获冠军风险日益严峻,容器云平台如何做好安全隔离?云计算下半场:谁主沉浮?2022年五大云虚拟化趋势什么是 NetDevOps,它如何帮助 IT 实现业务目标?IDC:中国视频云市场,阿里云连续四年稳居第一服务网格到底能做哪些事?使用公共云时,要在安全和合规方面考虑这些……

编辑推荐

一文让你看懂IaaS、PaaS和SaaS看完小白也能懂什么是公有云、私有云、混合云陌陌基于K8s和Docker容器管理平台的架构实践科技公司创始人谈MySQL的未来AWS公布AWS媒体服务家族,专为完整视频工作流提供支持
我收藏的内容
点赞
收藏

51CTO技术栈公众号