kubernetes关于eks一次异常问题的复盘
背景：
海外新加坡有一套aws的 eks集群，很小的规模 托管的 三节点（172-31-16-189节点为最近才加的，忽略）：
[root@ip-172-31-10-1 ~]# kubectl get nodes
NAME STATUS ROLES AGE VERSION
ip-172-31-16-189.ap-southeast-1.compute.internal Ready <none> 44h v1.23.9-eks-ba74326
ip-172-31-17-92.ap-southeast-1.compute.internal Ready <none> 110d v1.23.9-eks-ba74326
ip-172-31-3-165.ap-southeast-1.compute.internal Ready <none> 111d v1.23.9-eks-ba74326
ip-172-31-32-5.ap-southeast-1.compute.internal Ready <none> 111d v1.23.9-eks-ba74326事情经过是这样的12月28日更新镜像，172-31-17-92节点出现了一次镜像ImagePullBackOff,由于我镜像仓库位于国内我当时怀疑是网络问题，将镜像修改tag 上传到了dockerhub仓库，but 在宿主机操作docker pull 上传到dockerhub的镜像依然是pull不动，索性 restart了一下docker and kubelet 重新下载成功了......祸根就从这里埋下了。春节放假又出现了两次异常。后面找aws的小伙伴帮忙一起看了一下复盘了一下。这里记录一下！
kubernetes关于eks一次网络问题的复盘
出现的异常现象
- docker image镜像无法下载
- 节点上pod 无法连接内网域名（包括集群内svc地址and aws 数据库redis域名),ping 没有任何返回。看连接kafkaf服务的日志出现Failed to resolve 'b-2.xxxxx.xxxxx.c3.kafka.ap-southeast-1.amazonaws.com:9096': Try again (after 5001ms in state CONNECT, 4 identical error(s) suppressed)。mysql服务也出现连接失败的错误MySQL异常：SQL state HY000； error code 2002 如下：
- eks自有组建都在不停的重启,比较明显的服务有aws-node ebs-csi-node,还有我搭建的traefik代理组件
kubectl get pods -n kube-system分析以及解决过程
查看eks系统组件报错
kubectl describe pods aws-node-zx4sb -n kube-system重点关注词：
Last State: Terminated
Reason: Error
Exit Code: 137
也顺便看了一些kube-proxy，日志有一下报错：
service log of the node: Failed to ensure chain exists" err="error creating chain \"KUBE-EXTERNAL-SERVICES\": fork/exec /usr/sbin /iptables: resource temporarily unavailable: " table=filter chain=KUBE-EXTERNAL-SERVICES
traefik ebs-csi-node组件不断重启，不能正常运行，拿这两个组件尝试了一下 delete 异常节点上的traefik ebs-csi-node组件，等待pod重新running后再无异常
这里的重点关注词：
resource temporarily unavailable
注： aws-node 并未手动杀死
登陆异常节点查看日志：
journalctl |grep kubelet肉眼扫了一眼一些异常1月21日的报错日志：
failed to create new OS thread (have 6 already; errno=11)\nruntime: may need to increase max user processes (ulimit -u)
搜索关键词解决问题
找到这个关键词max user processes
执行了一下ulimit -a
max user processes (-u) unlimited
unlimited是指不限制用户可以使用的资源, 但这个设置对系统可打开的最大文件数(max open files)和各个用户可同时运行的最大进程数(max user processes)无效
参照谷歌搜索
The maximum user processes (nproc) limit on Linux counts the number of threads within all processes that can exist for a given user. The default value of nproc is 1024 on some versions of Linux, which is generally an insufficient number of threads for all processes
那默认值是1024.......，后之后觉查一下进程数：
ps ux|wc -l当前是400多个，扫一遍程序,参照https://aws.amazon.com/cn/premiumsupport/knowledge-center/eks-failed-create-pod-sandbox/：
ps ux | awk '{if($8=="Z") print}' ps ux | awk '{if($8=="Z") print}'|wc -lwhat 才更新了几天的程序有两个多个僵尸进程？扫了一眼：一个截图的game-screenshot 的nodejs程序造成的.....之前为什么没有......11月份他们改了程序方式....总算找到了罪魁祸首，僵尸进程没有处理....长时间运行是会出现更多的僵尸进程....那国内为什么没有出现过这个问题呢？带着疑惑看了一眼我的阿里亚ack集群：
ps ux | awk '{if($8=="Z") print}'|wc -l有500多个僵尸进程....但是确实没有出现过这样的问题，看一眼ulimit -a
顺便扫一眼腾讯云TKE
注：机型配置不一样，参数会有所区别，但是max user processed这个参数国内云商确实优化了.....先忽略1024的那么小的配置....找到写程序的小伙伴，连夜让他把代码改了......
吐槽：
- case工单提交了一天 完全没有人鸟.....账号还是国内某大厂的。最后找到了国内aws团队的小伙伴（最近正好又业务往来），给加速了一下，并帮分配到了台湾的工程师帮忙排查问题。当前状态下，国外电话打进来都自动被屏蔽了，联系很不方便。web 体验了一下Amazon Chime.....也断线了好几次。台湾工程师交流起来还是不习惯，太流程化.....文化差异吧哈哈。https://aws.amazon.com/cn/premiumsupport/knowledge-center/eks-failed-create-pod-sandbox/也是台湾工程师给提供的！
- 我使用托管服务默认觉得云商对系统参数都进行了优化....起码国内的 腾讯云 阿里云都这样做了。系统的参数很多都可以不用去关心调整。第一次使用aws我也想当然以为这样了，出了这问题我才发现其实并不是这样的，台湾的工程师也一直给我解释，他们是让用户差异化初始机器的时候自己设置......那我用什么EKS 我自己搭建一个kubeadm的集群不好了......当时着急搭建， 我是直接梭哈跑起来的....还被各种IAM摧残......
- 其实看到resource temporarily unavailable报错的时候就应该想到最大进程数了...这个问题我真的没有想到过.....因为初始化系统的时候个人都会把这些参数优化了....太理所当然的以为云商进行了优化了......
自己搭建集群好歹也记得把这些limit设置了.....
- 感谢国内AWS团队小伙伴的帮助
加载中,请稍侯......
网友评论