【containerd】RunPodSandbox for XXX error="failed to reserve sandbox name"

问题背景

工业云部署使用k8s集群

• k8s: 01746170708faa599113b027772802bcbb594ee8
• containerd: v1.5.4
• OS: Tencent tlinux 2.2 (Final)
• kernel: Linux TENCENT64.site 3.10.0-693_4003268.tl2

问题描述

工业云同学通过控制台升级业务容器镜像版本，升级后导致容器创建失败，失败的error log如下所示:

Jun 06 20:45:29 TENCENT64.site containerd[5327]: time="2022-06-06T20:45:29.816213573+08:00" level=error msg="RunPodSandbox for &PodSandboxMetadata{Name:edge-56c86c995f-tqzz2,Uid:da70d1c2-0978-40c1-a9a6-c5a25a7f41a3,Namespace:edge-adapter,Attempt:0,} failed, error" error="failed to reserve sandbox name \"edge-56c86c995f-tqzz2_edge-adapter_da70d1c2-0978-40c1-a9a6-c5a25a7f41a3_0\": name \"edge-56c86c995f-tqzz2_edge-adapter_da70d1c2-0978-40c1-a9a6-c5a25a7f41a3_0\" is reserved for \"762b66093089b50109f74fa5a4cc6e7165d916b18dfd1b5c877fc4effff1e558\""

问题排查

• 创建一个测试nginx的容器也创建失败，报错相同也是卡在create pod sandbox：

  
  
  image.png

• 通过nerdctl run创建容器发现也创建失败，卡在creating 状态：

• 查看containerd的error log:

  
  
  image.png

• 查看kubelet日志：

Jun 06 20:45:29 TENCENT64.site containerd[5327]: time="2022-06-06T20:45:29.816213573+08:00" level=error msg="RunPodSandbox for &PodSandboxMetadata{Name:edge-56c86c995f-tqzz2,Uid:da70d1c2-0978-40c1-a9a6-c5a25a7f41a3,Namespace:edge-adapter,Attempt:0,} failed, error" error="failed to reserve sandbox name \"edge-56c86c995f-tqzz2_edge-adapter_da70d1c2-0978-40c1-a9a6-c5a25a7f41a3_0\": name \"edge-56c86c995f-tqzz2_edge-adapter_da70d1c2-0978-40c1-a9a6-c5a25a7f41a3_0\" is reserved for \"762b66093089b50109f74fa5a4cc6e7165d916b18dfd1b5c877fc4effff1e558\""

• 环境中发现kworker占用CPU的使用率很高：

  
  
  image.png

• 集群上的Pod IP分配情况：

  
  
  image.png

• 内存使用情况

  
  
  image.png

• 有个containerd的僵尸进程是5月25号启动的，被systemd 1号进程托管，kill -9也杀不掉该进程

• 环境中存在chaosmesh 进程使用containerd，

ps -ef | grep chao
root        752 101375  0 16:05 pts/1    00:00:00 grep --color=auto chao
root      60780  59079  0 06:30 ?        00:00:03 /usr/local/bin/chaos-daemon --runtime containerd --http-port 31766 --grpc-port 31767 --pprof --ca /etc/chaos-daemon/cert/ca.crt --cert /etc/chaos-daemon/cert/tls.crt --key /etc/chaos-daemon/cert/tls.key --runtime-socket-path /host-run/containerd.sock

问题处理

• GitHub上搜索相关的issue，发现有类似error的issue:https://github.com/containerd/containerd/issues/4604
• 根据issue描述，初步怀疑是磁盘的IO过高导致容器创建失败，此问题社区已经有对应的bug fix PR:https://github.com/containerd/containerd/pull/6478/files
• 由于1.5.4版本中没有这个fix，所以在环境上升级了containerd版本，v1.5.10，这个版本包含对应的code fix，并且重启了机器，机器重启后pod都正常running，kworker使用CPU也恢复正常，由于当时没有查看IO的使用情况，所以不能排除IO不是真正的root cause，此问题需要继续跟进。

后续问题跟进

• 环境上已经替换为新版本的containerd，后面继续观察集群节点上的IO使用情况iotop，kworker的资源使用情况top；
• 在自测环境中做压力测试复现问题：

stress-ng --io 30 -d 5

image.png

创建nginx deployment：

kubectl apply -f nginx.yaml

 kubectl get pods
NAME                               READY   STATUS              RESTARTS   AGE
nginx-deployment-857cbc9c6-7plrb   0/1     ContainerCreating   0          7m41s
nginx-deployment-857cbc9c6-f5gjq   0/1     ContainerCreating   0          7m40s

image.png

kubelet error log:

image.png

containerd error log:

Jun 07 21:03:05 VM-71-117-ubuntu containerd[14269]: time="2022-06-07T21:03:05.036947355+08:00" level=error msg="RunPodSandbox for &PodSandboxMetadata{Name:nginx-deployment-857cbc9c6-f5gjq,Uid:29d9b646-2ed6-411d-b89a-5e1526de3393,Namespace:default,Attempt:0,} failed, error" error="failed to reserve sandbox name \"nginx-deployment-857cbc9c6-f5gjq_default_29d9b646-2ed6-411d-b89a-5e1526de3393_0\": name \"nginx-deployment-857cbc9c6-f5gjq_default_29d9b646-2ed6-411d-b89a-5e1526de3393_0\" is reserved for \"aa39cc65311ca413accf095a659c372b02e987d5b97687d3241c830f3b1091d5\""

