### 滚动升级 之 `更新太慢` > 默认情况下，滚动升级是逐个更新的，当有几十上百个POD需要更新时，再加上`就绪检测`，整个过程将会更慢。 * * * 解决方法： ~~~js rollingUpdate: maxSurge: 20% #每个滚动更新的实例数量 maxUnavailable: 10% #允许更新过程中有多少实例不可用 ~~~ * * * ### 就绪检测 之 `无损更新` > 通常，服务重启的时候会有一小段时间是`无法正常提供服务`的。 为了避免这个过程中有请求的流量进来，我们可以使用`就绪检测`来检测服务是否就绪可正常接收并处理请求。 ~~~js ...... readinessProbe: httpGet: host: api.xxx.com path: / port: 80 initialDelaySeconds: 3 # 容器启动3秒后开始第一次检测 periodSeconds: 60 # 每隔60s检测一次 timeoutSeconds: 3 # http检测请求的超时时间 successThreshold: 1 # 检测到有1次成功则认为服务是`就绪` failureThreshold: 1 # 检测到有1次失败则认为服务是`未就绪` ...... ~~~ * * * ### 就绪检测 之 `全面瘫痪` > 就绪检测是把双利剑，用不好，反而容易出大问题，比如服务全面瘫痪。 我们可以看到上面`就绪检测`的配置，漏洞百出。 * * * 比如： * 超时 > 高并发情况下，请求处理不过来，个别服务很容易导致检测请求的超时（504），立马被认为`未就绪`，于是流量被转移到其它服务，进而让本来就高负荷的其它服务出现同样情况，恶性循环，很快，所有服务都被认为是`未就绪`，结果产生`全面瘫痪`现象。 * * * 解决方法： > 设置更长的超时时间，以及更高的失败次数。 * 重新部署 > 这种情况可能是误操作，也可能是其它异常导致服务挂了。总之，你需要在用户还在不断尝试请求你服务的时候重启。你会惊讶的发现，一直无法正常启动为`就绪`状态，所有服务都是未就绪。同样的原因，服务启动过程不是一次全部起来，而是逐批启动，这样每批服务启动后都无法hold住流量，于是还是恶性循环，`全面瘫痪`。 * * * 解决方法： > 先去掉就绪检测再重新部署。 * * * ### 自动扩展 之 `瞬时高峰` > 自动扩展POD虽然好用，但如果扩展的指标（CPU、内存等）设置的过高，如：50%以上，那么，当突然有翻倍的流量过来时，根本来不及扩展POD，服务直接就超时或挂掉。 * * * 解决方法： > 尽可能的把指标设置在一个较小的值，对以往流量做参考评估，确保了当有2倍、3倍甚至5倍的流量突袭时不至于hold不住。 * * * ### 自动伸缩 之 `提前扩容` > 通常，节点的自动伸缩依赖于POD的自动扩展时资源是否充足。然而在面对定时突然流量高峰的业务时，这种伸缩显然来不及，甚至常常出现高峰10分钟后才扩容的机器，流量已经回到低谷，完全启不到作用。并且，流量到底是因为业务属性很快回落，还是因为扩容不及时导致的流失？ * * * 解决方法： > 根据自身业务，参考以住流量数量及推广时间，找到规律，提前或定时触发自动扩容。 * * * ### 容器运行 之 `僵尸进程` > 这是一个docker旧版（`<1.13`）已知问题，有些容器启动后会出现defunct进程（ps aux | grep defunct），而且会越来越多，称为`僵尸进程`，可能导致内存泄漏，而且kill不掉，除非重启容器。 * * * 解决方法： [tini](https://github.com/krallin/tini) * * * ### 集群节点 之 `移除节点` > 如何安全地移出节点？这个节点上面部署了你的业务，甚至包括kube-system的东西。 * * * 解决方法： [kubectl drain](https://kubernetes.io/docs/tasks/administer-cluster/safely-drain-node/)，可以先把节点上的POD驱逐到其它节点，然后再移出该节点。 --- 原文链接:[https://0x9.me/V37i5](https://0x9.me/V37i5)