前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
社区首页 >专栏 >kubernetes 中 Evicted pod 是如何产生的

kubernetes 中 Evicted pod 是如何产生的

作者头像
田飞雨
发布于 2021-10-08 07:01:26
发布于 2021-10-08 07:01:26
5.4K00
代码可运行
举报
文章被收录于专栏:田飞雨的专栏田飞雨的专栏
运行总次数:0
代码可运行

线上被驱逐实例数据

最近在线上发现很多实例处于 Evicted 状态,通过 pod yaml 可以看到实例是因为节点资源不足被驱逐,但是这些实例并没有被自动清理,平台的大部分用户在操作时看到服务下面出现 Evicted 实例时会以为服务有问题或者平台有问题的错觉,影响了用户的体验。而这部分 Evicted 状态的 Pod 在底层关联的容器其实已经被销毁了,对用户的服务也不会产生什么影响,也就是说只有一个 Pod 空壳在 k8s 中保存着,但需要人为手动清理。本文会分析为什么为产生 Evicted 实例、为什么 Evicted 实例没有被自动清理以及如何进行自动清理。

kubernetes 版本:v1.17

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
$ kubectl get pod | grep -i Evicted
cloud-1023955-84421-49604-5-deploy-c-7748f8fd8-hjqsh        0/1     Evicted   0          73d
cloud-1023955-84421-49604-5-deploy-c-7748f8fd8-mzd8x        0/1     Evicted   0          81d
cloud-1237162-276467-199844-2-deploy-7bdc7c98b6-26r2r       0/1     Evicted   0          18d

Evicted 实例状态:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
status:
  message: 'Pod The node had condition: [DiskPressure]. '
  phase: Failed
  reason: Evicted
  startTime: "2021-09-14T10:42:32Z"

实例被驱逐的原因

kubelet 默认会配置节点资源不足时驱逐实例的策略,当节点资源不足时 k8s 会停止该节点上实例并在其他节点启动新实例,在某些情况下也可通过配置 --eviction-hard= 参数为空来禁用驱逐策略,在之前的生产环境中我们也确实这么做了。

节点资源不足导致实例被驱逐

k8s 中产生 Evicted 状态实例主要是因为节点资源不足实例主动被驱逐导致的,kubelet eviction_manager 模块会定期检查节点内存使用率、inode 使用率、磁盘使用率、pid 等资源,根据 kubelet 的配置当使用率达到一定阈值后会先回收可以回收的资源,若回收后资源使用率依然超过阈值则进行驱逐实例操作。

Eviction Signal

Description

memory.available

memory.available := node.status.capacity[memory] - node.stats.memory.workingSet

nodefs.available

nodefs.available := node.stats.fs.available

nodefs.inodesFree

nodefs.inodesFree := node.stats.fs.inodesFree

imagefs.available

imagefs.available := node.stats.runtime.imagefs.available

imagefs.inodesFree

imagefs.inodesFree := node.stats.runtime.imagefs.inodesFree

pid.available

pid.available := node.stats.rlimit.maxpid - node.stats.rlimit.curproc

kubelet 中 pod 的 stats 数据一部分是通过 cAdvisor 接口获取到的,一部分是通过 CRI runtimes 的接口获取到的。

memory.available:当前节点可用内存,计算方式为 cgroup memory 子系统中 memory.usage_in_bytes 中的值减去 memory.stat 中 total_inactive_file 的值; nodefs.available:nodefs 包含 kubelet 配置中 --root-dir 指定的文件分区和 /var/lib/kubelet/ 所在的分区磁盘使用率; nodefs.inodesFree:nodefs.available 分区的 inode 使用率; imagefs.available:镜像所在分区磁盘使用率; imagefs.inodesFree:镜像所在分区磁盘inode使用率; pid.available:/proc/sys/kernel/pid_max 中的值为系统最大可用 pid 数;

kubelet 可以通过参数 --eviction-hard 来配置以上几个参数的阈值,该参数默认值为 imagefs.available<15%,memory.available<100Mi,nodefs.available<10%,nodefs.inodesFree<5%,当达到阈值时会驱逐节点上的容器。

kubelet 驱逐实例时与资源处理相关的已知问题

1、kubelet 不会实时感知到节点内存数据的变化

kubelet 定期通过 cadvisor 接口采集节点内存使用数据,当节点短时间内内存使用率突增,此时 kubelet 无法感知到也不会有 MemoryPressure 相关事件,但依然会调用 OOMKiller 停止容器。可以通过为 kubelet 配置 --kernel-memcg-notification 参数启用 memcg api,当触发memory 使用率阈值时 memcg 会主动进行通知;

