问题背景：
接performance team报问题，平时一直在跑的deploy job 出现了大面积的fail，
排查步骤:
接到客户报问题后，第一反应，肯定是查看pod信息
通过kubectl -n performance get pods -o wide
发现有大量的pods停留在 ContainerCreating 状态，因为pod没有被建立，此时是不能通过kubectl logs查看log的，
所以只能先通过kubectl describe查看哪些events发生在这个pod上，
```kubectl describe pod pvc-proxy-fc3c60531bb42efdfe4a65096ba5b9a0-9pr9g -n performance-deployments
=====================================
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 50m default-scheduler Successfully assigned pvc-proxy-fc3c60531bb42efdfe4a65096ba5b9a0-9pr9g to ip-10-146-20-198.ec2.internal
Normal SuccessfulMountVolume 50m kubelet, ip-10-146-20-198.ec2.internal MountVolume.SetUp succeeded for volume "learn-perf-deployments-share"
Normal SuccessfulMountVolume 50m kubelet, ip-10-146-20-198.ec2.internal MountVolume.SetUp succeeded for volume "learn-service-account-token-7ntls"
Warning FailedCreatePodSandBox 45m (x187 over 50m) kubelet, ip-10-146-20-198.ec2.internal Failed create pod sandbox: rpc error: code = Unknown desc = failed to start sandbox container for pod "pvc-proxy-fc3c60531bb42efdfe4a65096ba5b9a0-9pr9g": Error response from daemon: grpc: the connection is unavailable
Normal SandboxChanged 36s (x1839 over 50m) kubelet, ip-10-146-20-198.ec2.internal Pod sandbox changed, it will be killed and re-created.
```
1）简单从events上看到有些warning，google一把，有些说是高压力下，network 可能出现问题，导致pod不能被建立，aws/amazon-vpc-cni-k8s#59， 此时需要升级plugin的版本。由于我们正好刚刚升级过K8S cluster，所以想当然，认为是不是这个plugin忘记同步升级了。 但这只能是凭空猜测，因为不知道当前cluster deploy的整体架构，不知道有没有使用这个plugin。所以这个只能是猜测疑点1.
2）由于白天，不能联系到美国有权限的团队，只能继续思考
因为是大批量pod 同时发生问题，怀疑调度问题，本想登录到ec2上看看到底发生了什么，发现该pod被调度到kubernetes master node上了，无奈外企权限控制极度严苛，没有ssh权限；然后找出现问题的pod2，希望发现是否有被调度到其他node上的pod。观察后，发现全部是同一个node，到其他node上没有问题。此时锁定怀疑点2，是不是这个node有问题。这个理由感觉更充分一些，以往经验也告诉我，确实node发生问题，机率最大。
综上，两点疑点，都发邮件通知美国团队，重点让他们排查node，插件版本问题，只是猜测。
不过由于权限限制，这些都只能是猜测，定位某个pod的问题，还是应该查看kubelet log。具体定位调度时问题。。。。
3）经美国有权限同事，ssh node查看，果然发现docker最重要的创建container的进程 containerd 意外退出了。他们只是单纯remove掉node，也没有定位什么原因导致进程退出。如果换做我，是要进一步看看什么地方导致的。
It appears the issue with this node is not network related but rather containerd is not running on there for some reason.
Working node:
```
admin@ip-10-146-22-22:~$ ps -fe | grep containerd
root 1560 1546 0 Jan17 ? 00:09:26 docker-containerd -l unix:///var/run/docker/libcontainerd/docker-containerd.sock --metrics-interval=0 --start-timeout 2m --state-dir /var/run/docker/libcontainerd/containerd --shim docker-containerd-shim --runtime docker-runc
root 1756 1560 0 Jan17 ? 00:00:00 docker-containerd-shim 2a0c08abf30c240c18028ee06a13dc250be047f93a67316f29a8f9153e77705c /var/run/docker/libcontainerd/2a0c08abf30c240c18028ee06a13dc250be047f93a67316f29a8f9153e77705c docker-runc
root 1757 1560 0 Jan17 ? 00:00:00 docker-containerd-shim d5254a9e589d5c48d2e0417b8d694c31b2a5a1536dfd9c48c885d414fe68e250 /var/run/docker/libcontainerd/d5254a9e589d5c48d2e0417b8d694c31b2a5a1536dfd9c48c885d414fe68e250 docker-runc
root 1759 1560 0 Jan17 ? 00:00:00 docker-containerd-shim 9c6fca10612add0ac73e756825c57c222a88582fbe7aad4ff9d0f68904575f38 /var/run/docker/libcontainerd/9c6fca10612add0ac73e756825c57c222a88582fbe7aad4ff9d0f68904575f38 docker-runc
...
```
Broken node:
```
admin@ip-10-146-20-69:~$ ps -fe | grep containerd
root 1763 1 0 Jan17 ? 00:00:00 docker-containerd-shim dd1cb327ebd34c75f96488c45fb0db2f08b297abfa3e002fec56d52f8256f70c /var/run/docker/libcontainerd/dd1cb327ebd34c75f96488c45fb0db2f08b297abfa3e002fec56d52f8256f70c docker-runc
root 1764 1 0 Jan17 ? 00:00:00 docker-containerd-shim 986657c08709d9656c530c59eaa95f26b380847ffb63c3558241c69418097d7c /var/run/docker/libcontainerd/986657c08709d9656c530c59eaa95f26b380847ffb63c3558241c69418097d7c docker-runc
root 1765 1 0 Jan17 ? 00:00:00 docker-containerd-shim 8807a8c3afdc0b4edd2a0d220ea0ed01e492c0e55838c731ab451e50b7285b6a /var/run/docker/libcontainerd/8807a8c3afdc0b4edd2a0d220ea0ed01e492c0e55838c731ab451e50b7285b6a docker-runc
```
Im going to kill that node to get a working one to come up and we can come up with a list of action items in order to enable you guys to address in the future
处理办法，
从k8s cluster 中remove 掉那个有问题的node
后续跟进action：
增加对node上 重要进程containerd的监控
导出kubelet log到elasticsearch
学习到pod调度停留在containercreating状态，有很多种原因造成，需要认真定位，不能乱猜。