我希望帮助正在准备或正在使用Kubernetes的小伙伴。
使用Kubernetes时要注意的要点
滚动升级更新太慢
默认情况下，滚动升级会逐个更新。当有数十个Pod需要更新，加上准备检测时，整个过程将会变慢。如果你想与更多Kubernetes技术专家沟通，你可以加我WeChat liyingjiese，注意“添加组”。每周都有来自世界各地主要公司的最佳实践和行业更新。
解：
rollingUpdate:
maxSurge: 20％＃每次滚动更新的实例数
maxUnavailable: 10％＃允许在更新过程中有多少实例不可用
无损更新的可读检测
通常，当服务重新启动时，服务不可用的时间很短。
为避免在此过程中请求的流量进入，我们可以使用就绪检测来检查服务是否已准备好接收和处理请求。
..
readinessProbe:
httpGet:
主机: api.xxx.com
路径: /
端口: 80
initialDelaySeconds: 3＃第一次测试在容器启动3秒后开始
periodSeconds: 60＃每60秒检测一次
timeoutSeconds: 3＃http检测请求超时
successThreshold: 1＃检测到有1次成功，该服务被认为已准备就绪。
failureThreshold: 1＃检测到有1次失败，该服务被认为是“未准备好”
..准备测试全系列
准备检测是一把双剑，但很容易出现大问题，例如全面服务。
我们可以看到上面的准备检测测试的配置，它充满了漏洞。
例如：超时，高并发，请求无法处理，个别服务很容易导致检测请求超时（504），立即认为没有准备好，所以流量转移到其他服务，然后其他服务已经高负荷同样的情况，一个恶性循环，很快，所有服务都被认为没有准备好，导致完全瘫痪。
解决方法：设置更长的超时和更多的故障。
重新部署，这可能是一个误操作，或者可能是其他异常导致服务挂起。简而言之，您需要在用户仍在尝试请求您的服务时重新启动。您会惊讶地发现它无法在就绪状态下正常启动并且所有服务都没有准备好。出于同样的原因，服务启动过程并不是一次性完成，而是一批一批地启动，因此每批服务在启动后都无法保持流量，因此它仍然是一个恶性循环，充满了缺陷。
解决方案：删除就绪检测，然后重新部署。
瞬时自动扩展峰值
POD的自动扩展很容易使用，但是如果扩展指示器（CPU，内存等）设置得太高，例如：50％或更多，那么当突然加倍流量时，就没有时间来扩展Pod，服务直接超时。或挂断电话。
解决方案：尽可能将指标设置为较小的值，并对先前的流量进行参考评估，确保当有2倍，3倍甚至5倍的流量突袭时，它将无法保持。
自动扩展和扩展
通常，节点的自动缩放取决于Pod自动扩展时资源是否足够。然而，面对时间紧迫的交通高峰，这种缩放显然为时已晚。即使是仅在高峰流量10分钟后扩展的机器也已经回到底部，这完全是无效的。而且，流量真的是由于业务属性的快速下降，还是由于缺乏及时扩展造成的损失？
解决方案：根据自己的业务，参考实时流量和促销时间，查找规律，提前触发自动扩展或定时。
容器运行僵尸进程
这是Docker旧版本（

• 上一篇: 蓝盟IT外包，元宇宙：四梁八柱是什么
  下一篇: 在5G时代，WiFi被淘汰还是变得更强大？

• 分享到：