点击上方 云原生CTO，选择设为星标
优质文章，每日送达
「【只做懂你de云原生干货知识共享】」
如何高效管理kubernetes节点资源
本教程适用于运维人员需掌握的核心技能，对于高效管理kubernetes节点资源是一个非常重要的技能，因为它涉及到你对kubernetes了解的多少，以及运维人员出现资源短缺的时候，你可以立刻解决它，另外它会对你工作产生高的效率，当你的k8s集群中出现大量驱逐你可以立刻作出回应，另外对于我们如何管理节点资源，下面我们去进一步了解它。
你可能已经知道，kubelet是Kubernetes中的主要节点组件，它执行许多关键任务。
kubelet负责：
用kube-apiserver注册节点 监视kube-apiserver中计划的Pod，并告诉容器运行时（例如Docker）在计划新的Pod之后启动容器 监视运行中的容器并将其状态报告给kube-apiserver 执行活动性探针并在容器失败后重新启动容器 运行由kubelet直接管理的静态Pod。 与Core Metrics Pipeline和容器运行时进行交互以收集容器和节点度量。
我们在本文中要讨论的另一个重要的kubelet任务是，当节点资源耗尽时，“主节点代理”具有驱逐Pods的能力。当磁盘，RAM或CPU等计算资源不足时，kubelet在维护节点稳定性方面起着至关重要的作用。对于Kubernetes管理员来说，了解配置资源外处理的最佳做法很有用，以使节点资源变得灵活，同时保留系统的整体容错性和关键系统进程的稳定性。
Kubelet如何确定资源不足？
如前所述，kubelet可以从节点上驱逐工作负载，以释放资源来处理其他Pod和/或系统任务，例如容器运行时或kubelet本身。但是，kubelet如何确定资源不足？
Kubelet根据收回信号和收回阈值确定何时回收资源。逐出信号是系统资源（如内存或存储器）的当前容量。反过来，逐出阈值是kubelet应该维护的此资源的最小值。
换句话说，每个驱逐信号都与某个驱逐阈值相关联，该阈值告诉kubelet何时开始回收资源。目前，支持以下驱逐信号：
memory.available —描述群集内存状态的信号。内存的默认逐出阈值为100Mi。换句话说，当内存下降到100 Mi时，kubelet开始逐出Pod。 nodefs.available—这nodefs是kubelet用于卷，守护程序日志等的文件系统。默认情况下，如果nodefs.available<10％，kubelet将开始回收节点资源。 nodefs.inodesFree—描述nodefs索引节点内存状态的信号。默认情况下，如果nodefs.inodesFree<5％，kubelet将开始逐出工作负载。 imagefs.available—imagefs文件系统是容器运行时使用的可选文件系统，用于存储容器镜像和容器可写层。默认情况下，如果imagefs.available<15％，kubelet将开始逐出工作负载。 imagefs.inodesFree— imagefs索引节点内存的状态。它没有默认驱逐阈值。
上述驱逐阈值是非常合理的默认值。但是，用户可以通过在kubelet二进制文件上设置适当的标志来配置其自定义逐出阈值。这些用户定义的阈值可以更改默认的kubelet逐出行为。
目前，Kubernetes支持硬驱逐和软驱逐阈值。如果达到硬驱逐阈值，则kubelet将立即开始回收资源，而没有任何宽限期。相反，软驱逐阈值包括用户定义的宽限期，该宽限期应在kubelet开始回收任何资源之前到期。
你可以使用--eviction-hardkubelet二进制文件上的标志定义硬驱逐阈值。例如，kubelet —- eviction-hard=memory.available<1Gi 当节点的memory.available大小低于1Gi时，将告诉kubelet开始回收资源。
如果要在驱逐之前允许宽限期，可以将—- eviction-soft标志与—-eviction-soft-grace-period标志结合使用。例如，kubelet —- eviction-soft=memory.available<2Gi并且kubelet —- eviction-soft-grace-period=1m30s将90秒的驱逐临界保持触发驱逐门槛前。
用户还可以通过设置—- eviction-max-pod-grace-period秒数来指定允许的最大宽限期。
Kubelet如何回收资源？
Kubelet以最终用户Pod的利益为代价来回收资源。它首先尝试将此类资源回收为未使用的容器镜像或失效的Pod。
如果节点imagefs与nodefs文件系统一起具有专用文件系统，则kubelet会以不同的方式回收节点资源。在这种情况下，如果nodefs达到驱逐阈值，则kubelet会删除所有已死亡的Pod及其容器。相应地，如果imagefs达到驱逐阈值，则kubelet会删除所有未使用的容器镜像。
如果未使用imagefs，则kubelet首先删除所有已失效的Pod及其容器，然后删除所有未使用的映像。有关这一过程的详细信息，请参阅本文从Kubernetes文档。
如果回收容器镜像，失效的Pod和其他资源没有导致资源匮乏，则kubelet会作为最后的选择开始删除最终用户Pod。kubelet根据Pod的QoS类，Pod优先级和下面讨论的许多其他参数来决定退出哪个最终用户Pod。在描述此过程之前，让我们回顾一下Kubernetes中的基本QoS类。
您可能已经从Kubernetes的先前教程中了解到，可以保证Podtable，Burstable或Best-Effort。
保证的Pod是在所有容器中为CPU和RAM设置资源限制和请求（可选）的Pod，它们相等。
易爆容器是指为一个或多个容器的一个或多个资源（例如CPU，RAM）设置请求和（可选）限制的容器，它们不相等。
尽力而为pod是未设置资源的pod。该QoS模型由kubelet在其Pod排序方案中隐式使用。通常，kubelet使用以下规则对驱逐候选人进行排名：
Pod是否已超出其资源请求。在Kubernetes中，Pod是根据其请求而不是限制进行调度的。因此，保证所有容器和Pod都具有它们所请求的RAM CPU数量。但是，如果未设置限制，并且Pod超出了其资源请求，则在保证Pod或某些系统任务需要受限资源的情况下，可以终止或限制该Pod。在某些情况下，甚至那些消耗少于要求量的Pod也会被杀死。例如，当系统任务内存严重不足并且没有较低优先级的Pod被杀死时。按Pod优先。如果没有Pod超出其请求，则kubelet会检查Pod Priority。它将尝试先驱逐优先级较低的Pod。注意：在Kubernetes 1.14中，pod的优先级和抢占级别已升级到GA。
从1.11开始默认启用它们。您可以在本文中了解有关Pod Priority的更多信息。
相对于Pods的资源请求消耗的饥饿计算资源（例如，RAM）。根据这些规则，kubelet会按以下顺序逐出最终用户Pod：
驱逐的第一个候选对象是尽力而为和/或易爆的Pod，其受限资源的使用超出了请求。如果有多个这样的Pod，则kubelet会按优先级对它们进行排序，然后将资源消耗按指定的请求排序。最后将收回资源低于要求的保证和可爆pod。但是，如果某些系统任务（如kubelet或Docker）需要饥饿的资源，并且节点上没有尽力而为Pod，则kubelet可以驱逐消耗量低于其请求量的保证Pod。在这种情况下，它将首先以最低优先级驱逐有保证和/或易爆的pod。
最低驱逐收回
如果kubelet回收的资源量很小，则系统可以反复达到驱逐阈值。这不是理想的行为，因为它可能导致不良的调度决策和Pods频繁驱逐。为了避免这种情况，用户可以使用—- eviction-minimum-reclaimkubelet二进制文件上的标志设置每个资源的最小回收级别。
例如，看下面的kubelet配置：
--eviction-hard=memory.available<1Gi,nodefs.available<2Gi,imagefs.available<200Gi
--eviction-minimum-reclaim=memory.available=0Mi,nodefs.available=1Gi,imagefs.available=2Gi
此 —- eviction-minimum-reclaim设置确保nodefs回收后的最小imagefs可用存储量为3Gi，最小可用存储量为202 Gi。因此，以上配置可确保系统具有足够的可用资源，以避免非常频繁地达到收回阈值。
糟糕的资源不足处理配置可能会遇到的另一个潜在问题是节点条件的波动。当kubelet收到逐出信号时，后者会映射到相应的节点条件。例如，当达到memory.available逐出阈值时，kubelet将MemoryPressure节点条件分配给该节点。此条件与相应的污点关联，该污点可防止在具有MemoryPressure节点条件的节点上调度新Pod 。您可以在我们之前的文章中找到有关节点条件的更多信息。
但是，如果您使用具有较长宽限期的软驱逐阈值，则节点条件会在宽限期之间true和false之内振荡。这可能导致搬迁不确定性，因此，调度计划不佳。为了避免这种情况，您可以—- eviction-pressure-transition-period在kubelet上使用标志，该标志定义kubelet在满足驱逐条件之前必须等待多长时间。
一个简单的资源短缺处理方案
现在，我们将说明如何为K8s集群配置资源不足的处理。让我们想象一个简单的场景，其中仅考虑节点RAM。假设我们节点的内存容量为10 Gi RAM。我们想为系统守护进程（例如内核，kubelet，Docker等）保留总内存的10％。我们还希望以95％的内存利用率驱逐Pod。
使用默认逐出阈值启动kubelet，并且没有系统保留集。我们需要在kubelet上显式设置几个标志，以启用所需的行为。
为了实现我们的目标，我们需要在kubelet上设置以下标志：
eviction-hard=memory.available<500Mi
system-reserved=memory=1.5Gi
如您所见，system-reserved虽然直观上应该将其设置为1.5Gi，但应将其设置为10％= 1Gi。但是，“系统保留”应包括驱逐阈值（1Gi + .5Gi）覆盖的内存量。
根据配置K8s集群的方式，可以不同地设置kubelet标志。例如，如果计划使用Kops设置K8s集群，请运行kops edit cluster $NAME以使用集群配置打开编辑器。如果是VI编辑器，则按“ I”进入插入模式以编辑文件。上述资源不足处理策略的kubelet标志应如下所示：
kubelet:
eviction-hard=memory.available<500Mi
system-reserved=memory=1.5Gi
结论
在本教程中，我们讨论了一些有用的Kubernetes管理实践，用于在Kubernetes中自定义kubelet资源外管理。该平台允许管理员设置自定义驱逐阈值和驱逐宽限期，以决定哪些条件被视为对节点稳定性有害。但是，有了这种自由，就要承担很多责任。Kubernetes附带了合理的资源短缺管理默认设置。因此，在将驱逐阈值设置得太高或将驱逐宽限期设置得太长时，您应保持谨慎。
参考地址：https://supergiant.io/blog/efficient-node-out-of-resource-management-in-kubernetes/
我是个沉默不语的靠着车窗想念你的乘客, 当107路再次经过 时间是带走青春的电车 「——鼓楼 赵雷」。
【一个懂你的云原生知识共享平台】
「欢迎扫描下方二维码关注」
