如何在零停机的情况下迁移 Kubernetes 集群-六虎

作者：顾静（子白）｜阿里云高级研发工程师；谢瑶瑶（初扬）｜阿里云技能专家

导语： 随着云原生理念在企业中的深入和践行，运用容器化的份额大幅提升。是否能够确保运用容器化搬迁过程中的平稳切换，确保运用不停机搬迁，成为影响用户事务云化的一个重要条件。本文收拾自阿里如此原生团队在 KubeCon China 2021 线上峰会的共享实录，将经过集群搬迁的需求、场景以及实践方法，介绍怎么依据阿里云容器服务 ACK，在零停机的状况下搬迁 Kubernetes 集群。

大家好，我是谢瑶瑶，来自阿里云，目前是 Cloud-provider 开源子项目 cloud-provider-alibaba-cloud 项目的 Maintainer。今日由我和我的搭档顾静一同为大家共享怎么不停机的搬迁 Kubernetes 集群。顾静同学也是 cloud-provider-alibaba-cloud 项目的 Maintainer。

咱们将从上图几个方面来共享怎么不停机的搬迁 Kubernetes 集群。首要咱们会为大家介绍一下集群搬迁的需求以及运用场景；接着咱们会着重介绍怎么完成不停机地 Kubernetes 集群搬迁，包括怎么进行搬迁前的前置查看，怎么做运用的数据搬迁与流量搬迁等等。

为什么要搬迁 Kubernetes 集群？

下面简略介绍下集群搬迁的运用场景。

容器化的运用迁云

首要咱们来看一下容器化的运用搬迁场景。近年来云原生理念现已逐渐深入到了各大公司中。据相关查询统计，将近有 65% 的运用现已完成了容器化，并逐渐从线下的数据中心搬迁到了云上，以便充分利用云的弹性来完成企业的降本增效。是否能够确保运用容器化搬迁过程中的平稳切换，确保运用不停机搬迁，成为影响用户事务云化的一个重要条件。

跨云同步与搬迁

其次是混合云场景下的跨云流量搬迁。对用户来讲，假如云是一个极具性价比的挑选的话，那么混合云和多云的架构进一步为用户供给了一个低本钱全球可达的运用发布平台。多云能够让用户的运用布置到多个云厂商，防止厂商确定。一起它能够供给更高的议价才能、更强的备份、灾祸康复才能和更强的稳定性。一起还能够为全球用户供给依据地理位置的就近服务体验。怎么进行不停机跨云同步机搬迁是布置跨云/多云运用的前提。

集群新特性与 BreakingChange 场景

更高的 Kubernetes 版别往往会具有更多的新特性，可是运用这些新特性并不是没有价值的。假如你需求运用新特性，那就必须晋级 Kubernetes 到对应的新版别。这一般不是一件容易的事情。假如你的集群版别太低，那么你需求多次晋级集群才干抵达预期的版别。比方从 1.14 顺次晋级到 1.16，然后是 1.18，然后才是 1.20，这样来防止单次晋级集群版别过大形成的兼容性问题。并且这些新特性所引进的兼容性问题还或许形成服务中止。

除了晋级困难以及版别兼容性问题，晋级已有集群无法完成一些装备变更类的需求。比方你无法直接变更一个已有集群的网络形式，比方从 IPTables 切换到 IPVS，Flannel 到 Terway，更改 Cluster CIDR 等。这些变更会形成整个集群已有节点及 Pod 的重建，形成服务不行用，乃至是整个集群装备被污染。因而不中止搬迁 Kubernetes 集群运用在这种状况下或许是一个更好的挑选。

接下来咱们介绍一下怎么进行不停机搬迁。不停机搬迁总体上分为 3 个阶段。

第一阶段：前置查看，提早露出搬迁或许存在的潜在危险；第二阶段是运用搬迁，这一阶段需求新建一个方针版别的集群，并将运用及其数据搬迁到新的集群中；第三阶段是流量搬迁，这一阶段至关重要，他决定了怎么不停机地将线上流量导入到新建的集群中，并运用新建的集群为用户供给服务。

首要在前置查看阶段，咱们需求尽早的露出搬迁危险，因而咱们开发了一套前置查看框架，用来查看集群是否做好了搬迁预备。比方不同版别的集群会有 API groups 兼容性，需求提早处理 Label 的兼容性，不同版别的组件的行为差异等，如 kubeproxy 处理 SLB 流量转发的行为差异，会直接影响流量搬迁的成功。因而前置查看是一项非常重要的过程。

前置查看项都经过后，接下来便是运用的搬迁与流量搬迁。

图片 8.png

