代码 kubernetes 1.26.15

问题

混部机子批量节点NotReady(十几个,丫的重大故障),报错为:

意思就是 rpc 超了,节点下有太多 PodSandBox,crictl ps -a 一看有1400多个。。。大量exited的容器没有被删掉,累积起来超过了rpc限制。

PodSandBox 泄漏,crictl pods 可以看到大量同名但是 pod id不同的sanbox,几个月了kubelet并不主动删除

crictl pods
crictl inspectp <pod id>
crictl ps -a | grep <pod-id>
crictl logs <container-id>

kubelet通过cri和containerd进行交互。crictl也可以通过cri规范和containerd交互

crictl 是 CRI(规范) 兼容的容器运行时命令行接口,可以使用它来检查和调试 k8s node节点上的容器运行时和应用程序。

kubernetes 垃圾回收(Garbage Collection)机制由kubelet完成,kubelet定期清理不再使用的容器和镜像,每分钟进行一次容器的GC,每五分钟进行一次镜像的GC

代码逻辑

1. 开始GC

pkg/kubelet/kubelet.go:1352,开始GC func (kl *Kubelet) StartGarbageCollection()

pkg/kubelet/kuberuntime/kuberuntime_gc.go:409

// GarbageCollect removes dead containers using the specified container gc policy.
// Note that gc policy is not applied to sandboxes. Sandboxes are only removed when they are
// not ready and containing no containers.
//
// GarbageCollect consists of the following steps:
// * gets evictable containers which are not active and created more than gcPolicy.MinAge ago.
// * removes oldest dead containers for each pod by enforcing gcPolicy.MaxPerPodContainer.
// * removes oldest dead containers by enforcing gcPolicy.MaxContainers.
// * gets evictable sandboxes which are not ready and contains no containers.
// * removes evictable sandboxes.
func (cgc *containerGC) GarbageCollect(ctx context.Context, gcPolicy kubecontainer.GCPolicy, allSourcesReady bool, evictNonDeletedPods bool) error {
errors := []error{}
// Remove evictable containers
if err := cgc.evictContainers(ctx, gcPolicy, allSourcesReady, evictNonDeletedPods); err != nil {
errors = append(errors, err)
} // Remove sandboxes with zero containers
if err := cgc.evictSandboxes(ctx, evictNonDeletedPods); err != nil {
errors = append(errors, err)
} // Remove pod sandbox log directory
if err := cgc.evictPodLogsDirectories(ctx, allSourcesReady); err != nil {
errors = append(errors, err)
}
return utilerrors.NewAggregate(errors)
}

2. 驱逐容器 evictContainers

  1. 获取 evictUnits pkg/kubelet/kuberuntime/kuberuntime_gc.go:187

    列出所有容器,容器中状态为 ContainerState_CONTAINER_RUNNING 和 container.CreatedAt 小于 minAge 直接跳过。

    其余添加到 evictUnits
map[evictUnit][]containerGCInfo

// evictUnit is considered for eviction as units of (UID, container name) pair.
type evictUnit struct {
// UID of the pod.
uid types.UID
// Name of the container in the pod.
name string
} // containerGCInfo is the internal information kept for containers being considered for GC.
type containerGCInfo struct {
// The ID of the container.
id string
// The name of the container.
name string
// Creation time for the container.
createTime time.Time
// If true, the container is in unknown state. Garbage collector should try
// to stop containers before removal.
unknown bool
}
  1. 删除容器逻辑
