久酷

公司的项目的云服务提供方均为阿里云，为了减少运维成本，也基本基于阿里云的产品进行构建。 当然这样做有好处，也有不足，好处是：大大减少了相关产品运维成本更加方便。 不足就是一旦用上了阿里云的这种相关产品以后基本不太可能迁移他处，迁移成本过大。 阿里云的容器服务ACS产品（我们采用的是托管版本），一般半年期一个大版本升级，要持续跟进阿里云的升级进度，否则就会进入非维护期的产品系列了。 不过每次升级其实都是提心吊胆。最近一直提示可更新至1.18.8-aliyun.1版本，遂几个集群逐一开始升级，一般情况是没有问题的。 可今天就出现了幺蛾子。 其中一个集群在升级时死活不行（相同配置的其他集群OK）： 遇到这种情况只能寻求阿里云官方帮助解决，官方的工单服务还是不错的。最终得到的回复是其中一个Node资源不足引起的。 其实整体Node资源占用率仅为30%左右，而CPU一般在10%以下，每个node机器配置为：8核64G，上面业务Pod数10个左右，每个内存资源占用大概2G，很难理解哪块资源会不足，由于情况紧急并未深究此原因，紧急解决之。 最终的解决办法是先取消升级，排空该Node，再重新升级集群解决此问题。 当然阿里云给出的第一套建议是直接从集群中删除此node，升级完成后再添加回来，这个方法基本可以解决100%的node异常问题，但由于我们这节点上手动安装了dns等其他服务无法采用该方式，只能放弃。

问题 在高并发环境时间段，K8S集群中，前端接口应用被强制重启，其中未有异常日志。 环境 项目采用Spring Cloud微服务架构，全部打包docker镜像。 undertow做Web容器 – undertow版本—— 2.0.28.Final。 使用阿里云K8S容器服务部署。 Spring Boot版本——2.2.1.RELEASE。 原因 直接说原因吧，由于undertow web容器，采用了默认配置，没有手动分配线程数，而导致默认线程数过小，系统响应超时，而集群心跳检测时无法响应，认为应用已经挂掉，则强制重启了应用。 默认情况下，undertow的工作线程是以系统获取的CPU个数为基础分配计算的，当CPU数与2取最大值=io-worker，测试了一下，容器内部获取CPU为1，则 io-worker =2。 而workerThreads= ioThreads * 8 ，实际值则为16，一个实例仅16个线程，明显无法满足需求，导致大量等待请求，最终被强制重启。 undertow官方源码可参考如下： https://github.com/undertow-io/undertow/blob/master/core/src/main/java/io/undertow/Undertow.java ioThreads = Math.max(Runtime.getRuntime().availableProcessors(), 2); workerThreads = ioThreads * 8; 解决办法 最简单的办法，则是手动配置workerThreads值，这个是比较重要的参数，根据服务器的配置设置相应的值，一般来说最少128以上吧。

现象 晚上9点半时，接到项目组电话，线上正式环境要进行发布时，自动化流程jenkins一直卡住不动，部分镜像无法推送到中心仓库，项目无法发布。 解决 首先考虑网络原因，目前中心仓库使用的阿里云，部分成功，部分不成功，判断阿里云的网络应该是正常的，ctrl+c 中断，反复重试依旧如此，卡住半个多小时无任何响应，也不报错。 最终尝试重启了一下持续集成服务器的docker，发现一切恢复正常，用这么多年docker头一次出现该现象 ，难道是最新版本的bug?或许吧。