运用的搬迁能够经过开源组件 Velero 进行，官方有详细的文档来说明运用的搬迁，阿里云也专门为其提交了阿里云相关驱动。这里咱们首要介绍一下怎么做数据搬迁，数据搬迁是完成不停机搬迁的重要一环，咱们会以磁盘存储和有状况运用 MySQL/ETCD 的搬迁为例，来说明怎么进行数据的搬迁。

一般云上的存储首要有 NFS、OSS 对象存储、CloudDisk 云盘等，一般各大云厂商都为磁盘类型的存储供给了完善的快照办法及康复办法。上图展示了怎么将上海 Region 的运用数据搬迁到杭州 Region 的办法，关于磁盘存储类型，首要在上海 Region 构建磁盘快照，然后将快照经过云厂商的网络同步到待康复的地域杭州，然后经过快照康复功能创立一块磁盘，然后挂在到节点上后运用即可随时运用。

关于自建 MySQL/ ETCD 一类的运用数据，因为其持续读写或许形成潜在的数据不共同的状况，咱们能够经过为该运用在方针 Region 构建多个 Slave 副本（或许 quorum 副本），用来进行实时数据同步，当流量低峰期到来的时候，履行主从切换，或许强制选主流程。一旦方针 Region 选主完成，则代表切换完成，能够逐渐下线原 Region 的 MySQL 或 ETCD 副本。这便是一个简略的数据搬迁流程。

接下来介绍一下流量搬迁部分。流量搬迁是集群搬迁中十分重要的环节。流量搬迁是指在事务流量无中止的前提下，将事务流量从一个集群搬迁到另一个集群中去。客户端对流量搬迁应当完全无感。

DNS 是完成无损流量搬迁的一种方法。分别在两个集群中创立两个 LoadBalancer 类型 Service，然后将两个 SLB 添加到 DNS 后端，依据 DNS 的灰度才能完成流量分发到两个不同的集群中。这种方法较为简略，可是有一个比较大的缺陷，DNS 缓存有过期时间，流量切换后需求等待 30 分钟左右才干生效。当在新集群中进行事务回滚时，这个延迟不行承受的。

别的一种流量搬迁方法是依据 Istio 完成的。Istio 方法比较复杂，学习本钱比较高。需求新建一个 Istio 集群，并且更改已有的运用布置方法，然后依据 Istio 的灰度才能进行流量搬迁。

图片 11.png

那么有没有一种方法，操作简略又能够完成实时无损流量搬迁呢？

怎么在零停机的状况下搬迁 Kubernetes 集群

为了处理这个问题，咱们还得从服务露出方法入手。LoadBalancer 类型的 Service 实践是经过云上负载均衡器对外部露出服务的。负载均衡器是由各云服务供给商经过布置在集群中的 controller 创立的，创立出来的负载均衡器的信息会显现在 Service 的 status.loadBalancer 字段中。恳求拜访云上负载均衡器时，由各云厂商担任将流量重定向到后端 Pod 上。

图片 12.png

Cloud Controller Manager（CCM）便是阿里云容器服务布置在 Kubernetes 集群中的 controller，担任对接 Kubernetes 资源及云上基础产品，如 SLB、VPC、DNS 等。关于 SLB，CCM 支撑两种流量转发方法，一种是 ECS 形式，一种是 ENI 形式。ECS 形式将 Node IP 和 NodePort 挂载到 SLB 后端，流量经由 SLB 转向 Node，然后经过节点的 kube-proxy 转发至 Pod 上。ENI 形式将 PodIP 及 TargetPort 挂载到 SLB 后端，流量经由 SLB 直接转发到 Pod 上。与 ECS 形式比较，ENI 形式少了一层网络转发，网络性能更好。流量转发形式与 Kubernetes 中网络插件有关，Flannel 网络插件默以为 ECS 形式，Terway 网络插件默以为 ENI 形式。

那么 CCM 是怎么办理 SLB 的呢？

关于 LoadBalancer 类型的 Service，CCM 会为该 Service 创立或装备阿里云负载均衡 SLB。CCM 首要会查询 Kubernetes Service 信息，构建 Local model，然后查询 SLB 信息，构建 Remote model。对比两个 model 的差别，依据 Local model 更新 Remote model，直到两个 model 共同。当 Service 对应的 Endpoint 或许集群节点发生变化时，CCM 会自动更新 SLB 的虚拟服务器组中的后端。此外，CCM 还供给了许多阿里云特定注解，支撑丰厚的负载均衡才能。

当用户拜访 service 时，假如在集群内部，经由 service 转发至 Node，经过 kube-proxy 转发到 Pod。假如拜访负载均衡 ip 时，则经过 SLB 后转发至节点 Node 或许 Pod上。