// evict all containers that are evictable
func (cgc *containerGC) evictContainers(ctx context.Context, gcPolicy kubecontainer.GCPolicy, allSourcesReady bool, evictNonDeletedPods bool) error {
// Separate containers by evict units.
evictUnits, err := cgc.evictableContainers(ctx, gcPolicy.MinAge)
if err != nil {
return err
} // Remove deleted pod containers if all sources are ready.
// 如果pod已经不存在了,那么就删除其中的所有容器。
if allSourcesReady {
for key, unit := range evictUnits {
if cgc.podStateProvider.ShouldPodContentBeRemoved(key.uid) || (evictNonDeletedPods && cgc.podStateProvider.ShouldPodRuntimeBeRemoved(key.uid)) {
cgc.removeOldestN(ctx, unit, len(unit)) // Remove all.
delete(evictUnits, key)
}
}
} // Enforce max containers per evict unit.
// 执行 GC 策略,保证每个 POD 最多只能保存 MaxPerPodContainer 个已经退出的容器
if gcPolicy.MaxPerPodContainer >= 0 {
cgc.enforceMaxContainersPerEvictUnit(ctx, evictUnits, gcPolicy.MaxPerPodContainer)
} // Enforce max total number of containers.
// 执行 GC 策略,保证节点上最多有 MaxContainers 个已经退出的容器
if gcPolicy.MaxContainers >= 0 && evictUnits.NumContainers() > gcPolicy.MaxContainers {
// Leave an equal number of containers per evict unit (min: 1).
numContainersPerEvictUnit := gcPolicy.MaxContainers / evictUnits.NumEvictUnits()
if numContainersPerEvictUnit < 1 {
numContainersPerEvictUnit = 1
}
cgc.enforceMaxContainersPerEvictUnit(ctx, evictUnits, numContainersPerEvictUnit) // If we still need to evict, evict oldest first.
numContainers := evictUnits.NumContainers()
if numContainers > gcPolicy.MaxContainers {
flattened := make([]containerGCInfo, 0, numContainers)
for key := range evictUnits {
flattened = append(flattened, evictUnits[key]...)
}
sort.Sort(byCreated(flattened)) cgc.removeOldestN(ctx, flattened, numContainers-gcPolicy.MaxContainers)
}
}
return nil
}
  1. 移除该pod uid下的所有容器

    pkg/kubelet/kuberuntime/kuberuntime_gc.go:126
// removeOldestN removes the oldest toRemove containers and returns the resulting slice.
func (cgc *containerGC) removeOldestN(ctx context.Context, containers []containerGCInfo, toRemove int) []containerGCInfo {
// Remove from oldest to newest (last to first).
numToKeep := len(containers) - toRemove
if numToKeep > 0 {
sort.Sort(byCreated(containers))
}
for i := len(containers) - 1; i >= numToKeep; i-- {
if containers[i].unknown {
// Containers in known state could be running, we should try
// to stop it before removal.
id := kubecontainer.ContainerID{
Type: cgc.manager.runtimeName,
ID: containers[i].id,
}
message := "Container is in unknown state, try killing it before removal"
if err := cgc.manager.killContainer(ctx, nil, id, containers[i].name, message, reasonUnknown, nil); err != nil {
klog.ErrorS(err, "Failed to stop container", "containerID", containers[i].id)
continue
}
}
if err := cgc.manager.removeContainer(ctx, containers[i].id); err != nil {
klog.ErrorS(err, "Failed to remove container", "containerID", containers[i].id)
}
} // Assume we removed the containers so that we're not too aggressive.
return containers[:numToKeep]
}

3. 驱逐sandbox evictSandboxes

pkg/kubelet/kuberuntime/kuberuntime_gc.go:276

移除所有可驱逐的沙箱。可驱逐的沙箱必须满足以下要求: 1.未处于就绪状态2.不包含任何容器。3.属于不存在的 (即,已经移除的) pod,或者不是该pod的最近创建的沙箱。

原因分析

目前现象是 crictl pods 可以看到大量同名但是 pod id不同的sanbox。 根据 3 点要求

  1. sanbox notReady 满足
  2. 不包容任何容器 不满足
  3. 不是该pod的最近创建的沙箱 满足

因此sandbox 删不掉的原因是 sandbox下的容器未被删除

容器异常退出后,根据重启策略 restartPolicy: Always pod 会不断重启,直到 超过时限失败。

Pod 的垃圾收集

https://kubernetes.io/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection

对于已失败的 Pod 而言,对应的 API 对象仍然会保留在集群的 API 服务器上, 直到用户或者控制器进程显式地将其删除。

Pod 的垃圾收集器(PodGC)是控制平面的控制器,它会在 Pod 个数超出所配置的阈值 (根据 kube-controller-manager 的 terminated-pod-gc-threshold 设置 默认值:12500)时删除已终止的 Pod(阶段值为 Succeeded 或 Failed)。 这一行为会避免随着时间演进不断创建和终止 Pod 而引起的资源泄露问题。

容器什么时候删除

上面是pod纬度,但是我们的现象是容器删不掉,所以并不是原因,继续看代码

经过大佬的实验验证,对于失败的 容器,只会保留一个失败的现场,多余的会GC掉,和 问题现场一致

容器 GC 虽然有利于空间和性能,但是删除容器也会导致错误现场被清理,不利于 debug 和错误定位,因此不建议把所有退出的容器都删除。

