Esta página se ha traducido con Cloud Translation API.

Migrar Ingress a la API Gateway

Autopilot Standard

En esta página se explica cómo migrar la gestión del tráfico en Google Kubernetes Engine (GKE) de la API Ingress a la API Gateway. Gateway API proporciona una solución totalmente gestionada para gestionar el tráfico de tu aplicación. Google Cloud

Para minimizar el tiempo de inactividad y mitigar los riesgos, la forma más eficaz de migrar a la API Gateway es ejecutar simultáneamente la API Ingress y la nueva API Gateway. Este método permite probar a fondo la nueva configuración de Gateway en un entorno activo sin que afecte a los servicios actuales. Una vez que hayas validado la nueva configuración de Gateway, puedes hacer un cambio rápido de DNS para redirigir el tráfico a la API Gateway y asegurarte de que la transición sea fluida y con poco riesgo.

A grandes rasgos, la estrategia de migración consta de las siguientes fases:

Configura el nuevo balanceador de carga.
Define reglas para gestionar el tráfico entrante.
Implementa la nueva configuración y prueba el flujo de tráfico a la nueva dirección IP de la pasarela.
Cambia el tráfico de producción a la API Gateway.
Elimina los recursos de Ingress restantes.

Configurar el nuevo balanceador de carga

En esta fase, despliega un recurso de Kubernetes Gateway para balancear la carga del tráfico a tu clúster de GKE. Cuando despliega un recurso Gateway, GKE configura un balanceador de carga de aplicación de capa 7 para exponer el tráfico HTTP(S) a las aplicaciones que se ejecutan en el clúster. Implementa un recurso Gateway por cada clúster o balanceador de carga que necesites.

En el siguiente ejemplo, se configura un balanceador de carga de aplicación externo global. Para crear un Gateway, guarda el siguiente manifiesto como gateway.yaml:

kind: Gateway
apiVersion: gateway.networking.k8s.io/v1
metadata:
  name: external-http-gateway
spec:
  gatewayClassName: gke-l7-global-external-managed # GKE's managed external Application Load Balancer
  listeners:
  - name: http
    protocol: HTTP
    port: 80
    allowedRoutes:
      namespaces:
        from: Same # Only allow HTTPRoutes from the same namespace

El manifiesto anterior describe una Gateway que incluye los siguientes campos:

gatewayClassName: gke-l7-global-external-managed: especifica la GatewayClass de esta pasarela. Esta clase Gateway usa un balanceador de carga de aplicación externo global.
protocol: HTTP y port: 80: especifica que la pasarela expone el puerto 80 para el tráfico HTTP.

Definir reglas de tráfico para el tráfico entrante

Los recursos de ruta definen reglas específicas de protocolo para asignar tráfico de un Gateway a servicios de backend.

En esta fase, traduce el manifiesto de Ingress a un recurso HTTPRoute. Para convertir el manifiesto de Ingress, sigue los pasos que se indican en la herramienta ingress2gateway.

En este ejemplo se da por hecho que tienes el siguiente recurso Ingress:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: cafe-ingress
spec:
  ingressClassName: nginx
  rules:
  - host: cafe.example.com
    http:
      paths:
      - path: /tea
        pathType: Prefix
        backend:
          service:
            name: tea-svc
            port:
              number: 80
      - path: /coffee
        pathType: Prefix
        backend:
          service:
            name: coffee-svc
            port:
              number: 80

Después de convertir el archivo de manifiesto con la herramienta ingress2gateway, se genera el archivo de manifiesto HTTPRoute traducido.

Guarda el siguiente archivo de manifiesto de ejemplo como httproute.yaml:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: cafe-route
spec:
  # This route attaches to our new Gateway
  parentRefs:
  - name: external-http-gateway
  # The hostname is the same as before
  hostnames:
  - "cafe.example.com"
  # The routing rules are now more explicit
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /tea
    backendRefs:
    - name: tea-svc
      port: 80
  - matches:
    - path:
        type: PathPrefix
        value: /coffee
    backendRefs:
    - name: coffee-svc
      port: 80

Ten en cuenta que el campo rules del manifiesto HTTPRoute se corresponde directamente con las reglas de enrutamiento definidas en el manifiesto Ingress original.

Implementa y prueba la nueva configuración

En esta fase, aplicará los manifiestos de Gateway y HTTPRoute que ha creado en las dos fases anteriores y comprobará que el tráfico se dirige a la nueva dirección IP de Gateway.

Aplica los manifiestos de Gateway y HTTPRoute:

kubectl apply -f gateway.yaml
kubectl apply -f httproute.yaml

