Migre de um gateway de entrada Istio autogerenciado para um gateway de entrada do Service Mesh (ASM) sem tempo de inatividade. Este procedimento utiliza uma instância compartilhada do Classic Load Balancer (CLB) para transferir o tráfego gradualmente entre os dois gateways por meio de anotações de serviço baseadas em peso.
Como funciona
Tanto os gateways de entrada do Istio quanto do ASM registram seus pods como servidores de backend nos mesmos grupos de vServer do CLB. O CLB distribui o tráfego recebido com base nos valores de peso definidos nas anotações de serviço do Kubernetes. Durante a migração, aumente gradualmente o peso do gateway ASM e diminua o peso do gateway Istio até que todo o tráfego flua pelo ASM.

Pré-requisitos
Antes de começar, verifique se você possui:
Um gateway de entrada Istio autogerenciado em execução no seu cluster Container Service for Kubernetes (ACK)
Uma instância do ASM associada ao cluster ACK
Acesso ao console do CLB
Permissões para modificar recursos de Serviço do Kubernetes e configurações de instância do CLB
Etapa 1: Tornar a instância do CLB reutilizável
A instância do CLB criada pelo Serviço do gateway de entrada Istio não é reutilizável por padrão. Para permitir que ambos os gateways compartilhem a mesma instância do CLB, reconfigure-a da seguinte forma:
Faça login no console do CLB, localize a instância do CLB usada pelo gateway de entrada Istio e clique em seu ID de instância para abrir a página de configuração.
Desative o modo somente leitura de configuração da instância.
-
Remova as duas tags a seguir da instância do CLB:
kubernetes.do.not.deleteack.aliyun.com
-
Adicione as seguintes anotações ao Serviço do gateway de entrada Istio: Substitua os espaços reservados pelos seus valores reais: Exemplo:
Encontre os IDs dos grupos de vServer na página de gerenciamento da instância do CLB, na aba vServer Group .
Espaço reservado
Descrição
Exemplo
<your-clb-instance-id>ID da instância do CLB
lb-bp1onpskfeceg********<vserver-group-id>ID do grupo de vServer no console do CLB
rsp-bp1r4xk******<port>Porta do listener
80,443,15021annotations: service.beta.kubernetes.io/alibaba-cloud-loadbalancer-force-override-listeners: "false" service.beta.kubernetes.io/alibaba-cloud-loadbalancer-id: <your-clb-instance-id> service.beta.kubernetes.io/alibaba-cloud-loadbalancer-vgroup-port: <vserver-group-id>:<port>,<vserver-group-id>:<port> service.beta.kubernetes.io/alibaba-cloud-loadbalancer-weight: "100"annotations: service.beta.kubernetes.io/alibaba-cloud-loadbalancer-force-override-listeners: "false" service.beta.kubernetes.io/alibaba-cloud-loadbalancer-id: lb-bp1onpskfeceg******** # List all vServer groups of the CLB instance. Format: <vserver-group-id>:<port> # Separate multiple entries with commas. service.beta.kubernetes.io/alibaba-cloud-loadbalancer-vgroup-port: rsp-bp1r4xk******:15021,rsp-bp1kaqd******:80,rsp-bp1jyz0******:443 # Weight 100 means all traffic goes to the Istio ingress gateway. service.beta.kubernetes.io/alibaba-cloud-loadbalancer-weight: "100"
Verificar
Abra o console do CLB, acesse a instância do CLB e confirme se os endereços dos pods do gateway de entrada Istio aparecem na lista de servidores de backend do grupo de vServer.
-
Execute o comando a seguir para confirmar se as anotações do Serviço foram aplicadas: A saída deve incluir todas as quatro anotações
alibaba-cloud-loadbalancer-*com os valores configurados.kubectl get svc <istio-ingress-gateway-service-name> -n <namespace> -o yaml | grep alibaba-cloud-loadbalancer
Etapa 2: Criar um gateway de entrada ASM
Crie um gateway de entrada ASM com a mesma configuração de portas do gateway de entrada Istio. Para obter instruções detalhadas, consulte Criar um gateway de entrada.
Ao criar o gateway com um arquivo YAML, siga estas diretrizes:
Utilize um nome distinto. O nome do gateway de entrada ASM deve ser diferente do gateway de entrada Istio. Adicione o sufixo
-asmpara maior clareza (por exemplo,ingressgateway-asm).Mantenha a configuração de portas. Defina a lista de portas e os valores de
targetPortpara corresponder exatamente aos do gateway de entrada Istio.-
Configure as anotações do CLB com peso 0. Na Custom Resource Definition (CRD) do gateway, defina o campo
serviceAnnotationcom as mesmas anotações da Etapa 1, exceto pelo peso, que deve ser definido como"0": Para a lista completa de campos da CRD, consulte Campos de CRD para um gateway ASM.service.beta.kubernetes.io/alibaba-cloud-loadbalancer-weight: "0"
Verificar
Faça login no console do CLB, selecione um grupo de vServer e clique em o nome do grupo. Confirme se tanto os endereços dos pods do gateway Istio quanto os do gateway ASM aparecem na lista de servidores de backend. Isso confirma que a instância do CLB está sendo compartilhada com sucesso.
-
Execute o comando a seguir para verificar se ambos os conjuntos de pods de gateway estão registrados: A saída deve listar os pods do gateway de entrada ASM com seus endereços IP. Compare esses IPs com a lista de servidores de backend no console do CLB.
kubectl get pods -n <namespace> -l istio=ingressgateway-asm -o wide
Etapa 3: Migrar configurações do gateway Istio para o ASM
Aplique as configurações do gateway de entrada Istio ao gateway de entrada ASM para que ambos lidem com o tráfego de forma idêntica.
-
Atualize o seletor da CR do Gateway. Altere o valor de
spec.selector.istiona Custom Resource (CR) do Gateway para o nome do gateway de entrada ASM:spec: selector: istio: ingressgateway-asm Migre as CRs VirtualService e DestinationRule. Aplique as configurações das CRs VirtualService e DestinationRule diretamente no ASM sem modificações.
Verificar
Envie solicitações de teste diretamente para o IP do pod do gateway de entrada ASM (ignorando o CLB) e confirme se as regras de roteamento funcionam conforme o esperado:
# Get the ASM ingress gateway pod IP
ASM_POD_IP=$(kubectl get pods -n <namespace> -l istio=ingressgateway-asm -o jsonpath='{.items[0].status.podIP}')
# Send a test request
curl -H "Host: <your-domain>" http://$ASM_POD_IP:<port>/
Uma resposta bem-sucedida confirma que as configurações da CR do Gateway, VirtualService e DestinationRule estão funcionando corretamente no gateway de entrada ASM.
Etapa 4: Transferir tráfego do Istio para o ASM
Transfira o tráfego gradualmente ajustando a anotação service.beta.kubernetes.io/alibaba-cloud-loadbalancer-weight em ambos os Serviços de gateway. Aumente o peso do ASM e diminua o peso do Istio em fases.
Progressão de peso recomendada:
|
Fase |
Peso Istio |
Peso ASM |
Duração sugerida |
Validação |
|
1 |
100 |
0 |
Estado inicial |
Confirmar reuso do CLB (Etapa 2) |
|
2 |
90 |
10 |
1 hora |
Monitorar taxas de erro e latência |
|
3 |
50 |
50 |
2 horas |
Verificar todas as rotas e integridade do backend |
|
4 |
10 |
90 |
1 hora |
Validar casos extremos |
|
5 |
0 |
100 |
Estado final |
Validação completa |
Para ajustar os pesos em cada fase, edite as anotações de Serviço de ambos os gateways. Por exemplo, para rotear 10% do tráfego para o ASM:
-
Serviço do gateway de entrada Istio:
service.beta.kubernetes.io/alibaba-cloud-loadbalancer-weight: "90" -
Serviço do gateway de entrada ASM:
service.beta.kubernetes.io/alibaba-cloud-loadbalancer-weight: "10"
Monitore as métricas da aplicação (taxas de erro, latência e throughput) em cada fase antes de prosseguir para a próxima. Se ocorrerem problemas, reverta imediatamente restaurando os pesos anteriores.
Reverter
Se surgirem problemas em qualquer fase, reverta os pesos de tráfego para restaurar todo o fluxo para o gateway de entrada Istio:
-
Defina o peso do gateway de entrada Istio novamente para
"100":service.beta.kubernetes.io/alibaba-cloud-loadbalancer-weight: "100" -
Defina o peso do gateway de entrada ASM para
"0":service.beta.kubernetes.io/alibaba-cloud-loadbalancer-weight: "0" Investigue e resolva o problema antes de reiniciar a migração.
Após uma reversão bem-sucedida, o gateway de entrada Istio original volta a processar todo o tráfego. Nenhuma alteração de configuração nas CRs Gateway, VirtualService ou DestinationRule afeta o fluxo de tráfego quando o peso do gateway ASM está definido como 0.