cmd/kubelet/app/options/options.go:183

// Maximum number of old instances of containers to retain globally.  Each container takes up some disk space. To disable, set to a negative number.
// 我们可以设置这个值兜底
MaxContainerCount: -1,
MinimumGCAge: metav1.Duration{Duration: 0},
// 每个 container 最终可以保存多少个已经结束的容器,默认是 1,设置为负数表示不做限制
MaxPerPodContainerCount: 1,

再看上面容器GC代码

// 如果pod已经不存在了,那么就删除其中的所有容器。
.... // 执行 GC 策略,保证每个 POD 最多只能保存 MaxPerPodContainerCount 个已经退出的容器
// MaxPerPodContainerCount 默认值为1,对应保留一个失败的现场
if gcPolicy.MaxPerPodContainer >= 0 {
cgc.enforceMaxContainersPerEvictUnit(ctx, evictUnits, gcPolicy.MaxPerPodContainer)
} // 保证节点上最多有 MaxContainerCount 个已经退出的容器
// MaxContainerCount 默认值为 -1 不限制,我们可以设置一个兜底
if gcPolicy.MaxContainers >= 0 && evictUnits.NumContainers() > gcPolicy.MaxContainers {
......
}

总结,容器失败,会保留一个现场不GC,导致越来越多失败的容器存在,最后容器过多,导致rpc传输超过限制,整个节点崩掉

解决方案

粗暴手删

  1. crictl 超出限制,不能正常工作时
#!/bin/bash

# 列出所有在 k8s.io 命名空间下的容器
containers=$(ctr -n k8s.io c list -q) # 遍历容器 ID 并删除每一个容器
for container in $containers; do
echo "Deleting container: $container"
ctr -n k8s.io c rm "$container"
done echo "All containers have been removed." systemctl restart containerd
systemctl restart kubelet
  1. crictl 可以正常工作,删除失败容器,sandbox会1min后,自动gc
#!/bin/bash

# 获取所有Exited状态的容器ID
exited_containers=$(crictl ps -a | grep Exited | grep months | awk '{print $1}') # 检查是否有Exited容器需要删除
if [ -z "$exited_containers" ]; then
echo "没有找到任何处于Exited状态的容器。"
else
# 遍历所有Exited状态的容器ID,并删除它们
for container in $exited_containers; do
echo "正在删除容器: $container"
crictl rm $container
if [ $? -eq 0 ]; then
echo "容器 $container 已成功删除。"
else
echo "删除容器 $container 失败。"
fi
done
fi

优雅解决

  • 配置 maximum-dead-containers 兜底,默认-1,节点虽然限制每一个容器的失败实例为1,但是总的失败实例不做限制。
  • 使用operator 或则 npd 进行监控,太多,则和诊断中心联动删除(倒序删除最老的50个exited,滚动删除)

grpc ??

问题的本质是 grpc 超标,我们是否可以直接改 grpc 的 received message larger than max (4198720 vs. 4194304)

让我们看一下 containerd 的源码

kubelet 与 cri server 交互 pkg/cri/server/sandbox_list.go:29

func (c *criService) ListPodSandbox(ctx context.Context, r *runtime.ListPodSandboxRequest) (*runtime.ListPodSandboxResponse, error)

pkg/cri/cri.go:100 s, err := server.NewCRIService(c, client)

client 是New返回一个新的containerd客户端,该客户端连接到地址提供的containerd实例,代码很简单,如果 address!="" 设置 grpc 大小为 16m,如果为空,grpc 大小为默认值 4m

// New returns a new containerd client that is connected to the containerd
// instance provided by address
func New(address string, opts ...ClientOpt) (*Client, error) {
// .......
c := &Client{
defaultns: copts.defaultns,
}
// .......
if address != "" {
// .......
gopts := []grpc.DialOption{
grpc.WithBlock(),
grpc.WithTransportCredentials(insecure.NewCredentials()),
grpc.FailOnNonTempDialError(true),
grpc.WithConnectParams(connParams),
grpc.WithContextDialer(dialer.ContextDialer),
grpc.WithReturnConnectionError(),
}
if len(copts.dialOptions) > 0 {
gopts = copts.dialOptions
}
// 设置 grpc 最大值 16m
gopts = append(gopts, grpc.WithDefaultCallOptions(
grpc.MaxCallRecvMsgSize(defaults.DefaultMaxRecvMsgSize),
grpc.MaxCallSendMsgSize(defaults.DefaultMaxSendMsgSize)))
//........ connector := func() (*grpc.ClientConn, error) {
ctx, cancel := context.WithTimeout(context.Background(), copts.timeout)
defer cancel()
conn, err := grpc.DialContext(ctx, dialer.DialAddress(address), gopts...)
if err != nil {
return nil, fmt.Errorf("failed to dial %q: %w", address, err)
}
return conn, nil
}
conn, err := connector()
if err != nil {
return nil, err
}
c.conn, c.connector = conn, connector
}
//........
return c, nil
}

