使用时需要注意的坑点

检测的配置，漏洞百出。

比如：超时，高并发情况下，请求处理不过来，个别服务很容易导致检测请求的超时(504)，立马被认为未就绪，于是流量被转移到其它服务，进而让本来就高负荷的其它服务出现同样情况，恶性循环，很快，所有服务都被认为是未就绪，结果产生全面瘫痪现象。

解决方法：设置更长的超时时间，以及更高的失败次数。

重新部署，这种情况可能是误操作，也可能是其它异常导致服务挂了。总之，你需要在用户还在不断尝试请求你服务的时候重启。你会惊讶的发现，一直无法正常启动为就绪状态，所有服务都是未就绪。同样的原因，服务启动过程不是一次全部起来，而是逐批启动，这样每批服务启动后都无法hold住流量，于是还是恶性循环，全面瘫痪。

解决方法：先去掉就绪检测再重新部署。

自动扩展之瞬时高峰

自动扩展POD虽然好用，但如果扩展的指标(CPU、内存等)设置的过高，如：50%以上，那么，当突然有翻倍的流量过来时，根本来不及扩展Pod，服务直接就超时或挂掉。

解决方法：尽可能的把指标设置在一个较小的值，对以往流量做参考评估，确保了当有2倍、3倍甚至5倍的流量突袭时不至于hold不住。

自动伸缩之提前扩容

通常，节点的自动伸缩依赖于Pod的自动扩展时资源是否充足。然而在面对定时突然流量高峰的业务时，这种伸缩显然来不及，甚至常常出现高峰10分钟后才扩容的机器，流量已经回到低谷，完全启不到作用。并且，流量到底是因为业务属性很快回落，还是因为扩容不及时导致的流失?

解决方法：根据自身业务，参考以住流量数量及推广时间，找到规律，提前或定时触发自动扩容。

容器运行之僵尸进程

这是一个Docker旧版(<1.13)已知问题，有些容器启动后会出现defunct进程(ps aux | grep defunct)，而且会越来越多，称为僵尸进程，可能导致内存泄漏，而且kill不掉，除非重启容器。

（编辑：应用网_丽江站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!