memcg 主动通知的功能是 cgroup 中已有的,kubelet 会在 /sys/fs/cgroup/memory/cgroup.event_control 文件中写入 memory.available 的阈值,而阈值与 inactive_file 文件的大小有关系,kubelet 也会定期更新阈值,当 memcg 使用率达到配置的阈值后会主动通知 kubelet,kubelet 通过 epoll 机制来接收通知。

2、kubelet memory.available 不会计算 active page

kubelet 通过内存使用率驱逐实例时,内存使用率数据包含了 page cache 中 active_file 的数据,在某些场景下会因 page cache 过高导致内存使用率超过阈值会造成实例被驱逐,

由于在内存紧张时 inactive_file 会被内核首先回收,但在内存不足时,active_file 也会被内核进行回收,社区对此机制也有一些疑问,针对内核回收内存的情况比较复杂,社区暂时还未进行回应,详情可以参考 kubelet counts active page cache against memory.available (maybe it shouldn’t?)

kubelet 计算节点可用内存的方式如下:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
#!/bin/bash
#!/usr/bin/env bash

# This script reproduces what the kubelet does
# to calculate memory.available relative to root cgroup.

# current memory usage
memory_capacity_in_kb=$(cat /proc/meminfo | grep MemTotal | awk '{print $2}')
memory_capacity_in_bytes=$((memory_capacity_in_kb * 1024))
memory_usage_in_bytes=$(cat /sys/fs/cgroup/memory/memory.usage_in_bytes)
memory_total_inactive_file=$(cat /sys/fs/cgroup/memory/memory.stat | grep total_inactive_file | awk '{print $2}')

memory_working_set=${memory_usage_in_bytes}
if [ "$memory_working_set" -lt "$memory_total_inactive_file" ];
then
    memory_working_set=0
else
    memory_working_set=$((memory_usage_in_bytes - memory_total_inactive_file))
fi

memory_available_in_bytes=$((memory_capacity_in_bytes - memory_working_set))
memory_available_in_kb=$((memory_available_in_bytes / 1024))
memory_available_in_mb=$((memory_available_in_kb / 1024))

echo "memory.capacity_in_bytes $memory_capacity_in_bytes"
echo "memory.usage_in_bytes $memory_usage_in_bytes"
echo "memory.total_inactive_file $memory_total_inactive_file"
echo "memory.working_set $memory_working_set"
echo "memory.available_in_bytes $memory_available_in_bytes"
echo "memory.available_in_kb $memory_available_in_kb"
echo "memory.available_in_mb $memory_available_in_mb"

驱逐实例未被删除原因分析

源码中对于 Statefulset 和 DaemonSet 会自动删除 Evicted 实例,但是对于 Deployment 不会自动删除。阅读了部分官方文档以及 issue,暂未找到官方对 Deployment Evicted 实例未删除原因给出解释。

