滚动发布卡在一个节点上的时候

一句话总结

恶魔阵的maxUnavailable: 1如果一个节点无法启动新的分区，**就不会触动其他节点，而是保持原样停止。**这不是错误，而是约定，结果群集将以旧设置节点和新设置节点分开。

为什么一个节点会让整个系统停止？

想想反面，就会得出答案。新规格错了，但如果恶魔阵不停地推进的话会怎么样。七个GPU节点全部同时死亡。滚动更新的目的是不是为了尽快结束，而是将错误变更的爆炸半径固定为一个。所以恶魔阵会更换一个，等待那个帕德准备好，如果准备不好就永远等待。

问题在于这次停工很安静。kubectl get ds看起来是这样的。

NAME                       DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE
nvidia-container-toolkit   3         3         2       1            2

不是错误。也没有红色字。READY 2/3乍一看可以读作“几乎都完成了”。但是这个表所说的却是群集分裂成了两代的事实。一台不能显示新的规格，两台仍然保持着旧规格。如果像GPU设置一样，如果是修改节点文件的守护程序，那么这个状态意味着“每个节点都有不同的运行时设置的群集”。

怎么行动

恶魔阵列的滚动更新按节点计算。

1. 再选择一个旧规格的节点。
2. 首先擦除该节点的缓存。
3. 制作新的规格的板。
4. 等待那个帕德可以使用为止。
5. maxUnavailable如果再次恢复到这样的自由度，它将回到第1个位置。

如果第3次新帕德无法安排日程，第4次就不能结束，第5次永远不会到来。重要的是第2次比第3次早——停止的节点既没有旧帕德，也没有新帕德，而是处于空的状态。

新派德不显示的原因通常是其中三个之一。没有收到图像，无法访问节点请求的资源，或容差·节点选择器不一致。前两个是派德Pending或者ImagePullBackOff留下罗，最后性格不同——如果容忍度不一致，恶魔控制器会完全判断“这个节点不能有帕德”，并从目标中删除，DESIRED数字本身减少。虽然看起来像同样的症状，但要看的地方不同。

kubectl rollout status ds/...在这种状态下就直接挂住。如果CI管道中没有此命令，则需要1个小时才能抓到。--timeout一定要给。

在现场相遇的样子

**第一，通知是numberUnavailable罗建达。**恶魔阵几分钟以上desiredNumberScheduled != numberReady如果保持状态，人必须看。通过pad重新启动次数或错误日志无法捕获此停止——因为什么都不重新启动，也没有任何错误。

**第二，养成确认分裂世代的习惯。**查看每个节点实际运行的哪些规格的最快方法是同时查看帕德的图像和节点。UP-TO-DATE光看数字就无法知道哪个节点落后了，在GPU设置中，那个“哪个节点”就是故障范围。

**第三，回溯往往比前进快。**在修复新规格没有显示的原因时，一个节点仍然空着。kubectl rollout undo恢复旧规格，将三个节点恢复到同一状态，然后再寻找原因，在事故应对中，首先要做的不是诊断，而是将状态统一起来。

下次实习要做的事情

紧接着在实训中将分开使用的三种方式设定为设定和对象进行处理。将设备插件设置命名并保存成多套，用节点标签选择使用，MIG节点因为资源名称本身不同，通过调度确认旧文件夹无法使用该节点，并按季度分配给团队的份额。部署停止的样子在该课程的最后一个实训中再次见面。