共计 5635 个字符，预计需要花费 15 分钟才能阅读完成。
作者：顾静（子白）|阿里云高级研发工程师；谢瑶瑶（初扬）|阿里云技术专家
导语： 随着云原生理念在企业中的深刻和践行，利用容器化的比例大幅晋升。是否能够保障利用容器化迁徙过程中的安稳切换，保障利用不停机迁徙，成为影响用户业务云化的一个重要条件。本文整顿自阿里云云原生团队在 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 流量转发的行为差别，会间接影响流量迁徙的胜利。因而前置查看是一项十分重要的步骤。
前置查看项都通过后，接下来就是利用的迁徙与流量迁徙。
利用的迁徙能够通过开源组件 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 的灰度能力进行流量迁徙。
那么有没有一种形式，操作简略又能够实现实时无损流量迁徙呢？
如何在零停机的状况下迁徙 Kubernetes 集群
为了解决这个问题，咱们还得从服务裸露形式动手。LoadBalancer 类型的 Service 理论是通过云上负载均衡器对外部裸露服务的。负载均衡器是由各云服务提供商通过部署在集群中的 controller 创立的，创立进去的负载均衡器的信息会显示在 Service 的 status.loadBalancer 字段中。申请拜访云上负载均衡器时，由各云厂商负责将流量重定向到后端 Pod 上。
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，齐全无感。
具体操作如下：首先在 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 负载平衡呢？
对于 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 间能够实现负载平衡。
基于 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 模式解决这一问题。
总结来说，集群迁徙能够分为如下三个步骤，前置查看、利用迁徙及流量迁徙三个步骤。前置查看须要查看不同集群间 api/Node label 等兼容性，利用迁徙能够应用开源工具进行，基于 CCM 则能够实现实时无损流量迁徙。
本次分享到此结束，谢谢。
近期热门
1 月成都连连看：
阿里云容器实际营 & KubeMeet 技术沙龙限额报名中！
阿里云容器服务实际营和 KubeMeet 开源技术沙龙将别离于 2022 年 1 月 13 日 和 1 月 15 日在成都阿里核心天府长岛举办，为你带来容器技术产品实际、开源技术利用案例一站式学习。每场限额 50 人，扫描图片二维码火速报名！
点击 此处 ，理解阿里云容器服务 ACK 更多详情：