Alibaba Cloud Service Mesh:Migração gradual in-place do Istio para o ASM

Etapa 1: Adicionar o cluster ao ASM

Consulte a documentação Add a cluster to an ASM instance e marque a opção "Ignorar verificação do namespace istio-system" ao adicionar o cluster. Isso permite incluir no ASM tanto clusters Kubernetes do Alibaba Cloud com Istio instalado quanto clusters auto-gerenciados registrados no Container Service. Se o cluster ainda não estiver registrado no Container Service, utilize o recurso de registro de clusters do ACK One para registrá-lo e, em seguida, adicione-o ao ASM pelo console do ASM.

Após adicionar o cluster ao ASM, o sistema cria automaticamente o recurso ASMMigrateFromIstio na instância do ASM. Esse recurso controla todo o processo de migração. Execute o comando abaixo para visualizar o conteúdo desse recurso.

kubectl --kubeconfig=${ASM_KUBECONFIG} get asmmigratefromistio

Saída esperada:

apiVersion: istio.alibabacloud.com/v1beta1
kind: ASMMigrateFromIstio
metadata:
  name: default
spec:
  desiredState: Init
  retryCounter: 0
  advancedOptions:
    stopIstioSystemInjectionDisabling: false
status:
  message: ""
  retryCounter: 0
  state: Init

A tabela a seguir descreve alguns dos campos desse recurso.

Transição de estados do ASMMigrateFromIstio

Quando os preparativos da migração permitirem avançar para a próxima fase, altere manualmente o estado do recurso ASMMigrateFromIstio. Por exemplo, se a fase atual for Init, mudar o estado para SetupIstioForMigrate indica o início da próxima etapa.

Veja abaixo exemplos de comandos para transitar entre as fases.

• SetupIstioForMigrate

  kubectl --kubeconfig=${ASM_KUBECONFIG} patch asmmigratefromistio default --type='merge' -p '{"spec":{"desiredState":"SetupIstioForMigrate"}}'

• Migrating

  kubectl --kubeconfig=${ASM_KUBECONFIG} patch asmmigratefromistio default --type='merge' -p '{"spec":{"desiredState":"Migrating"}}'

• Finished

  kubectl --kubeconfig=${ASM_KUBECONFIG} patch asmmigratefromistio default --type='merge' -p '{"spec":{"desiredState":"Finished"}}'

Tomando o estado SetupIstioForMigrate como exemplo, verifique se a transição ocorreu com sucesso da seguinte forma:

kubectl get asmigratefromistio default -o yaml

Saída esperada:

apiVersion: istio.alibabacloud.com/v1beta1
kind: ASMMigrateFromIstio
metadata:
  name: default
spec:
  desiredState: SetupIstioForMigrate
  retryCounter: 0
status:
  message: ""
  retryCounter: 0
  state: SetupIstioForMigrate

Se o valor de status.state for SetupIstioForMigrate, a transição de estado foi concluída com êxito.

Configurações adicionais para clusters com gateway leste-oeste do Istio habilitado

Por padrão, o ASM desativa a injeção automática no namespace istio-system. No entanto, após a criação dos Pods do gateway leste-oeste do Istio, é necessário substituir manualmente suas imagens via MutatingWebhook. Esse recurso exige que a injeção no namespace istio-system não seja explicitamente proibida. Portanto, se o seu cluster possuir gateways leste-oeste habilitados, execute o comando abaixo para impedir que o plano de controle do ASM force a desativação da injeção nesse namespace.

kubectl --kubeconfig=${ASM_KUBECONFIG} patch asmmigratefromistio default --type='merge' -p '{"spec":{"advancedOptions":{"disableIstioSystemLabelReconciliation": true}}}' 

Em seguida, remova manualmente os rótulos que o ASM já sincronizou para o istio-system:

1. Edite a configuração do namespace istio-system.

   kubectl --kubeconfig=${ACK实例kubeconfig文件路径} edit ns istio-system

2. Remova manualmente o rótulo istio-injection: disable, salve e saia.

Etapa 2: Configurar o Istio para a migração

1. Altere o estado para SetupIstioForMigrate.

   Importante

   Após executar este comando, o Istiod reiniciará progressivamente para aplicar as configurações necessárias à migração feitas pelo ASM.

2. Para garantir a comunicação mTLS correta entre o Sidecar do Istio e o Sidecar do ASM durante a migração, o ASM adicionará a seguinte configuração ao Istio nesta fase:

   defaultConfig:
     proxyMetadata:
       PROXY_CONFIG_XDS_AGENT："true"

   Além disso, reinicie manualmente todas as cargas de trabalho que possuem o Sidecar do Istio injetado para aplicar essa configuração. Execute o comando abaixo para verificar se um Pod específico atende ao requisito:

   kubectl get pod ${POD名称} -o yaml|grep PROXY_CONFIG_XDS_AGENT

   Uma saída não vazia indica que a carga de trabalho atende à condição. Quando todas as cargas de trabalho com Sidecar do Istio injetado no cluster cumprirem esse requisito, prossiga para o estado Migrating.

Etapa 3: Iniciar a migração

Esta etapa inicia a fase Migrating. Nela, escolha livremente entre injetar o Sidecar do Istio ou o proxy de malha do ASM nas cargas de trabalho até substituir todos os Sidecars do Istio pelos proxies do ASM.