了解 LoadBalancer service 工作原理后，能不能经过 CCM 完成实时无损流量搬迁呢？答案是能够的。将两个集群的节点加入到同一个 SLB 的同一个端口中，然后经过修改两个集群所占权重即可完成流量搬迁。关于客户端来讲，拜访的仍然是曾经的 SLB ip 和 port，完全无感。

图片 15.png

具体操作如下：首要在 1.14 集群中创立一个 Service，指定已有 SLB 及端口，以及端口相关的虚拟服务器组。然后在 1.20 集群中创立一个 Service，指定相同的 SLB、端口及虚拟服务器组。经过 weight annotation 为两个集群设置权重。

装备完成后，流量转发方法如上图所示。有 80% 的流量转发到 1.14 集群中，20% 的流量转发到 1.20 集群中。

两个集群共用 SLB 的同一个端口。经过修改 Service 中的 weight annotation 能够动态实时修改流向两个集群的流量份额，完成灰度流量搬迁。当搬迁完成后，从 1.14 集群中删去 Service 即可。

设置权重 annotation 后，怎么确保集群内 Pod 负载均衡呢？

图片 20.png

关于 externalTrafficPolicy 为 Cluster 的 service，CCM 会将一切节点加入到 SLB 后端。每个节点的权重为 weight/NodeNum。此刻，Node1，Node2，Node3 权重均为 27，可是三个节点上的 Pod 数量并不均衡，那么怎么完成 Pod 负载均衡呢？Cluster 形式是依靠 kube-proxy 完成的。在 cluster 形式下，kube-proxy 会将一切 Pod 信息写入到本地的转发规则中，并以轮训的方法向这些 Pod 转发恳求。以 Node3 为例，该节点上没有 Pod，当恳求发送到 Node3 节点后，kube-proxy 会将恳求转发给 Node1 或许 Node2。

关于 externalTrafficPolicy 为 Local 的 service，CCM 仅会将 Pod 所在节点加入到 SLB 后端。因为假如节点没有 Pod，当恳求转发至该节点时，恳求会被直接丢弃。Local 形式下，需求先核算每个 Pod 的权重，即 PerPodWeight=Weight/TotalPodNum。节点权重为 NodePodNum*PerPodWeight。Node1 为 50，Node2 为 30。因为每个 Pod 的权重都为 10，因而 Pod 间能够完成负载均衡。

图片 21.png

依据 CCM 的流量搬迁方案不仅适用于云上集群搬迁，还适用于混合云、跨 Region 搬迁及跨云搬迁场景。以混合云场景为例，客户能够将线下 ECS 加入到 SLB 后端，然后经过设置权重逐渐将流量从线下集群搬迁到线上集群中，无需进行事务改造，客户端也是完全无感的。

在新集群中测验时不行防止的会遇到运用更新的场景。假如确保运用更新的过程中流量无损呢？

运用更新分为两个过程，创立新的 Pod，等待 Pod running 后，删去旧的 Pod。新的 Pod 创立成功后，CCM 会将其挂在到 SLB 后端，假如新建的 Pod 无法供给服务，那么恳求就会失利。因而，需求为 Pod 添加就绪检测。仅当 Pod 能够对外服务时，才将其加入到 SLB 后端。在删去 Pod 时也会遇到相同的场景。因为 Pod 删去和从 SLB 后端移除 Pod 是异步进行的，假如 Pod 以及删去，可是还未从 SLB 后端移除，就会呈现恳求转发到后端，可是无 Pod 处理导致恳求失利的状况。因而需求为 Pod 添加 prestop hook。

Pod 优雅退出过程如上图所示。首要 kubelet delete pod，然后 endpoint controller 更新 endpoint。更新完毕后，kube-proxy 移除节点转发规则。CCM 检测到 endpoint 更新事情后，从 SLB 后端移除 Pod。在apiserver 删去 Pod 时，kubelet 一起开始删去 Pod 逻辑，触发 Pod prestop。在 prestop 结束后发送 sigterm 信息。在整个 Pod 优雅退出过程中，直到 CCM 从 SLB 后端移除 Pod 之前一直会有新的流量进入。

因为 CCM 与 kube-proxy 是异步进行的，因而会呈现 SLB 还未移除 Pod，kubeproxy 现已将节点转发规则清理的状况。此刻，恳求进入 SLB 后，转发至 Node上，因为 kube-proxy 现已将路由规则清理了，所以该恳求无法处理。将 service 改为 cluster 形式能够处理这一问题。假如 Service 一定需求为 local 形式，那么需求确保一个节点上有多个 Pod。也能够经过设置 Service 为 eni 形式处理这一问题。