但是在 pkg/cri/cri.go:62 初始化 cri 插件时,address 为空,grpc 大小为默认值 4m

client, err := containerd.New(
"",
containerd.WithDefaultNamespace(constants.K8sContainerdNamespace),
containerd.WithDefaultPlatform(platforms.Default()),
containerd.WithServices(servicesOpts...),
)

contianerd 相关issue

社区目前的方案就是设置 maximum-dead-containers 兜底

https://github.com/kubernetes/kubernetes/issues/63858

最终方案

  • 配置 pod status NotReady > 50 电话告警

    increase(problem_counter{app="ops.paas.npd",reason="lots of pods notReady"}[60m]) > 0
  • 配置 maximum-dead-containers=200

后续改进

死亡容器保持一个不删,只是原因,后续发现sandbox 的 GC 速度很慢 (看日志 GC 一个sandbox 5s 左右)

removeSandBox 会调用 stopSandBox,if sandbox.NetNS != nil 会 teardownPodNetwork ,这里会和 cni 插件交互,因为 cni-adaptor 重复删除网络又报错,GC 就失败了,极大影响 GC 效率,后续需要对 cni 插件进行优化

删除网络操作

cni 删除操作,因改为尽量删除

https://github.com/containernetworking/plugins/issues/210 vendor/github.com/containerd/go-cni/cni.go:234

// Remove removes the network config from the namespace
func (c *libcni) Remove(ctx context.Context, id string, path string, opts ...NamespaceOpts) error {
if err := c.Status(); err != nil {
return err
}
ns, err := newNamespace(id, path, opts...)
if err != nil {
return err
}
for _, network := range c.Networks() {
if err := network.Remove(ctx, ns); err != nil {
// Based on CNI spec v0.7.0, empty network namespace is allowed to
// do best effort cleanup. However, it is not handled consistently
// right now:
// https://github.com/containernetworking/plugins/issues/210
// TODO(random-liu): Remove the error handling when the issue is
// fixed and the CNI spec v0.6.0 support is deprecated.
// NOTE(claudiub): Some CNIs could return a "not found" error, which could mean that
// it was already deleted.
if (path == "" && strings.Contains(err.Error(), "no such file or directory")) || strings.Contains(err.Error(), "not found") {
continue
}
return err
}
}
return nil
}

kubelet gc 源码分析的更多相关文章

  1. GC 源码分析

    java对象的内存分配入口 Hotspot 源码解析(9) •内存代管理器TenuredGeneration对垃圾对象的回收2015-01-18阅读1154 •内存代管理器DefNewGenerati ...

  2. 11.深入k8s:kubelet工作原理及源码分析

    转载请声明出处哦~,本篇文章发布于luozhiyun的博客:https://www.luozhiyun.com 源码版本是1.19 kubelet信息量是很大的,通过我这一篇文章肯定是讲不全的,大家可 ...

  3. kubelet分析-csi driver注册源码分析

    kubelet注册csi driver分析 kubelet注册csi driver的相关功能代码与kubelet的pluginManager有关,所以接下来对pluginManager进行分析.分析将 ...

  4. heapster源码分析——kubelet的api调用分析

    一.heapster简介 什么是Heapster? Heapster是容器集群监控和性能分析工具,天然的支持Kubernetes和CoreOS.Kubernetes有个出名的监控agent---cAd ...

  5. 源码分析HotSpot GC过程(一)

    «上一篇:源码分析HotSpot GC过程(一)»下一篇:源码分析HotSpot GC过程(三):TenuredGeneration的GC过程 https://blogs.msdn.microsoft ...

  6. 源码分析HotSpot GC过程(三):TenuredGeneration的GC过程

    老年代TenuredGeneration所使用的垃圾回收算法是标记-压缩-清理算法.在回收阶段,将标记对象越过堆的空闲区移动到堆的另一端,所有被移动的对象的引用也会被更新指向新的位置.看起来像是把杂陈 ...

  7. kubelet分析-csi driver注册分析-Node Driver Registrar源码分析

    kubernetes ceph-csi分析目录导航 Node Driver Registrar分析 node-driver-registrar是一个sidecar容器,通过Kubelet的插件注册机制 ...

  8. kubelet源码分析——关闭Pod

    上一篇说到kublet如何启动一个pod,本篇讲述如何关闭一个Pod,引用一段来自官方文档介绍pod的生命周期的话 你使用 kubectl 工具手动删除某个特定的 Pod,而该 Pod 的体面终止限期 ...

  9. kubelet源码分析——监控Pod变更

    前言 前文介绍Pod无论是启动时还是关闭时,处理是由kubelet的主循环syncLoop开始执行逻辑,而syncLoop的入参是一条传递变更Pod的通道,显然syncLoop往后的逻辑属于消费者一方 ...

  10. k8s驱逐篇(3)-kubelet节点压力驱逐-源码分析篇

    kubelet节点压力驱逐-概述 kubelet监控集群节点的 CPU.内存.磁盘空间和文件系统的inode 等资源,根据kubelet启动参数中的驱逐策略配置,当这些资源中的一个或者多个达到特定的消 ...

