经验首页 前端设计 程序设计 Java相关 移动开发 数据库/运维 软件/图像 大数据/云计算 其他经验
当前位置:技术经验 » 数据库/运维 » Kubernetes » 查看文章
kubelet gc 源码分析
来源:cnblogs  作者:叒狗  时间:2024/5/27 9:20:41  对本文有异议

代码 kubernetes 1.26.15

问题

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

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

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

  1. crictl pods
  2. crictl inspectp <pod id>
  3. crictl ps -a | grep <pod-id>
  4. 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

  1. // GarbageCollect removes dead containers using the specified container gc policy.
  2. // Note that gc policy is not applied to sandboxes. Sandboxes are only removed when they are
  3. // not ready and containing no containers.
  4. //
  5. // GarbageCollect consists of the following steps:
  6. // * gets evictable containers which are not active and created more than gcPolicy.MinAge ago.
  7. // * removes oldest dead containers for each pod by enforcing gcPolicy.MaxPerPodContainer.
  8. // * removes oldest dead containers by enforcing gcPolicy.MaxContainers.
  9. // * gets evictable sandboxes which are not ready and contains no containers.
  10. // * removes evictable sandboxes.
  11. func (cgc *containerGC) GarbageCollect(ctx context.Context, gcPolicy kubecontainer.GCPolicy, allSourcesReady bool, evictNonDeletedPods bool) error {
  12. errors := []error{}
  13. // Remove evictable containers
  14. if err := cgc.evictContainers(ctx, gcPolicy, allSourcesReady, evictNonDeletedPods); err != nil {
  15. errors = append(errors, err)
  16. }
  17. // Remove sandboxes with zero containers
  18. if err := cgc.evictSandboxes(ctx, evictNonDeletedPods); err != nil {
  19. errors = append(errors, err)
  20. }
  21. // Remove pod sandbox log directory
  22. if err := cgc.evictPodLogsDirectories(ctx, allSourcesReady); err != nil {
  23. errors = append(errors, err)
  24. }
  25. return utilerrors.NewAggregate(errors)
  26. }

