Migrar NGINX Ingress para o cloud-native API Gateway | ferramenta de migração - API Gateway: Central de Documentação do Alibaba Cloud

Pré-requisitos

Um NGINX Ingress Controller está implantado no seu cluster ACK.
Uma instância do cloud-native API Gateway deve estar criada. Caso contrário, crie uma instância de gateway.

Notas de uso

O cloud-native API Gateway não copia as configurações do Ingress. Ele analisa as alterações nos seus recursos do Ingress existentes em tempo real.
Durante a migração, as alterações de configuração do Ingress são refletidas tanto no NGINX Ingress Controller quanto no cloud-native API Gateway.
Não exclua as configurações do Ingress de produção após a migração. O cloud-native API Gateway continua analisando as configurações do Ingress existentes e futuras.
As configurações do 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ê na migração de rotas e na alternância de tráfego.

Nota

Uma AI Skill oficial (alibabacloud-nginx-ingress-to-api-gateway) pode verificar a compatibilidade do Ingress em lote, gerar plugins Wasm e novas configurações de rota do Ingress para anotações incompatíveis, além de produzir um runbook de migração completo.

Etapa 1: Migrar regras de roteamento

acesse o API Gateway console.
No painel de navegação à esquerda, escolha 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 do Ingress associados à source IngressClass no cluster selecionado e aplica suas configurações de domínio e rota.

Importante

Se o gateway de destino já estiver associado a este cluster, mas usar uma IngressClass diferente, a migração falhará. especifique a IngressClass, que deve corresponder àquela configurada para o cluster associado.

Parâmetro	Descrição
Instance	A instância do 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 HTTP API que recebe as rotas importadas do NGINX Ingress.
resource	O grupo de recursos de destino.
Namespace	O namespace dos recursos do Ingress a serem migrados.
IngressClass	A IngressClass dos recursos do Ingress a serem migrados. Nota especifique apenas uma única IngressClass. Se estiver vazio, o gateway monitora todos os recursos do Ingress, independentemente da IngressClass.

Clique em Next.
O cloud-native API Gateway monitora todos os recursos do Ingress associados à source IngressClass e aplica as configurações de domínio e rota à nova API.
1. Por exemplo, suponha que você tenha um recurso do Ingress chamado nginx-route no seu cluster de contêineres source.
2. No console do cloud-native API Gateway, você pode ver que o gateway sincronizou automaticamente o Ingress do cluster source e criou as configurações de nome de domínio e de rota correspondentes.

Etapa 2: Validar rotas

Valide a compatibilidade dos recursos do Ingress:

Se nenhuma anotação incompatível do Ingress for encontrada, prossiga para a próxima etapa.
Se existirem anotações incompatíveis do Ingress, use 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.
Importante
- Você pode ignorar nginx.ingress.kubernetes.io/service-weight se o seu valor for uma string vazia (""). Essa anotação era adicionada por padrão em versões mais antigas do console do 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: escolha um método de alternância de tráfego

Teste antes de alternar o tráfego

Antes de alternar o tráfego em produção, teste localmente. Aponte o domínio do seu service para o ip do SLB do cloud-native API Gateway no seu arquivo hosts local e, em seguida, verifique o roteamento com curl ou Postman.

Selecione um método de alternância 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 original do SLB. O SLB distribui o tráfego por peso durante a migração e, em seguida, encaminha todo o tráfego para o cloud-native API Gateway após a conclusão.

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 destino 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 selecione a porta e o protocolo corretos para evitar perda de tráfego.

Alternar tráfego via DNS

No console do seu provedor de DNS, adicione registros apontando os nomes de domínio migrados para o endereço do SLB do cloud-native API Gateway. Use registros de DNS ponderados para uma alternância gradual de tráfego.

Etapa 4: Alternar tráfego

Reutilizar o SLB original

Etapa 1: Clique em Change SLB

A ação de clique em Change SLB desanexa o SLB do gerenciamento de service de contêineres e define o agendamento do listener para Weighted Round Robin.

Importante

Esta etapa desanexa o SLB do gerenciamento de service de contêineres. Após a desanexação, o SLB não pode detectar alterações de ip do Pod no NGINX Ingress Controller. modifique as anotações e reassocie o Kubernetes Service ao SLB imediatamente.

Etapa 2: Sobrescrever anotações do service

Após a Etapa 1, acesse o ACK console. 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 e verifique antes de prosseguir.

Etapa 3: Alternar tráfego por peso

defina o peso do tráfego do cloud-native API Gateway (1-100). Comece com um valor entre 1 e 10.

Este valor é 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 (o sistema aplica a configuração de forma assíncrona).
- Se as métricas degradarem, defina o peso como 0 para interromper a migração.
Você também pode aumentar o peso do gateway indiretamente, diminuindo a anotação service.beta.kubernetes.io/alibaba-cloud-loadbalancer-weight no Kubernetes Service selecionado em Reuse the original SLB. 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 um quick rollback.

Nota

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. verifique o tráfego e, se não precisar mais da capacidade de reversão, clique em Complete Traffic Verification para prosseguir.

Importante

Após o clique em Complete Traffic Verification, você não poderá mais modifique o peso.

Etapa 4: Alternar todo o tráfego

No console do ACK, defina a anotação service.beta.kubernetes.io/alibaba-cloud-loadbalancer-weight como 0 para o Kubernetes Service selecionado em Step 3: Choose a traffic switching method ou exclua o recurso do Service. O sistema remove os nós do NGINX Ingress Controller do SLB, alternando todo o tráfego para o cloud-native API Gateway. Clique em Complete Migration para concluir.

Alternar tráfego via DNS

No console do seu provedor de DNS, adicione registros apontando os nomes de domínio migrados para o endereço do SLB do cloud-native API Gateway. Use registros de DNS ponderados para uma alternância 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 'Reuse the original SLB', defina o peso como 0.
Se estiver usando a alternância de DNS, remova os registros de 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 você tiver outros SLBs ainda não totalmente alternados, conclua a alternância de tráfego deles. Após alternar todo o tráfego do SLB, exclua o Kubernetes Service e o NGINX Ingress Controller se não forem mais necessários.

Alternar tráfego via DNS

Após 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.