Obtén la dirección IP de la pasarela. Puede que tarde unos minutos en asignar la dirección IP:
```
kubectl get gateway external-http-gateway -o=jsonpath="{.status.addresses[0].value}" --watch
```
El resultado es la dirección IP externa de la pasarela, por ejemplo, 203.0.113.90.
Prueba la nueva dirección IP de la pasarela. Usa el siguiente comando curl para enviar una solicitud a la dirección IP y especificar el nombre de host cafe.example.com. Por ejemplo:
```
curl --resolve cafe.example.com:80:203.0.113.90 http://cafe.example.com/tea
curl --resolve cafe.example.com:80:203.0.113.90 http://cafe.example.com/coffee
```
Sustituye 203.0.113.90 por la dirección IP externa que has obtenido en el paso anterior. El resultado confirma que la nueva dirección IP de la pasarela enruta correctamente el tráfico de cafe.example.com sin realizar una búsqueda de DNS.

Dirige el tráfico a la nueva dirección IP de la pasarela

En esta fase, cambia el tráfico activo de tu Ingress anterior al nuevo Gateway actualizando tus registros DNS para que apunten a la nueva dirección IP del Gateway. Los pasos exactos para actualizar los registros DNS varían en función de tu proveedor de DNS.

Por ejemplo, si has configurado cafe.example.com en Ingress, busca el registro A de cafe.example.com con tu proveedor de DNS y cambia el valor de la antigua dirección IP de Ingress por 203.0.113.90, que es la nueva dirección IP de Gateway.

Después de actualizar el registro DNS, el tráfico empieza a pasar de Ingress a Gateway, pero el cambio no se produce inmediatamente para todos los clientes. Los resolutores de DNS que tengan en caché el registro anterior esperan a que caduque el valor de tiempo de vida (TTL) del registro antes de volver a consultar el registro y recibir la dirección IP actualizada. Por este motivo, debes seguir usando tu Ingress y tu Gateway al mismo tiempo hasta que verifiques que el tráfico a Ingress ha cesado, lo que indica que la propagación de DNS se ha completado y que los clientes ya no se dirigen a la antigua dirección IP. Para comprobarlo, monitoriza el tráfico de tu balanceador de carga o controlador de entrada. Para obtener más información, consulta Comprobar la propagación de DNS.

Si usas Cloud DNS, puedes usar pesos de destino para cambiar gradualmente el tráfico de la dirección IP antigua a la nueva. Para obtener más información, consulta el artículo sobre cómo configurar políticas de enrutamiento de DNS y comprobaciones de estado.

Limpiar los recursos de Ingress restantes

Después de confirmar que tu nuevo Gateway funciona correctamente, limpia los recursos de Ingress antiguos.

Elimina el recurso Ingress:
```
kubectl delete ingress cafe-ingress
```
Desinstala el controlador ingress-nginx. Por ejemplo, si has usado Helm para instalar el controlador, ejecuta el siguiente comando:
```
helm uninstall ingress-nginx -n ingress-nginx
```

Comparación de funciones entre Ingress NGINX y GKE Gateway

Gateway API ofrece una forma más estandarizada de configurar el tráfico de entrada y tiene paridad de funciones para las funciones más comunes, como el enrutamiento, los encabezados y la división del tráfico.

En la siguiente tabla se comparan las anotaciones que se usan para las funciones comunes en el controlador Ingress y la API Gateway.

Función	Anotación en Ingress	Anotación en GKE Gateway	Paridad
Reescrituras de URLs	`nginx.ingress.kubernetes.io/rewrite-target`	`HTTPRoute` con un filtro `urlRewrite`.	Paridad parcial. GKE Gateway solo admite sustituciones de prefijos.
Manipulación de encabezados	`nginx.ingress.kubernetes.io/proxy-set-headers` o `add-headers`	`HTTPRoute` con un modificador `requestHeaderModifier` o un filtro `responseHeaderModifier`.	Paridad total.
Enrutamiento basado en rutas	`spec.rules.http.paths` en el objeto Ingress.	`rules.matches.path` en el objeto HTTPRoute.	Paridad total.
Enrutamiento basado en hosts	`spec.rules.host` en el objeto Ingress.	`hostnames` en el objeto HTTPRoute.	Paridad total.
División del tráfico	`nginx.ingress.kubernetes.io/canary` anotaciones.	`HTTPRoute` con `backendRefs` ponderado.	Paridad total. Además, puedes dividir el tráfico con un control pormenorizado.
Autenticación	`nginx.ingress.kubernetes.io/auth-url` para la autenticación externa.	Identity-Aware Proxy (IAP): `BackendPolicy` CRD. Otros: requiere un enfoque más personalizado, posiblemente con una malla de servicios o filtros personalizados.	Paridad parcial. Identity-Aware Proxy es la forma recomendada de proteger tu pasarela y se configura en el backend.

Siguientes pasos

Consulta cómo proteger tu Gateway.
Consulta cómo funciona la gestión del tráfico de la pasarela.