在软件升级领域，有两种主流的软件升级方式，即原地升级和替换升级。这两种升级方式同样适用于Kubernetes集群。这两种方式采用了不同的思路，存在着各自的利弊。下面我们对这两种集群升级方式及其优缺点展开讲解。
原地升级会通过在ECS上原地替换Kubernetes组件的方式完成整个集群的升级工作，阿里云容器服务Kubernetes为客户提供的集群升级就是基于这种方式的。
以1.14版升级到1.16版为例，我们会通过直接升级节点上的Kubelet及其配置的方式，将集群所有节点升级到1.16版。在这个过程中节点保持运行，ECS的相关配置也不会被修改，如图12-2所示。
图12-2 集群原地升级
原地升级的优点在于，通过原地替换的方式对节点进行升级，保证了节点上的Pod不会因为集群升级而重建，确保了业务的连贯性。该种升级方式不对底层ECS进行修改和替换，保证了依赖特定节点调度的业务可以正常运行，也对ECS的包年、包月客户更加友好。
原地升级的缺点在于，需要在节点上进行一系列升级操作，才能完成整个节点的升级工作。这就导致整个升级过程不够“原子化”，可能会在中间的某一步失败，从而导致该节点升级失败。原地升级的另一个缺点是需要预留一定量的资源，只有在资源足够的情况下升级程序才能在ECS上完成对节点的升级。
替代升级又称轮转升级。替代升级会逐个将旧版本的节点从集群中移除，并用全新的新版本节点来替换，从而完成整个Kubernetes集群的升级工作。
同样以1.14版升级到1.16版为例，用替代轮转方式，我们会将集群中1.14版的节点依次进行排水（drain）并从集群中移除，并直接加入1.16版的节点。完成所有节点的轮转之后，整个集群就升级到1.16版了，如图12-3所示。
图12-3 集群替代升级
替代升级的优点在于，通过将旧版本的节点替换为新版本的节点从而完成集群升级。这个替换的过程相较于原地升级更为“原子化”，也不存在那么复杂的中间状态，所以也不需要在升级之前进行太多的前置检查。
替代升级的缺点在于，将集群内的节点全部进行替换和重置，所有节点都会经历排水的过程，这就会使集群内的Pod大量迁移重建。在对Pod重建容忍度比较低的业务中可能会引发故障。另一个缺点为节点经历重置后，储存在节点本地磁盘上的数据都会丢失。最后就是这种升级方式可能会带来宿主机IP地址变化等问题，对包年、包月用户也不够友好。