由于各种财政原因，我管理的集群现在只有两个节点，而且这两个节点是两台物理机。
然后就出现了这样一个图：
大量该集群服务不可用
发现这个问题是因为注意到集群中的大量服务突然不可用。
所有位于其中的Longhorn卷都变成了Degraded状态，大量容器等待重启。
值得注意的是，由于其中一个节点崩溃，Nexus服务也崩溃了，进而导致Docker镜像仓库也不可用。这进一步导致其他服务在重启时无法获取到镜像。
这种影响是全局的，跨集群的。幸运的是，另外两个集群并没有同时立刻需要获取镜像。
闪崩的原因
当前还没有找到闪崩的直接原因。但是从监控数据来看，蓝色节点的内存占用一直超过80%。
再加上我当时触发了两个React项目的构建，可以推断，由于构建恰好被分配到了这个节点，导致该节点的内存完全耗尽。
当内存耗尽时，发生了以下事情（个人推测）：
首先受到影响的应该是Longhorn，因为Longhorn会同步两个节点上的卷。当内存达到极限时，系统负载激增导致一台节点的各方面性能下降，最终导致Longhorn认为某个节点上的卷失去响应。
我隐约记得，Longhorn的处理方式很可能会让这个卷变成只读状态，从而导致所有需要写入硬盘的服务挂掉，如Jenkins、Gitea、Nexus和Postgres等等。
负载不平衡的原因
这是由于定期进行的patch导致的。
首先，需要明确的是，这个集群的每个node都直接对应一个物理机。
与云平台不同，云平台通常会在进行patch时启动一个新的node，并将该node加入到集群，然后再驱逐出一个老的node上的pod，最后将该老node移出集群并销毁。
而对于这个物理集群，无论如何驱逐，最终都需要重启该node。因此，进行一次patch后，无论如何，所有的pod都会移动到其他的node上。
而在当前情况下，该集群只有两台node，这就意味着，当一台node进行更新并重启时，所有的负载都会集中到另一台node上，导致负载极度不平衡。
缓慢的自动恢复
由于大量的Longhorn卷需要恢复，因此在集群开始恢复之后，整个集群的CPU占用率会非常高。同时，由于涉及大量的读写操作，集群的硬盘压力也很大（因成本考虑，硬盘为机械硬盘而非SSD）。
虽然好的方面是，整个集群的自动恢复过程不需要人工干预，但坏的方面是，所有的服务恢复需要花费约一个小时。
当然，这也是因为该集群包含了许多基础设施，导致需要先恢复基础设施后再恢复服务。
如何解决
要解决集群负载不平衡的问题，可以增加一个节点来分担负载。
但更重要的是，为什么不减少这个集群的负载？比如为什么不把部分服务迁移到别的集群（如果这些集群还能承担）？
需要注意的是，这里的讨论前提是每个node都对应着一个物理机。
在这种情况下，我们可以得出这样的结论：对于一个拥有12核24G的集群来说，使用两台6核12G的机器最高的利用率只能到50%，而使用三台4核8G的机器则可以用到66%。也就是说，node越多，硬件资源的利用率上限也就越高。
不过，这种估算并未考虑操作系统本身对内存的占用。如果不考虑这一点，那么把12核24G的集群拆成100个node显然是荒谬的。
更正式结论
负载不平衡的问题背后其实是集群容错率的问题。
当我们考虑需要多少个node时，不仅要考虑是否满足业务需求，还要考虑异常情况。我们需要考虑集群最多能接受多少个node同时down掉，以及如何避免多个node同时down掉。
举个例子，如果我们需要一个8核16G的集群，选择两台6核12G的机器组成集群，那么任何一台node都不能down掉。
反过来，如果选择三台4核8G的机器组成集群，那么理论上可以有一台node down掉。为了确保集群的稳定性，我们需要尽量确保这三台node不在同一地区。
后记
尽管内容相对简单，但这个例子提醒我们一定要动手实操，真正落地。
在创建这个两个node的集群时，我就意识到存在问题。但问题是当时我考虑的不止这一个，以至于我没有意识到这个问题的致命性。
之前我也曾考虑到etcd的问题、Longhorn卷的可用性问题（另外两个集群是3个node存2份）、未来扩展的维护问题，以及patch挂一台的影响等等。
当时我站在的角度认为恢复是自动的，因此Longhorn卷的可用性和扩展是主要的问题。
至于patch时挂一台，当时的考虑是反正可以自动恢复，没必要太纠结。但这不是一个逻辑和理性判断的问题，而是一个价值判断的问题。
只有在真正亲身经历过之后，才能对这些不同的点做出感性的价值判断。
现在站在今天的角度看，Longhorn的可用性其实并不是那么大的问题。因为Longhorn本身只要有一个卷活着就可以正常的读写。问题无非是卷的恢复必须等待node恢复，这个可以通过错开node的patch时间轻松解决。
至于集群的扩展，无非是在扩展时需要将原先做纯worker的node移除，然后重新以etcd和control plane加入即可。
但是patch问题将会在扩展成三节点之前一直困扰着集群，并且由于这个集群主要是负责基础设施，最总我的体验是非常差的。
前后对比：
以前：反正自动恢复，无非等一会儿。
现在：没人愿意再等那一会儿了。