1. Altere o estado para Migrating. Após entrar com sucesso no estado Migrating, aplique todas as APIs do Istio ao ASM. Em seguida, siga as etapas abaixo para migrar separadamente os Sidecars do Istio, os gateways de entrada, os gateways de saída e os gateways leste-oeste para os componentes correspondentes do ASM.

2. (Opcional) Implante o gateway entre clusters do ASM.

   No ASM, cargas de trabalho com proxy de malha injetado usam automaticamente o gateway entre clusters do ASM para comunicação entre clusters, equivalente ao gateway leste-oeste do Istio. Assim, se você habilitou o gateway leste-oeste, implante o gateway entre clusters do ASM antes de injetar o proxy de malha do ASM em qualquer carga de trabalho. Isso garante que a comunicação entre clusters funcione normalmente após a substituição do Sidecar do Istio.

   Configure o nome de rede correspondente ao cluster no console do ASM, alinhado à configuração de rede atual do Istio. Marque a opção para habilitar o gateway entre clusters nos clusters que já possuem o gateway leste-oeste do Istio implantado. Para mais informações, consulte 为集群指定网络配置，并启用跨集群网格代理.

   Ao ativar o proxy de malha entre clusters, o sistema cria automaticamente um Service do tipo LoadBalancer, gerando custos de instância CLB. Clique em OK após concluir a configuração.

   Nota

   Essa configuração deve corresponder exatamente à do Istio. Por exemplo, se o Istio definiu network-1 para o cluster a e network-2 para o cluster b, o ASM deve manter a mesma configuração.

3. Migre o Sidecar do Istio para o proxy de malha do ASM.

   $ kubectl --kubeconfig=${K8s集群kubeconfig文件路径} -n ${命名空间} patch ${Deployment名称} --type='merge' -p '{"spec":{"template":{"metadata":{"labels":{"sidecar.asm.aliyun.com/inject":"true"}}}}}'

   Importante

   Este comando altera o rótulo da carga de trabalho, provocando uma reinicialização progressiva. A possibilidade de interrupção de tráfego depende do suporte do protocolo da aplicação ao encerramento graceful (HTTP/HTTP2/gRPC), da configuração correta de encerramento graceful no Sidecar do Istio e do comportamento da aplicação (todas as requisições devem retornar dentro do tempo de espera do encerramento graceful). Sempre que possível, execute essa operação em horários de baixa demanda.

4. Migre o gateway de entrada do Istio para o gateway de entrada do ASM.

   Realize a migração suave do gateway de entrada do Istio para o gateway de entrada do ASM. Para instruções detalhadas, consulte Migrate traffic from a self-managed Istio ingress gateway to an ASM ingress gateway.

5. Migre o gateway de saída do Istio para o gateway de saída do ASM. Se o cluster a ser migrado já utilizar gateway de saída, siga os passos abaixo.

   1. Crie um gateway de saída no ASM. Consulte Crie um gateway de saída para mais detalhes. Crie também outros recursos conforme necessário, como ServiceEntry para registrar serviços externos, regras de gateway para habilitar portas de encaminhamento no gateway de saída e serviços virtuais para direcionar o tráfego ao gateway de saída. Veja Gerencie o tráfego de saída para serviços externos para instruções completas.

   2. Modifique o serviço virtual correspondente ao serviço externo a ser migrado para apontar para o gateway de saída do ASM e defina o peso desejado.

      Confira abaixo um exemplo de configuração desse serviço virtual. Para o exemplo completo, consulte Egress gateway for HTTP traffic.

      apiVersion: networking.istio.io/v1
      kind: VirtualService
      metadata:
        name: direct-cnn-through-egress-gateway
      spec:
        hosts:
        - edition.cnn.com
        gateways:
        - istio-egressgateway
        - mesh
        http:
        - match:
          - gateways:
            - mesh
            port: 80
          route:
          - destination:
              host: istio-egressgateway.istio-system.svc.cluster.local
              port:
                number: 80
            weight: 99
          - destination: # 新增一个destination，指向出口网关，并根据需要调整其权重
              host: asm-egressgateway.istio-system.svc.cluster.local # 假设您的ASM出口网关叫asm-egressgateway
              port:
                number: 80
            weight: 1

      Neste YAML, o tráfego destinado a edition.cnn.com é roteado na proporção de 99:1 entre o Istio Ingressgateway e o ASM Egressgateway. Ajuste gradualmente essa proporção conforme necessário até migrar todo o tráfego para o gateway de saída do ASM. Utilize os logs de acesso do gateway de saída do Istio para verificar se ainda há tráfego passando por ele.

Etapa 4: Concluir a migração

Certifique-se de completar todas as tarefas abaixo antes de avançar para a próxima fase da migração.

• Todos os Sidecars do Istio foram totalmente removidos.

• Não há mais tráfego passando pelos gateways leste-oeste, de entrada e de saída do Istio.

• Todas as configurações de API do Istio foram importadas para o ASM.

• As cargas de trabalho com proxy de malha do ASM injetado estão funcionando conforme o esperado.

Após confirmar tudo, use o comando istioctl da versão correspondente para desinstalar o Istio do cluster:

$ istioctl --kubeconfig=${K8s集群kubeconfig文件路径} uninstall --purge

Após a desinstalação, altere o estado para Finished. Se a transição falhar, siga as instruções em status.message para limpar os recursos residuais do Istio. Incremente o valor de spec.retryCounter em 1 e tente novamente até que status.state exiba o estado Finished. Nesse ponto, a migração estará concluída.