随机推荐

  1. DevEco Device Tool 3.0 Release带来5大能力升级,让智能设备开发更高效

    原文:https://mp.weixin.qq.com/s/QYlHUU05BDlzVxbfZbiKOg,点击链接查看更多技术内容. DevEco Device Tool是面向智能设备开发者提供的一站 ...

  2. Centos 6.4 配置网页服务器

    Centos 6.4 配置网页服务器 (2013-08-08 22:59:09) 转载▼   分类:linux系统 今天值班,在单位找一台电脑安装了Centos 6.4操作系统. 一.安装软件 yum ...

  3. 重新点亮linux 命令树————screen 命令和系统日志[二十四]

    前言 简单介绍一下screen 正文 因为我们终端关闭后,终端就消失了,故而希望有终端保持. 1.yum install screen 进行安装. 2.使用screen 进行进入 3.然后打开tail ...

  4. 力扣595(MySQL)-大的国家(简单)

    题目: World 表: 如果一个国家满足下述两个条件之一,则认为该国是 大国 : 面积至少为 300 万平方公里(即,3000000 km2),或者人口至少为 2500 万(即 25000000)编 ...

  5. 【深度】阿里巴巴万级规模 K8s 集群全局高可用体系之美

    简介: 台湾作家林清玄在接受记者采访的时候,如此评价自己 30 多年写作生涯:"第一个十年我才华横溢,'贼光闪现',令周边黯然失色:第二个十年,我终于'宝光现形',不再去抢风头,反而与身边的 ...

  6. 【ESSD技术解读-01】 云原生时代,阿里云块存储 ESSD 快照服务如何被企业级数据保护所集成?

    ​简介: 本文描述了阿里云块存储快照服务基于高性能 ESSD 云盘提升快照服务性能,提供轻量.实时的用户体验及揭秘背后的技术原理.依据行业发展及云上数据保护场景,为企业用户及备份厂商提供基于快照高级特 ...

  7. [FAQ] Phpstorm 代码提示功能失效问题

    如果是之前有代码提示,中间突然不出现提示了,那么考虑重建一下项目索引. 示例: Refer:Phpstorm代码提示 Link:https://www.cnblogs.com/farwish/p/13 ...

  8. dotnet 8 破坏性改动 在 AssemblyInformationalVersionAttribute 添加上 git 的 commit 号

    我在一个 WPF 项目里面,在界面显示应用的版本号,更新到 dotnet 8 的 SDK 之后,发现我的界面布局损坏了.本质上这个破坏性改动和 WPF 没有什么关系,是 dotnet 的 SDK 或编 ...

  9. WPF 已知问题 资源字典树引用与资源寻找的坑

    大家都知道,在 WPF 里面,可以让资源字典合并其他资源字典,从而定义出资源字典引用树.然而在资源字典引用树里面,如果没有理清关系,将可以作出一个超级复杂的引用关系网.如果在性能优化中,将网断开部分, ...

  10. 第一章 Jenkins安装配置

    Jenkins官网 # 官网: https://www.jenkins.iohttps://www.jenkins.io/zh/ # docker安装: https://www.jenkins.io/ ...