Este tópico descreve como migrar um Nginx Ingress autogerenciado para o MSE Ingress usando a ferramenta de migração visual no console do MSE.
Pré-requisitos
Um Nginx Ingress Controller implantado no cluster do Container Service.
Um Cloud Native Gateway disponível. Se não tiver um, consulte Crie um MSE Cloud Native Gateway.
Observações de uso
O processo de migração não copia as configurações de Ingress. Em vez disso, permite que o MSE Ingress reutilize essas configurações monitorando e interpretando alterações nos recursos de Ingress existentes em tempo real.
Durante a migração, tanto o Nginx Ingress Controller quanto o MSE Ingress refletem quaisquer alterações nas configurações de Ingress.
Após concluir a migração, não exclua nenhuma configuração de Ingress em uso. A migração apenas habilita o MSE Ingress a monitorar e interpretar configurações de Ingress atuais e futuras.
Após a migração, mantenha as configurações de Ingress existentes e futuras associadas à IngressClass original. Por exemplo, se um recurso de Ingress especificava anteriormente
ingressClassName: nginxem sua spec, deve continuar assim após a migração.
Métodos de migração
Detalhes
Fluxo de trabalho de migração
O Cloud Native Gateway fornece uma ferramenta de Migração para a Cloud que orienta passo a passo na migração das configurações de roteamento e na transferência de tráfego.
Etapa 1: Migrar regras de roteamento
Faça login no console do MSE. Na barra de navegação superior, selecione uma região.
No painel de navegação à esquerda, escolha Cloud Native Gateway > Migration to Cloud.
Na página Migration to Cloud, clique em Add Task.
-
No painel Create Migration Configuration, configure os parâmetros.
O Cloud Native Gateway monitora todos os recursos de Ingress no cluster de contêiner selecionado associados à IngressClass de origem e aplica as configurações de nome de domínio e roteamento.
ImportanteA migração não é permitida se o Cloud Native Gateway de destino já estiver associado a este cluster de contêiner usando uma IngressClass diferente. Certifique-se de que a IngressClass especificada aqui corresponda àquela já configurada para o cluster.
Parâmetro
Descrição
Cloud-native Gateway
Selecione o Cloud Native Gateway de destino para a migração. A versão do gateway deve ser 1.2.22 ou posterior.
Container Service ACK/ACK Serverless cluster
Selecione o cluster do Container Service que contém o Nginx Ingress a ser migrado. Garanta que o Cloud Native Gateway e o cluster de contêiner estejam na mesma VPC.
Source Ingress Class
Especifique a IngressClass associada aos recursos de Ingress que deseja migrar.
NotaÉ possível especificar apenas uma IngressClass.
Se deixar este parâmetro vazio, a IngressClass será ignorada e o gateway monitorará todos os recursos de Ingress no cluster.
Descrição
Insira uma descrição com até 64 caracteres.
-
Clique em Next.
O Cloud Native Gateway passa a monitorar automaticamente as alterações em todos os recursos de Ingress no cluster de contêiner selecionado e associados à IngressClass de origem, aplicando as configurações de nome de domínio e roteamento desses recursos.
Suponha que exista um Ingress chamado httpbin no cluster de contêiner de origem.
-
No console do Cloud Native Gateway, o Ingress do cluster de origem é sincronizado automaticamente com o gateway de destino, criando as configurações de domínio e roteamento correspondentes. A página de detalhes Routing Settings é exibida da seguinte forma:
-
Assistente de configuração:
-
Adicionar fonte de serviço
Use K8s, Nacos, Zookeeper, SAE, EDAS e Function Compute (FC) como fontes de serviço. Adicione um recurso existente da VPC atual e selecione um serviço registrado nele.
Botão: Add service source
-
Associar serviço de backend
Distribui solicitações para um serviço de backend. Esse serviço pode ser descoberto dinamicamente a partir de uma fonte de serviço ou especificado por um endereço estático ou nome de domínio.
Botão: Associate backend service
-
Vincular nome de domínio
Oferece gerenciamento de múltiplos domínios. Ao vincular um nome de domínio, associe protocolos, certificados e configurações de roteamento a diferentes domínios.
Botão: Bind domain name
-
Criar rota
Uma rota contém regras de correspondência baseadas em nomes de domínio, caminhos, métodos, parâmetros de solicitação e cabeçalhos de solicitação. Quando um usuário acessa uma rota, a solicitação é encaminhada para o serviço de backend correspondente.
Botão: Create route
-
Colunas da lista: Route name, Status, WAF protection, Source, Route condition, Associated domain name, Destination service type, Destination service e Actions.
-
Etapa 2: Verificar rotas
Verifique a compatibilidade das anotações de Ingress monitoradas:
Se não houver anotações de Ingress incompatíveis, prossiga para a próxima etapa.
-
Caso encontre anotações de Ingress incompatíveis, envie um ticket para obter uma solução.
ImportanteIgnore a anotação
nginx.ingress.kubernetes.io/service-weightse seu valor for"". Essa anotação é adicionada por padrão por uma versão anterior do console do Container Service e não tem efeito.Durante a migração, não remova anotações incompatíveis em uso. Essas anotações ainda são interpretadas pelo Nginx Ingress Controller e afetam o tráfego do negócio. Adicione anotações estendidas do MSE ao recurso de Ingress para obter a mesma funcionalidade no MSE Ingress. Depois que todo o tráfego for migrado para o MSE Ingress, remova as anotações incompatíveis conforme necessário.
Etapa 3: Selecionar método de transferência
Testar antes de transferir o tráfego
Antes de transferir o tráfego de produção, realize um teste local. Modifique o arquivo hosts local para resolver o nome de domínio de negócios para o SLB do Cloud Native Gateway. Use uma ferramenta como curl ou Postman para verificar se todo o tráfego se comporta conforme o esperado.
Selecionar método de transferência
Reutilizar SLB de origem
Princípio: O processo adiciona as instâncias de nó do Cloud Native Gateway ao grupo de servidores de backend do SLB de origem. Durante a migração, o SLB distribui o tráfego de negócios para o Cloud Native Gateway com base nos pesos configurados. Após a conclusão da migração, o SLB encaminha todo o tráfego para o Cloud Native Gateway.
A tabela a seguir descreve os parâmetros.
Parâmetro | Descrição |
ACK Cluster Namespace | Selecione o namespace onde está localizado o Kubernetes Service associado ao SLB do Nginx Ingress. |
ACK Cluster SLB Service | Selecione o nome do Kubernetes Service associado ao SLB do Nginx Ingress. |
SLB ID | Clique em na instância SLB para confirmar que ela é o destino correto para a migração. |
Ports and Backend Servers | Selecione a porta do listener e o protocolo do gateway (HTTP/HTTPS) da instância SLB de origem. O grupo de servidores virtuais de destino aparece automaticamente. Nota Certifique-se de selecionar a porta e o protocolo corretos para evitar perda de tráfego. |
Resolução DNS
Acesse o serviço de resolução de domínios do provedor de DNS e adicione mapeamentos para o endereço SLB do Cloud Native Gateway para todos os domínios envolvidos na migração de rotas. Recomendamos usar a resolução ponderada de DNS para transferir o tráfego gradualmente.
Etapa 4: Transferir tráfego
Reutilizar SLB de origem
Etapa 1: Modificar SLB
Ao clicar em Modify SLB, o sistema desassocia automaticamente a instância SLB do gerenciamento do Container Service e altera o algoritmo de agendamento do listener para Weighted Round Robin.
Esta etapa desassocia a instância SLB do gerenciamento do Container Service. Após a desassociação, a instância SLB não rastreia mais as alterações de endereço IP do Pod no Nginx Ingress Controller. Prossiga prontamente para a próxima etapa para modificar as anotações e reassociar o Kubernetes Service à instância SLB.
Etapa 2: Sobrescrever as anotações do serviço
Após concluir a Etapa 1, acesse o console do Container Service. Exclua manualmente todas as anotações existentes do Kubernetes Service selecionado na etapa Switch Traffic. Em seguida, copie as anotações geradas automaticamente na página Traffic Switchover e adicione-as ao Kubernetes Service de destino. Esta etapa reconfigura o Kubernetes Service original para reutilizar a instância SLB. Após a modificação, clique em Precheck. Se a verificação for aprovada, prossiga para a próxima etapa.
apiVersion: v1
kind: Service
metadata:
annotations:
service.beta.kubernetes.io/alibaba-cloud-loadbalancer-id: lb-bp1lc0huzf0o1ks333yo1
service.beta.kubernetes.io/alibaba-cloud-loadbalancer-weight: '100'
service.beta.kubernetes.io/alibaba-cloud-loadbalancer-vgroup-port: 'rsp-bp1uybv6iy50i:80,rsp-bp10s0ndrfvdt:443'
creationTimestamp: '2023-11-29T07:14:40Z'
finalizers:
- service.k8s.alibaba/resources
labels:
app: nginx-ingress-lb
service.beta.kubernetes.io/hash: 39a51bd97b88f6eaf232da33434ce2fe44ae094b7b4d2b9bb9126eb7
service.k8s.alibaba/loadbalancer-id: lb-bp1lc0huzf0o1ks333yo1
managedFields:
- apiVersion: v1
fieldsType: FieldsV1
fieldsV1:
'f:metadata':
'f:annotations':
.: {}
'f:kubectl.kubernetes.io/last-applied-configuration': {}
'f:service.beta.kubernetes.io/alibaba-cloud-loadbalancer-connection-drain': {}
'f:service.beta.kubernetes.io/alibaba-cloud-loadbalancer-connection-drain-timeout': {}
'f:service.beta.kubernetes.io/alibaba-cloud-loadbalancer-instance-charge-type': {}
'f:service.beta.kubernetes.io/alibaba-cloud-loadbalancer-resource-group-id': {}
'f:labels':
.: {}
'f:app': {}
Se pods de aplicativos no mesmo cluster de contêiner acessarem o gateway Nginx Ingress, adicione também a anotação service.beta.kubernetes.io/alibaba-cloud-loadbalancer-hostname: mse-ingress-migration ao Service. Antes de adicionar a anotação, certifique-se de que o controle de acesso por IP esteja desativado para a instância SLB associada ao Service. Essa anotação força os pods de aplicativos a acessar o gateway Nginx Ingress através do SLB e impede que o Kube Proxy otimize o tráfego para ignorar o SLB e acessar diretamente o pod do Nginx Ingress.
Etapa 3: Transferência ponderada de tráfego
Defina o peso do tráfego para a instância do Cloud Native Gateway. Defina um valor de 1 a 100 com base nas necessidades do negócio. Recomendamos um valor inicial entre 1 e 10.
Esse valor representa a soma dos pesos de todos os nós do Cloud Native Gateway. A instância SLB distribui o tráfego com base na proporção de peso entre os nós do Cloud Native Gateway e os nós do Nginx Ingress no grupo de servidores virtuais. O peso total dos nós do Nginx Ingress é definido como 100 por padrão. Portanto, se definir o peso do Cloud Native Gateway como 100, ele receberá metade do tráfego. Da mesma forma, se definir o peso como 50, ele receberá um terço do tráfego.
-
Durante a migração, monitore as métricas do gateway no painel de monitoramento do Cloud Native Gateway para verificar a integridade do gateway e garantir que as métricas de negócios estejam estáveis.
Se os resultados forem conforme o esperado, aumente gradualmente o peso. Aguarde pelo menos 3 minutos entre as alterações de peso, pois o backend aplica a configuração de forma assíncrona.
Caso os resultados não sejam os esperados, defina o peso como 0 para interromper a migração.
No console do Container Service, reduza o valor da anotação
service.beta.kubernetes.io/alibaba-cloud-loadbalancer-weightdo Kubernetes Service selecionado para reusing the original cluster's SLB para aumentar indiretamente o peso do Cloud Native Gateway. Especificamente, quando o valor dessa anotação é 0, todo o tráfego é direcionado para o Cloud Native Gateway.Como o SLB é um balanceador de carga de Camada 4, ele controla o tráfego no nível de conexão. O valor do peso não consegue controlar com precisão a proporção de distribuição no nível de solicitação.
Se a taxa de sucesso cair após a transferência de tráfego, execute um fast rollback definindo este peso como 0.
Se desejar permanecer em estado de migração por um período prolongado e poder ajustar os pesos de tráfego entre o Nginx Ingress e o MSE Ingress a qualquer momento, permaneça nesta etapa. Assim que verificar que o tráfego se comporta conforme o esperado e não precisar mais reverter todo o tráfego para o Nginx Ingress, clique em Complete Traffic Verification para prosseguir.
Após clicar em Complete Traffic Verification, não será mais possível modificar os pesos.
Etapa 4: Concluir troca de tráfego
No console do Container Service, defina o valor da anotação service.beta.kubernetes.io/alibaba-cloud-loadbalancer-weight como 0 para o K8s Service selecionado em Step 3: Select a traffic shifting method, ou exclua o recurso Service. Os nós do Nginx Ingress Controller serão então removidos automaticamente do SLB, e todo o tráfego do SLB será transferido para o Cloud Native Gateway. Clique em Complete Migration para finalizar a tarefa de migração.
Resolução DNS
Acesse o serviço de resolução de domínios do provedor de DNS e adicione mapeamentos para o endereço SLB do Cloud Native Gateway para todos os domínios envolvidos na migração de rotas. Recomendamos usar a resolução ponderada de DNS para transferir o tráfego gradualmente.
Rollback rápido
Se encontrar problemas inesperados durante a migração de tráfego, utilize os métodos a seguir para realizar um rollback rápido e restaurar o tráfego para o Nginx Ingress Controller.
Reutilizar o SLB do cluster de origem: Defina o peso como 0. Isso interrompe a migração.
Usar DNS para resolver para o SLB do Cloud Native Gateway: No provedor de DNS, remova o endereço SLB do Cloud Native Gateway para todos os domínios de negócios.
Etapa 5: Concluir a migração
Reutilizar SLB de origem
Se utilizou o método de transferência de tráfego via SLB, garanta que o tráfego tenha sido completamente transferido para todas as instâncias SLB relevantes. Após concluir a transferência de tráfego para todas as instâncias SLB, exclua o Kubernetes Service e o Nginx Ingress Controller conforme necessário.
Resolução DNS
Caso tenha utilizado o método de transferência de tráfego via DNS e os endereços IP de todos os domínios de negócios agora resolvam para a lista de endereços SLB do gateway MSE, exclua o Kubernetes Service e o Nginx Ingress Controller conforme necessário.
Solução de problemas
Bad request: mse.backend.gw.MIGRATE_INGRESS_CLASS_CONFLICT
Este erro indica que o gateway já está associado ao cluster do Container Service e tem o monitoramento de Ingress ativado, mas a IngressClass especificada para esta migração não corresponde à configuração original de monitoramento de Ingress. Certifique-se de que as configurações de IngressClass sejam consistentes.
Se precisar modificar a IngressClass configurada anteriormente, escolha um dos métodos a seguir com base na sua configuração:
Se gerencia o MSE Ingress através de um MseIngressConfig, consulte Access Container Service and Container Compute Service by using MSE Ingress para modificá-lo.
Caso não gerencie o MSE Ingress através de um MseIngressConfig, acesse o console do gateway, localize a fonte de serviço e modifique as opções de monitoramento de Ingress para o cluster de contêiner correspondente.
Bad request: mse.backend.gw.MIGRATE_SERVICE_ANNOTATION_NOT_MATCH [annotation is not expected]
Este erro indica que as anotações no Kubernetes Service não foram atualizadas para os valores necessários.
Bad request: mse.backend.gw.MIGRATE_SERVICE_NOT_MATCH [weight hasn't been 0 or service hasn't been deleted]
Isso indica que o valor da anotação service.beta.kubernetes.io/alibaba-cloud-loadbalancer-weight para o K8s Service não está definido como 0, ou o K8s Service não foi excluído. No console do Container Service, defina o valor da anotação service.beta.kubernetes.io/alibaba-cloud-loadbalancer-weight como 0, ou exclua o K8s Service.