statefulset: pkg/controller/statefulset/stateful_set_control.go

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
// Examine each replica with respect to its ordinal
for i := range replicas {
    // delete and recreate failed pods
    if isFailed(replicas[i]) {
        ssc.recorder.Eventf(set, v1.EventTypeWarning, "RecreatingFailedPod",
            "StatefulSet %s/%s is recreating failed Pod %s",
            set.Namespace,
            set.Name,
            replicas[i].Name)
        if err := ssc.podControl.DeleteStatefulPod(set, replicas[i]); err != nil {
            return &status, err
        }
        if getPodRevision(replicas[i]) == currentRevision.Name {
            status.CurrentReplicas--
        }
        if getPodRevision(replicas[i]) == updateRevision.Name {
            status.UpdatedReplicas--
        }
        ......

daemonset: pkg/controller/daemon/daemon_controller.go

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
func (dsc *DaemonSetsController) podsShouldBeOnNode(
		......
) (nodesNeedingDaemonPods, podsToDelete []string) {

		......

    switch {
		......
    case shouldContinueRunning:
				......
        for _, pod := range daemonPods {
            if pod.DeletionTimestamp != nil {
                continue
            }
            if pod.Status.Phase == v1.PodFailed {
                // This is a critical place where DS is often fighting with kubelet that rejects pods.
                // We need to avoid hot looping and backoff.
                backoffKey := failedPodsBackoffKey(ds, node.Name)
                ......

解决方案

1、团队里面有了一套 k8s 集群事件采集的链路,我们通过消费 k8s 中 pod 的相关事件来进行处理,消费事件时过滤 pod 中与 Evicted 实例相关的事件然后处理即可。

Evicted 实例判断逻辑:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
const (
	podEvictedStatus = "Evicted"
)

// 判断如果为 Evicted 状态的实例且 Pod 中容器数为 0 时直接删除 pod
if strings.ToLower(status) == strings.ToLower(podEvictedStatus) && len(pod.Status.ContainerStatuses) == 0 {
	
}

2、社区有人提供通过在 kube-controller-manager 中配置 podgc controller –terminated-pod-gc-threshold 参数来自动清理:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
Podgc controller flags:

      --terminated-pod-gc-threshold int32
                Number of terminated pods that can exist before the terminated pod garbage collector starts deleting terminated pods. If
                <= 0, the terminated pod garbage collector is disabled. (default 12500)

该参数配置的是保留的异常实例数,默认值为 12500,但 podgc controller 回收 pod 时使用强杀模式不支持实例的优雅退出,因此暂不考虑使用。

3、其他处理方式可以参考社区中提供的 Kubelet does not delete evicted pods

总结

由于在之前的公司中对于稳定性的高度重视,线上节点并未开启驱逐实例的功能,因此也不会存在 Evicted 状态的实例,当节点资源严重不足时会有告警人工介入处理,以及还会有二次调度、故障自愈等一些辅助处理措施。本次针对 Evicted 相关实例的分析,发现 k8s 与操作系统之间存在了很多联系,如果要彻底搞清楚某些机制需要对操作系统的一些原理有一定的了解。

参考: https://github.com/kubernetes/kubernetes/issues/55051 https://ieevee.com/tech/2019/05/23/ephemeral-storage.html https://github.com/kubernetes/kubernetes/issues/43916 https://kubernetes.io/docs/concepts/scheduling-eviction/node-pressure-eviction/

本文参与 腾讯云自媒体同步曝光计划,分享自作者个人站点/博客。
原始发表:2021-03-01,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
暂无评论
推荐阅读
编辑精选文章
换一批
Kubernetes 中 Evicted pod 是如何产生的
最近在线上发现很多实例处于 Evicted 状态,通过 pod yaml 可以看到实例是因为节点资源不足被驱逐,但是这些实例并没有被自动清理,平台的大部分用户在操作时看到服务下面出现 Evicted 实例时会以为服务有问题或者平台有问题的错觉,影响了用户的体验。而这部分 Evicted 状态的 Pod 在底层关联的容器其实已经被销毁了,对用户的服务也不会产生什么影响,也就是说只有一个 Pod 空壳在 k8s 中保存着,但需要人为手动清理。本文会分析为什么为产生 Evicted 实例、为什么 Evicted 实例没有被自动清理以及如何进行自动清理。
米开朗基杨
2021/10/18
1K0
Kubernetes 中 Evicted pod 是如何产生的
kubernetes-pod驱逐机制
kubelet持续监控主机的资源使用情况,并尽量防止计算资源被耗尽。一旦出现资源紧缺的迹象,kubelet就会主动终止部分pod的运行,以回收资源。
yaohong
2020/07/05
1.4K0
Kubernetes Eviction Manager工作机制分析
研究过Kubernetes Resource QoS的同学,肯定会有一个疑问:QoS中会通过Pod QoS和OOM Killer进行资源的回收,当发生资源紧缺的时候。那为什么Kubernetes会再搞一个Kubelet Eviction机制,来做几乎同样的事呢? 首先,我们来谈一下kubelet通过OOM Killer来回收资源的缺点: System OOM events本来就是对资源敏感的,它会stall这个Node直到完成了OOM Killing Process。 当OOM Killer干掉某些cont
Walton
2018/04/16
2K0
Kubernetes Eviction Manager工作机制分析
浅析 Kubelet 驱逐机制
Kubelet 出于对节点的保护,允许在节点资源不足的情况下,开启对节点上 Pod 进行驱逐的功能。最近对 Kubelet 的驱逐机制有所研究,发现其中有很多值得学习的地方,总结下来和大家分享。
CS实验室
2021/09/24
1.6K0
kubernetes 组件之 kubelet
每个Node节点上都运行一个 Kubelet 服务进程,默认监听 10250 端口,接收并执行 Master 发来的指令,管理 Pod 及 Pod 中的容器。每个 Kubelet 进程会在 API Server 上注册所在Node节点的信息,定期向 Master 节点汇报该节点的资源使用情况,并通过 cAdvisor 监控节点和容器的资源。
看、未来
2022/06/05
7690
kubernetes 组件之 kubelet
Kubernetes Pod Evicted[通俗易懂]
近日 Kubernetes 测试集群 Pod 状态出现 Evicted 现象 , 但是项目还是能正常提供服务 , 最先的解决办法是手动将 Evicted 状态的 Pod 删除。
全栈程序员站长
2022/08/30
1.1K0
Kubernetes节点的驱逐与预留
K8S 的节点上的资源会被 pod 和系统进程所使用,如果默认什么都不配置,那么节点上的全部资源都是可以分配给pod使用的,系统进程本身没有保障,这样做很危险:
极客运维圈
2020/07/20
3.1K0
Kubernetes节点的驱逐与预留
TKE节点磁盘空间不足导致pod被驱逐问题
最近遇到了一个问题,TKE控制台出现了大量的failed状态的pod,查看了事件并没有明显的异常报错,这里到底是怎么回事呢?
聂伟星
2021/05/31
3.1K0
谈谈K8S Pod Eviction 机制
Pod Eviction 是k8s一个特色功能,它在某些场景下应用,如节点NotReady、Node节点资源不足,把pod驱逐至其它Node节点。
YP小站
2020/06/04
5.1K0
Kubernetes(k8s)-服务质量(QoS)
作者介绍:简历上没有一个精通的运维工程师。请点击上方的蓝色《运维小路》关注我,下面的思维导图也是预计更新的内容和当前进度(不定时更新)。
运维小路
2025/02/19
1150
Kubernetes(k8s)-服务质量(QoS)
【重识云原生】第六章容器6.3.6节——kubelet组件
        Kubelet组件运行在Node节点上,维持运行中的Pods以及提供kuberntes运行时环境,其主要功能就是定时从某个地方获取节点上 pod/container 的期望状态(运行什么容器、运行的副本数量、网络或者存储如何配置等等),并调用对应的容器平台接口达到这个状态。
江中散人_Jun
2022/10/04
1.1K0
【重识云原生】第六章容器6.3.6节——kubelet组件
Kubernetes Node资源预留
Kubernetes 的节点可以按照 Capacity 调度。默认情况下 pod 能够使用节点全部可用容量。这是个问题,因为节点自己通常运行了不少驱动 OS 和 Kubernetes 的系统守护进程(system daemons)。除非为这些系统守护进程留出资源,否则它们将与 pod 争夺资源并导致节点资源短缺问题。
YP小站
2020/06/04
3.5K0
Kubernetes Node资源预留
kubernetes是怎么做资源管理的?
在Kubernetes中,Pod是最小的调度单元,所以跟资源和调度相关的属性都是Pod对象的字段,而其中最重要的就是CPU和内存。如下所示:
极客运维圈
2020/03/23
6740
kubernetes调度之资源耗尽处理方案
当可用的计算机资源非常低的时候,kubelet仍然要保证节点的稳定性.当处理不可压缩的计算机资源(比如内存或磁盘空间)时,这尤其重要,当这些资源被耗尽时,节点将变得不稳定
kubernetes中文社区
2019/06/24
1.2K0
kubelet最佳配置
author: garnett.wang@gmail.com kubernetes version: 1.6.2 Kubelet Configurations We Should Care About 下面是我梳理的,我认为必须关注的flag。 flagvalue --address0.0.0.0 --allow-privilegedfalse --cadvisor-port int324194 --cgroup-driver stringcgroupfs --cluster-dns stringS
Walton
2018/04/16
2.5K0
Kubernetes节点资源耗尽状态的处理
最近发现测试环境的k8s集群,总有node利用不上,pod漂移过去之后,启动不了,故仔细排查了一下缘由!
SY小站
2020/06/15
1.4K0
kubernetes应用资源管理
Kubernetes针对不同服务质量的预期,通过QoS(Quality of Service)来对pod进行服务质量管理,提供了个采用requests和limits两种类型对资源进行分配和使用限制。对于一个pod来说,服务质量体现在两个为2个具体的指标:CPU与内存。实际过程中,当NODE节点上内存资源紧张时,kubernetes会根据预先设置的不同QoS类别进行相应处理。
heidsoft
2022/01/17
8370
kubernetes应用资源管理
K8s驱逐策略
周期性检查节点状态,每当节点状态为 NotReady,并且超出 podEvictionTimeout 时间后,就把该节点上的 pod 全部驱逐到其它节点,其中具体驱逐速度还受驱逐速度参数,集群大小等的影响。
黄啊码
2022/06/20
1.2K0
8.深入k8s:资源控制Qos和eviction及其源码分析
又是一个周末,可以愉快的坐下来静静的品味一段源码,这一篇涉及到资源的回收,工作量是很大的,篇幅会比较长,我们可以看到k8s在资源不够时会怎么做的,k8s在回收资源的时候有哪些考虑,我们的pod为什么会无端端的被干掉等等。
luozhiyun
2020/09/01
1.1K0
8.深入k8s:资源控制Qos和eviction及其源码分析
关于Kubernetes image垃圾镜像容器的回收
早些时候kubernetes集群的cri还使用docker的时候经历过这样的状况: 集群运行很久后硬盘跑的快满了......,大文件主要集中在:/var/lib/docker/overlay2 下文件有快70G,/var/log/journal/日志也有4-5G。当时的操作是手工的在work节点进行了一下的操作:
对你无可奈何
2021/09/22
5.8K1
相关推荐
Kubernetes 中 Evicted pod 是如何产生的
更多 >
领券
社区富文本编辑器全新改版!诚邀体验~
全新交互,全新视觉,新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能,全面提升创作效率和体验
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档
查看详情【社区公告】 技术创作特训营有奖征文