Com a descontinuação do NGINX Ingress, é necessário migrar para uma nova solução de gateway. O Cloud-native API Gateway oferece uma ferramenta de migração baseada em interface que transfere regras de roteamento e altera o tráfego de um NGINX Ingress autogerenciado para o Cloud-native API Gateway.
Pré-requisitos
Um NGINX Ingress Controller implantado no cluster ACK.
Uma instância do Cloud-native API Gateway criada. Caso contrário, Crie uma instância de gateway.
Observações de uso
O Cloud-native API Gateway não copia as configurações do Ingress, mas analisa as alterações nos recursos de Ingress existentes em tempo real.
Durante a migração, as mudanças na configuração do Ingress refletem tanto no NGINX Ingress Controller quanto no Cloud-native API Gateway.
Não exclua as configurações de Ingress de produção após a migração. O Cloud-native API Gateway continua a analisar as configurações de Ingress atuais e futuras.
As configurações de Ingress existentes e futuras devem permanecer associadas à IngressClass monitorada pelo Cloud-native API Gateway. Por exemplo, se a ingressClassName era nginx/higress/apig, mantenha-a inalterada após a migração.
Procedimento de migração
A ferramenta Migrate to Cloud orienta você durante a migração de rotas e a troca de tráfego.
Uma AI Skill oficial (alibabacloud-nginx-ingress-to-api-gateway) verifica em lote a compatibilidade do Ingress, gera plugins Wasm e novas configurações de rota de Ingress para anotações incompatíveis, além de produzir um runbook completo de migração.
Etapa 1: Migrar regras de roteamento
Faça login no console do API Gateway.
No painel de navegação à esquerda, selecione Cloud Migration.
Na página Cloud Migration, clique em Create a task.
-
No painel Create Migration Configuration, configure os parâmetros.
O Cloud-native API Gateway monitora todos os recursos de Ingress associados à IngressClass de origem no cluster selecionado e aplica suas configurações de domínio e rota.
ImportanteSe o gateway de destino já estiver associado a este cluster, mas usar uma IngressClass diferente, a migração falhará. A IngressClass especificada deve corresponder àquela configurada para o cluster associado.
Parâmetro
Descrição
Instance
A instância de gateway de destino.
Source Cluster
O cluster de contêineres que hospeda o NGINX Ingress a ser migrado. Deve estar na mesma VPC que o Cloud-native API Gateway.
API Name
A API HTTP que recebe as rotas de NGINX Ingress importadas.
resource
O grupo de recursos de destino.
Namespace
O namespace dos recursos de Ingress a serem migrados.
IngressClass
A IngressClass dos recursos de Ingress a serem migrados.
Nota-
Especifique apenas uma única IngressClass.
-
Se deixado em branco, o gateway monitora todos os recursos de Ingress, independentemente da IngressClass.
-
-
Clique em Next.
O Cloud-native API Gateway monitora todos os recursos de Ingress associados à IngressClass de origem e aplica as configurações de domínio e rota à nova API.
Por exemplo, suponha que exista um recurso de Ingress chamado nginx-route no cluster de contêineres de origem.
No console do Cloud-native API Gateway, o gateway sincroniza automaticamente o Ingress do cluster de origem e cria as configurações correspondentes de nome de domínio e rota.
Etapa 2: Validar rotas
Valide a compatibilidade dos recursos de Ingress:
Caso nenhuma anotação de Ingress incompatível seja encontrada, prossiga para a próxima etapa.
-
Se existirem anotações de Ingress incompatíveis, utilize ferramentas de IA como HiClaw, CoPaw ou QoderWork com a Skill oficial de migração alibabacloud-nginx-ingress-to-api-gateway para analisar configurações, gerar plugins Wasm para anotações incompatíveis e criar um runbook. Se os problemas persistirem, envie um ticket.
ImportanteIgnore
nginx.ingress.kubernetes.io/service-weightse seu valor for uma string vazia (""). Essa anotação era adicionada por padrão em versões mais antigas do console ACK e não tem efeito funcional.Não exclua anotações incompatíveis durante a migração. O NGINX Ingress Controller ainda as utiliza para o tráfego de produção.
Etapa 3: Escolher um método de troca de tráfego
Testar antes de trocar o tráfego
Antes de alternar o tráfego ativo, realize testes locais. Aponte o domínio do serviço para o ip do SLB do Cloud-native API Gateway no arquivo hosts local e verifique o roteamento com curl ou Postman.
Selecionar um método de troca de tráfego
Reutilizar o SLB original
Este método adiciona nós do Cloud-native API Gateway ao grupo de vServers de backend da instância SLB original. O SLB distribui o tráfego por peso durante a migração e, após a conclusão, encaminha todo o tráfego para o Cloud-native API Gateway.
Configure os seguintes parâmetros:
|
Parâmetro |
Descrição |
|
ACK Cluster Namespace |
O namespace do Kubernetes Service associado ao SLB do NGINX Ingress. |
|
ACK Cluster SLB Service |
O Kubernetes Service associado ao SLB do NGINX Ingress. |
|
SLB ID |
Confirme se o SLB consultado é o alvo da migração. |
|
Ports and Backend Servers |
A porta do listener e o protocolo (HTTP/HTTPS) do SLB original. O grupo de vServers de destino é exibido automaticamente. Nota
Certifique-se de selecionar a porta e o protocolo corretos para evitar perda de tráfego. |
Trocar tráfego via dns
No console do provedor de dns, adicione registros apontando os nomes de domínio migrados para o endereço do SLB do Cloud-native API Gateway. Utilize registros dns ponderados para uma troca gradual de tráfego.
Etapa 4: Trocar o tráfego
Reutilizar o SLB original
Etapa 1: Clicar em Change SLB
Ao clicar em Change SLB, o sistema desvincula o SLB do gerenciamento de serviço de contêiner e define o agendamento do listener como Weighted Round Robin.
Esta etapa desvincula o SLB do gerenciamento de serviço de contêiner. Após o desvinculamento, o SLB não consegue detectar alterações de ip de Pod no NGINX Ingress Controller. Prossiga imediatamente para a próxima etapa para modificar anotações e reassociar o Kubernetes Service ao SLB.
Etapa 2: Sobrescrever anotações de serviço
Após a Etapa 1, acesse o console ACK. Exclua todas as anotações atuais do Kubernetes Service selecionado na etapa Reuse the original SLB. Copie as anotações geradas na página Traffic Switching e adicione-as ao Service de destino. Isso reconfigura o Service para reutilizar o SLB. Clique em Pre-check para verificar antes de prosseguir.
Etapa 3: Trocar tráfego por peso
Defina o peso de tráfego do Cloud-native API Gateway (1-100). Comece com um valor entre 1 e 10.
Esse valor representa o peso total de todos os nós do Cloud-native API Gateway. O SLB distribui o tráfego com base na proporção de peso entre os nós do gateway e os nós do NGINX Ingress (peso total padrão: 100). Definir o peso do gateway como 100 concede a ele metade do tráfego; definir como 50 concede um terço.
-
Monitore a integridade do gateway e as métricas de negócios usando os painéis do Cloud-native API Gateway.
Se as métricas estiverem saudáveis, aumente o peso gradualmente. Aguarde pelo menos 3 minutos entre as alterações (a configuração é aplicada de forma assíncrona).
Caso as métricas piorem, defina o peso como 0 para interromper a migração.
Também é possível aumentar o peso do gateway indiretamente, reduzindo a anotação
service.beta.kubernetes.io/alibaba-cloud-loadbalancer-weightno Kubernetes Service selecionado em Reutilizar o SLB original. Definir essa anotação como 0 direciona todo o tráfego para o Cloud-native API Gateway.O SLB opera na Camada 4 (nível de conexão), portanto, os valores de peso não controlam com precisão a distribuição no nível de requisição.
Se a taxa de sucesso cair, defina o peso como 0 para realizar uma reversão rápida.
Para manter a capacidade de ajustar os pesos de tráfego entre o NGINX Ingress e o Cloud-native API Gateway, permaneça nesta etapa. Quando o tráfego for verificado e a capacidade de reversão não for mais necessária, clique em Complete Traffic Verification para prosseguir.
Após clicar em Complete Traffic Verification, não será mais possível modificar o peso.
Etapa 4: Trocar todo o tráfego
No console ACK, defina a anotação service.beta.kubernetes.io/alibaba-cloud-loadbalancer-weight como 0 para o Kubernetes Service selecionado na Etapa 3: Escolher um método de troca de tráfego, ou exclua o recurso do Service. O sistema remove os nós do NGINX Ingress Controller do SLB, transferindo todo o tráfego para o Cloud-native API Gateway. Clique em Complete Migration para finalizar.
Trocar tráfego via dns
No console do provedor de dns, adicione registros apontando os nomes de domínio migrados para o endereço do SLB do Cloud-native API Gateway. Utilize registros dns ponderados para uma troca gradual de tráfego.
Reversão rápida
Se ocorrerem problemas de roteamento durante a migração, reverta o tráfego para o NGINX Ingress Controller:
Se estiver usando o método 'Reutilizar o SLB original', defina o peso como 0.
Se estiver usando a troca via dns, remova os registros dns que apontam seus nomes de domínio para o endereço do SLB do Cloud-native API Gateway.
Etapa 5: Concluir a migração
Reutilizar o SLB original
Se houver outros SLBs ainda não totalmente trocados, conclua a troca de tráfego deles. Assim que todo o tráfego do SLB for trocado, exclua o Kubernetes Service e o NGINX Ingress Controller se não forem mais necessários.
Trocar tráfego via dns
Assim que todos os nomes de domínio resolverem para o SLB do Cloud-native API Gateway, exclua o Kubernetes Service e o NGINX Ingress Controller se não forem mais necessários.