2. 驱逐容器 evictContainers

  1. 获取 evictUnits pkg/kubelet/kuberuntime/kuberuntime_gc.go:187
    列出所有容器,容器中状态为 ContainerState_CONTAINER_RUNNING 和 container.CreatedAt 小于 minAge 直接跳过。
    其余添加到 evictUnits
  1. map[evictUnit][]containerGCInfo
  2. // evictUnit is considered for eviction as units of (UID, container name) pair.
  3. type evictUnit struct {
  4. // UID of the pod.
  5. uid types.UID
  6. // Name of the container in the pod.
  7. name string
  8. }
  9. // containerGCInfo is the internal information kept for containers being considered for GC.
  10. type containerGCInfo struct {
  11. // The ID of the container.
  12. id string
  13. // The name of the container.
  14. name string
  15. // Creation time for the container.
  16. createTime time.Time
  17. // If true, the container is in unknown state. Garbage collector should try
  18. // to stop containers before removal.
  19. unknown bool
  20. }
  1. 删除容器逻辑
  1. // evict all containers that are evictable
  2. func (cgc *containerGC) evictContainers(ctx context.Context, gcPolicy kubecontainer.GCPolicy, allSourcesReady bool, evictNonDeletedPods bool) error {
  3. // Separate containers by evict units.
  4. evictUnits, err := cgc.evictableContainers(ctx, gcPolicy.MinAge)
  5. if err != nil {
  6. return err
  7. }
  8. // Remove deleted pod containers if all sources are ready.
  9. // 如果pod已经不存在了,那么就删除其中的所有容器。
  10. if allSourcesReady {
  11. for key, unit := range evictUnits {
  12. if cgc.podStateProvider.ShouldPodContentBeRemoved(key.uid) || (evictNonDeletedPods && cgc.podStateProvider.ShouldPodRuntimeBeRemoved(key.uid)) {
  13. cgc.removeOldestN(ctx, unit, len(unit)) // Remove all.
  14. delete(evictUnits, key)
  15. }
  16. }
  17. }
  18. // Enforce max containers per evict unit.
  19. // 执行 GC 策略,保证每个 POD 最多只能保存 MaxPerPodContainer 个已经退出的容器
  20. if gcPolicy.MaxPerPodContainer >= 0 {
  21. cgc.enforceMaxContainersPerEvictUnit(ctx, evictUnits, gcPolicy.MaxPerPodContainer)
  22. }
  23. // Enforce max total number of containers.
  24. // 执行 GC 策略,保证节点上最多有 MaxContainers 个已经退出的容器
  25. if gcPolicy.MaxContainers >= 0 && evictUnits.NumContainers() > gcPolicy.MaxContainers {
  26. // Leave an equal number of containers per evict unit (min: 1).
  27. numContainersPerEvictUnit := gcPolicy.MaxContainers / evictUnits.NumEvictUnits()
  28. if numContainersPerEvictUnit < 1 {
  29. numContainersPerEvictUnit = 1
  30. }
  31. cgc.enforceMaxContainersPerEvictUnit(ctx, evictUnits, numContainersPerEvictUnit)
  32. // If we still need to evict, evict oldest first.
  33. numContainers := evictUnits.NumContainers()
  34. if numContainers > gcPolicy.MaxContainers {
  35. flattened := make([]containerGCInfo, 0, numContainers)
  36. for key := range evictUnits {
  37. flattened = append(flattened, evictUnits[key]...)
  38. }
  39. sort.Sort(byCreated(flattened))
  40. cgc.removeOldestN(ctx, flattened, numContainers-gcPolicy.MaxContainers)
  41. }
  42. }
  43. return nil
  44. }
  1. 移除该pod uid下的所有容器
    pkg/kubelet/kuberuntime/kuberuntime_gc.go:126
  1. // removeOldestN removes the oldest toRemove containers and returns the resulting slice.
  2. func (cgc *containerGC) removeOldestN(ctx context.Context, containers []containerGCInfo, toRemove int) []containerGCInfo {
  3. // Remove from oldest to newest (last to first).
  4. numToKeep := len(containers) - toRemove
  5. if numToKeep > 0 {
  6. sort.Sort(byCreated(containers))
  7. }
  8. for i := len(containers) - 1; i >= numToKeep; i-- {
  9. if containers[i].unknown {
  10. // Containers in known state could be running, we should try
  11. // to stop it before removal.
  12. id := kubecontainer.ContainerID{
  13. Type: cgc.manager.runtimeName,
  14. ID: containers[i].id,
  15. }
  16. message := "Container is in unknown state, try killing it before removal"
  17. if err := cgc.manager.killContainer(ctx, nil, id, containers[i].name, message, reasonUnknown, nil); err != nil {
  18. klog.ErrorS(err, "Failed to stop container", "containerID", containers[i].id)
  19. continue
  20. }
  21. }
  22. if err := cgc.manager.removeContainer(ctx, containers[i].id); err != nil {
  23. klog.ErrorS(err, "Failed to remove container", "containerID", containers[i].id)
  24. }
  25. }
  26. // Assume we removed the containers so that we're not too aggressive.
  27. return containers[:numToKeep]
  28. }

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

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

再看上面容器GC代码

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

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

解决方案

