新建环境灰度迁移Istio社区版至ASM

当您需要将业务从Istio社区版迁移到服务网格 ASM(Service Mesh),而现有的业务又不允许停止服务时,您可以通过新建ACK集群来对现有服务进行灰度切换。本文介绍如何在不停止服务的前提下将Istio社区版灰度迁移至ASM。

卸载迁移与新建环境灰度迁移

如何迁移Istio社区版本至ASM中,将业务从Istio迁移至ASM采用了先卸载istio,再原地安装配置ASM的方式。在一些无法容忍业务中断的场景中,推荐使用新建集群的方式,通过配置流量入口灰度切换,实现新旧集群并行运行,从而逐步完成迁移。以下是卸载迁移与新建环境灰度迁移的优缺点对比:

迁移类型

优点

缺点

卸载迁移

不需要准备另外一套环境。

要求业务在一定时间内停止服务,配置应用、业务重启和业务验证的操作全部完成后恢复服务。

新建环境灰度迁移

  • 对操作时间没有要求,有充足的准备和验证时间验证新环境。

  • 随时切流,随时回滚。

迁移完成前会同时存在两套相同的应用部署。

步骤一:创建新集群并加入ASM

  1. 创建新集群,您可以根据实际业务需求选择创建ACK托管集群、ACK Serverless集群或ACS集群。具体操作,请参见创建ACK托管集群创建ACK Serverless集群创建ACS集群

    关于ASM支持的集群类型,请参见功能特性。如有其他疑问,请提交工单咨询。
  2. 将新集群加入到ASM实例。具体操作,请参见添加集群到ASM实例

  3. 执行以下命令,将旧集群中的Istio的配置导出。

    kubectl get VirtualService --all-namespaces -o yaml > all-vs.yaml
    kubectl get DestinationRule --all-namespaces -o yaml > all-dr.yaml
    kubectl get Gateway --all-namespaces -o yaml > all-gw.yaml
    kubectl get ServiceEntry --all-namespaces -o yaml > all-se.yaml
    kubectl get EnvoyFilter --all-namespaces -o yaml > all-ef.yaml
    kubectl get Sidecar --all-namespaces -o yaml > all-sidecar.yaml
    kubectl get WorkloadEntry --all-namespaces -o yaml > all-we.yaml
    kubectl get WorkloadGroup --all-namespaces -o yaml > all-wg.yaml
    kubectl get PeerAuthentication --all-namespaces -o yaml > all-pa.yaml
    kubectl get RequestAuthentication --all-namespaces -o yaml > all-ra.yaml
    kubectl get AuthorizationPolicy --all-namespaces -o yaml > all-ap.yaml
  4. 使用ASM实例的kubeconfig,将Istio配置导入到ASM。

    kubectl apply -f all-*.yaml
  5. 如下图所示,将部分应用迁移到新集群后,使用测试流量访问ASM网关验证新集群是否符合预期。

    image

步骤二:验证和切换

新集群测试验证无误后,可以开始通过配置DNS权重将分配至新集群入口的流量逐步提升,并与此同时增加新集群的部署规模,直到将流量完全切换至新集群。

  • 通过DNS权重将部分流量引导至新集群入口,并同时对新集群扩容,以承担更多流量。

    • 若应用行为不符合预期,则将新集群权重设置为0,使得流量仍然全部进入旧集群。

  • 流量完全切换至新集群后,将旧集群保留一段时间,保证能够随时调整DNS权重将流量切换回到旧集群。

image

步骤三:完成切换并下线旧集群

新集群在符合预期的情况下正常工作一段时间后,可以彻底下线旧集群。至此灰度迁移完成。

image

相关操作

通过配置DNS权重将生产流量分别引导到旧集群和新集群,可以实现平滑的灰度迁移。这种方法允许您逐步将流量从旧集群迁移到新集群,同时监控应用性能和用户反馈,确保迁移过程中的稳定性和可靠性。如果您使用的DNS为阿里云云解析DNS,可以根据权重配置进行DNS权重配置。