把压力测试进程停掉，pod就创建成功了:

kubectl get pods
NAME                               READY   STATUS    RESTARTS   AGE
nginx-deployment-857cbc9c6-7plrb   1/1     Running   0          14m
nginx-deployment-857cbc9c6-f5gjq   1/1     Running   0          14m

• 使用containerd v1.5.10做压力测试
  创建Pod还是会卡在creating状态大概五分钟,最后状态变成RunContainerError状态，最后还是会报错failed to reserve sandbox name \"nginx-deployment-857cbc9c6-sp5rp_default_c2c8a3d4-0e02-4688-8b6e-711a0f6525c5_0\": name \"nginx-deployment-857cbc9c6-sp5rp_default_c2c8a3d4-0e02-4688-8b6e-711a0f6525c5_0\" is reserved for \"39ab9d7b6250608fd911ff079f3d0781044674e2d6a1e58893ed422d6a2adb60\""：

 Normal   Scheduled               7m41s  default-scheduler  Successfully assigned default/nginx-deployment-857cbc9c6-sp5rp to 10.0.71.117
  Warning  FailedCreatePodSandBox  3m37s  kubelet            Failed to create pod sandbox: rpc error: code = DeadlineExceeded desc = context deadline exceeded

root@VM-71-117-ubuntu:~# kubectl get pods
NAME                               READY   STATUS              RESTARTS   AGE
nginx-deployment-857cbc9c6-sp5rp   0/1     ContainerCreating   0          7m23s
nginx-deployment-857cbc9c6-wm88t   0/1     RunContainerError   0          7m24s

kubelet log:

Jun 08 10:00:13 VM-71-117-ubuntu kubelet[11643]: E0608 10:00:13.322478   11643 pod_workers.go:190] "Error syncing pod, skipping" err="failed to \"CreatePodSandbox\" for \"nginx-deployment-857cbc9c6-sp5rp_default(c2c8a3d4-0e02-4688-8b6e-711a0f6525c5)\" with CreatePodSandboxError: \"Failed to create sandbox for pod \\\"nginx-deployment-857cbc9c6-sp5rp_default(c2c8a3d4-0e02-4688-8b6e-711a0f6525c5)\\\": rpc error: code = DeadlineExceeded desc = context deadline exceeded\"" pod="default/nginx-deployment-857cbc9c6-sp5rp" podUID=c2c8a3d4-0e02-4688-8b6e-711a0f6525c5

containerd log:

image.png

• 分析错误产生的原因
  1、kubelet 发送请求给 containerd 创建容器，当 containerd 第一次尝试创建这个容器的时候，它会创建名为Attempt的元数据，该变量保持默认值为0代码)
  2、在kubelet和containerd之间发生context timeout
  3、在下一次kubelet运行 SyncPod 时，kubelet 会尝试再次创建相同的容器。但是，它不会在 CreateContainer 超时时增加Attempt次数，只会在容器重新启动时增加，在超时之后，Attempt number 不会增加，但是 CRI 已经保留了容器名称，因此所有后续创建相同容器的请求都会失败代码
  这是kubelet和containerd的正常的行为，如果容器设置策略为restartPolicy:Always or restartPolicy:OnFailure当磁盘IO下降，containerd最终会创建容器成功。（根据前面的压测结果，如果kill掉IO比较高的压测进程，容器会很快创建成功。）
• PR fix解析
  目前社区内针对这个问题，merge了一个PR ，此PR主要是解决在createContainer的时候调用umount触发内核调用sync-fs，这样会增加磁盘的IO开销，使用readonly mount就不会掉用sync-fs方法，此PR改用readonly mount，这样可以减少 PodCreateContainer 中的 syncfs，减小containerd带来的IO开销，从而加快容器的创建，但它不能减少 runc 进程中的 mount 时的产生的磁盘IO。
  所以继续跟踪发现：runc init确实也卡住了

root      3516  3508  0 15:54 pts/1    00:00:00 runc init

image.png

image.png

通过ps aux | grep runc会发现有些runc stack是卡在do_mount上，并且runc的进程状态是D，什么是D状态呢？D状态的进程通常是在等待IO，比如磁盘IO，网络IO，其他外设IO，很明显这块是在等待磁盘IO。

• 目前的解决方法
  从上面的排查和社区的分析来看，此问题主要是磁盘IO过高导致的，所以要解决问题，就是从如何降低磁盘IO出发，上面的PR fix也是从containerd方面降低磁盘IO：
  1、更换高性能的磁盘，提高磁盘IO，增大磁盘容量；
  2、增加集群节点，对于高IO的业务，迁移到其它节点，减小节点的IO（公有云的解决方法是加cbs或者挪到eks）；
  3、在更新业务的时候，不要同时更新多个，可以每次保持最小化更新，防止pull image加大磁盘IO导致更新失败。