Microservices Engine:Migrate from Nginx Ingress to MSE Ingress

Requisitos previos

• Se desplegó un Nginx Ingress Controller en su clúster de Container Service.

• Debe contar con una instancia de Cloud Native Gateway disponible. Si no tiene una, consulte Create an MSE Cloud Native Gateway.

Notas de uso

• El proceso de migración no copia sus configuraciones de Ingress. En su lugar, permite que MSE Ingress reutilice dichas configuraciones al observar y analizar los cambios de sus recursos de Ingress existentes en tiempo real.

• Durante la migración, tanto el Nginx Ingress Controller como MSE Ingress reflejan cualquier cambio que usted aplique a las configuraciones de Ingress.

• Una vez finalizada la migración, no elimine ninguna configuración de Ingress que esté en uso. La migración solo habilita a MSE Ingress para observar y analizar las configuraciones de Ingress actuales y futuras.

• Después de la migración, debe mantener las configuraciones de Ingress existentes y futuras asociadas con la IngressClass original. Por ejemplo, si un recurso de Ingress especificaba previamente ingressClassName: nginx en su spec, debe continuar haciéndolo tras la migración.

Métodos de migración

Flujo de trabajo de migración

Cloud Native Gateway proporciona una herramienta de migración a la nube que lo guía paso a paso para migrar sus configuraciones de enrutamiento y trasladar el tráfico.

Paso 1: Migrar las reglas de enrutamiento

1. Inicie sesión en la consola de MSE. En la barra de navegación superior, seleccione una región.

2. En el panel de navegación izquierdo, elija Cloud Native Gateway > Migration to Cloud.

3. En la página Migration to Cloud, haga clic en Add Task.

4. En el panel Create Migration Configuration, configure los parámetros.

   Cloud Native Gateway observa todos los recursos de Ingress del clúster de contenedores seleccionado que estén asociados con la IngressClass de origen. A continuación, aplica sus configuraciones de nombre de dominio y de enrutamiento.

   Importante

   La migración no se permite si la instancia de Cloud Native Gateway de destino ya está asociada con este clúster de contenedores mediante una IngressClass diferente. Asegúrese de que la IngressClass especificada aquí coincida con la que ya está configurada para el clúster.

   Parámetro	Descripción
   Cloud-native Gateway	Seleccione la instancia de Cloud Native Gateway de destino para la migración. La versión de la puerta de enlace debe ser 1.2.22 o posterior.
   Container Service ACK/ACK Serverless cluster	Seleccione el clúster de Container Service que contiene el Nginx Ingress que desea migrar. Asegúrese de que Cloud Native Gateway y el clúster de contenedores se encuentren en la misma VPC.
   Source Ingress Class	Especifique la IngressClass asociada con los recursos de Ingress que desea migrar. Nota Solo puede especificar una IngressClass. Si deja este parámetro vacío, se ignora la IngressClass y la puerta de enlace observa todos los recursos de Ingress del clúster.
   Description	Introduzca una descripción de hasta 64 caracteres.

5. Haga clic en Next.

   A partir de este momento, Cloud Native Gateway observa automáticamente los cambios en todos los recursos de Ingress que se encuentran en el clúster de contenedores seleccionado y están asociados con la IngressClass de origen. Después, aplica las configuraciones de nombre de dominio y de enrutamiento de dichos recursos.

   1. Suponga que tiene un Ingress llamado httpbin en el clúster de contenedores de origen.

   2. En la consola de Cloud Native Gateway, verá que el Ingress del clúster de origen se sincroniza automáticamente con la puerta de enlace de destino, lo que crea las configuraciones de dominio y de enrutamiento correspondientes. La página de detalles de Routing Settings se muestra de la siguiente manera:

      1. Asistente de configuración:

         1. Agregar origen de servicio

            Puede usar K8s, Nacos, Zookeeper, SAE, EDAS y Function Compute (FC) como orígenes de servicio. Es posible agregar un recurso existente de su VPC actual y luego seleccionar un servicio registrado a partir de él.

            Botón: Add service source

         2. Asociar servicio de backend

            Distribuye las solicitudes hacia un servicio de backend. Este servicio se puede descubrir dinámicamente desde un origen de servicio o especificarse mediante una dirección o un nombre de dominio estático.

            Botón: Associate backend service

         3. Vincular nombre de dominio

            Proporciona gestión multidominio. Al vincular un nombre de dominio, puede asociar protocolos, certificados y configuraciones de enrutamiento con distintos dominios.

            Botón: Bind domain name

         4. Crear ruta

            Una ruta contiene reglas de coincidencia basadas en nombres de dominio, rutas, métodos, parámetros de solicitud y encabezados de solicitud. Cuando un usuario accede a una ruta, la solicitud se reenvía al servicio de backend correspondiente.

            Botón: Create route

      2. Columnas de la lista: Route name, Status, WAF protection, Source, Route condition, Associated domain name, Destination service type, Destination service y Actions.

Paso 2: Comprobar las rutas

Compruebe la compatibilidad de las anotaciones de Ingress observadas:

• Si no hay anotaciones de Ingress incompatibles, continúe con el siguiente paso.

• Si encuentra anotaciones de Ingress incompatibles, puede enviar un ticket para obtener una solución.

  Importante

  • Puede ignorar la anotación nginx.ingress.kubernetes.io/service-weight si su valor es "". Esta anotación se agrega de forma predeterminada en versiones anteriores de la consola de Container Service y no tiene ningún efecto.

  • Durante la migración, no elimine las anotaciones incompatibles que estén en uso. Estas anotaciones aún son analizadas por el Nginx Ingress Controller y afectan el tráfico de su negocio. Puede agregar anotaciones extendidas de MSE al recurso de Ingress para lograr la misma funcionalidad en MSE Ingress. Una vez que todo el tráfico haya migrado a MSE Ingress, podrá quitar las anotaciones incompatibles según sea necesario.

Paso 3: Seleccionar el método de traslado

Pruebas antes de trasladar el tráfico

Antes de trasladar el tráfico de producción, ejecute una prueba local. Modifique su archivo hosts local para resolver el nombre de dominio de negocio hacia el SLB de Cloud Native Gateway. Utilice una herramienta como curl o Postman para comprobar que todo el tráfico se comporta según lo esperado.

Seleccionar el método de traslado

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': {}