粗暴手删

  1. crictl 超出限制,不能正常工作时
  1. #!/bin/bash
  2. # 列出所有在 k8s.io 命名空间下的容器
  3. containers=$(ctr -n k8s.io c list -q)
  4. # 遍历容器 ID 并删除每一个容器
  5. for container in $containers; do
  6. echo "Deleting container: $container"
  7. ctr -n k8s.io c rm "$container"
  8. done
  9. echo "All containers have been removed."
  10. systemctl restart containerd
  11. systemctl restart kubelet
  1. crictl 可以正常工作,删除失败容器,sandbox会1min后,自动gc
  1. #!/bin/bash
  2. # 获取所有Exited状态的容器ID
  3. exited_containers=$(crictl ps -a | grep Exited | grep months | awk '{print $1}')
  4. # 检查是否有Exited容器需要删除
  5. if [ -z "$exited_containers" ]; then
  6. echo "没有找到任何处于Exited状态的容器。"
  7. else
  8. # 遍历所有Exited状态的容器ID,并删除它们
  9. for container in $exited_containers; do
  10. echo "正在删除容器: $container"
  11. crictl rm $container
  12. if [ $? -eq 0 ]; then
  13. echo "容器 $container 已成功删除。"
  14. else
  15. echo "删除容器 $container 失败。"
  16. fi
  17. done
  18. 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

  1. 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

  1. // New returns a new containerd client that is connected to the containerd
  2. // instance provided by address
  3. func New(address string, opts ...ClientOpt) (*Client, error) {
  4. // .......
  5. c := &Client{
  6. defaultns: copts.defaultns,
  7. }
  8. // .......
  9. if address != "" {
  10. // .......
  11. gopts := []grpc.DialOption{
  12. grpc.WithBlock(),
  13. grpc.WithTransportCredentials(insecure.NewCredentials()),
  14. grpc.FailOnNonTempDialError(true),
  15. grpc.WithConnectParams(connParams),
  16. grpc.WithContextDialer(dialer.ContextDialer),
  17. grpc.WithReturnConnectionError(),
  18. }
  19. if len(copts.dialOptions) > 0 {
  20. gopts = copts.dialOptions
  21. }
  22. // 设置 grpc 最大值 16m
  23. gopts = append(gopts, grpc.WithDefaultCallOptions(
  24. grpc.MaxCallRecvMsgSize(defaults.DefaultMaxRecvMsgSize),
  25. grpc.MaxCallSendMsgSize(defaults.DefaultMaxSendMsgSize)))
  26. //........
  27. connector := func() (*grpc.ClientConn, error) {
  28. ctx, cancel := context.WithTimeout(context.Background(), copts.timeout)
  29. defer cancel()
  30. conn, err := grpc.DialContext(ctx, dialer.DialAddress(address), gopts...)
  31. if err != nil {
  32. return nil, fmt.Errorf("failed to dial %q: %w", address, err)
  33. }
  34. return conn, nil
  35. }
  36. conn, err := connector()
  37. if err != nil {
  38. return nil, err
  39. }
  40. c.conn, c.connector = conn, connector
  41. }
  42. //........
  43. return c, nil
  44. }

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

  1. client, err := containerd.New(
  2. "",
  3. containerd.WithDefaultNamespace(constants.K8sContainerdNamespace),
  4. containerd.WithDefaultPlatform(platforms.Default()),
  5. containerd.WithServices(servicesOpts...),
  6. )

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

  1. // Remove removes the network config from the namespace
  2. func (c *libcni) Remove(ctx context.Context, id string, path string, opts ...NamespaceOpts) error {
  3. if err := c.Status(); err != nil {
  4. return err
  5. }
  6. ns, err := newNamespace(id, path, opts...)
  7. if err != nil {
  8. return err
  9. }
  10. for _, network := range c.Networks() {
  11. if err := network.Remove(ctx, ns); err != nil {
  12. // Based on CNI spec v0.7.0, empty network namespace is allowed to
  13. // do best effort cleanup. However, it is not handled consistently
  14. // right now:
  15. // https://github.com/containernetworking/plugins/issues/210
  16. // TODO(random-liu): Remove the error handling when the issue is
  17. // fixed and the CNI spec v0.6.0 support is deprecated.
  18. // NOTE(claudiub): Some CNIs could return a "not found" error, which could mean that
  19. // it was already deleted.
  20. if (path == "" && strings.Contains(err.Error(), "no such file or directory")) || strings.Contains(err.Error(), "not found") {
  21. continue
  22. }
  23. return err
  24. }
  25. }
  26. return nil
  27. }

原文链接:https://www.cnblogs.com/cheng-sir/p/18214252

 友情链接:直通硅谷  点职佳  北美留学生论坛

本站QQ群:前端 618073944 | Java 606181507 | Python 626812652 | C/C++ 612253063 | 微信 634508462 | 苹果 692586424 | C#/.net 182808419 | PHP 305140648 | 运维 608723728

W3xue 的所有内容仅供测试,对任何法律问题及风险不承担任何责任。通过使用本站内容随之而来的风险与本站无关。
关于我们  |  意见建议  |  捐助我们  |  报错有奖  |  广告合作、友情链接(目前9元/月)请联系QQ:27243702 沸活量
皖ICP备17017327号-2 皖公网安备34020702000426号