Google utiliza tecnología de IA para traducir contenido a tu idioma preferido. Las traducciones realizadas con IA pueden contener errores.

Migra Ingress a la API de Gateway

Autopilot Standard

En esta página, se muestra cómo migrar la administración del tráfico en Google Kubernetes Engine (GKE) de la API de Ingress a la API de Gateway. La API de Gateway proporciona una solución Google Cloud completamente administrada para controlar el tráfico de tu aplicación.

Para minimizar el tiempo de inactividad y mitigar el riesgo, el enfoque más eficaz para migrar a la API de Gateway es ejecutar la API de Ingress existente y las configuraciones nuevas de la API de Gateway de forma simultánea. Este método permite realizar pruebas exhaustivas de la nueva configuración de la puerta de enlace en un entorno activo sin afectar tus servicios actuales. Después de validar la configuración nueva de Gateway, puedes realizar una migración de sistemas rápida de DNS para redireccionar el tráfico a la API de Gateway y ayudar a garantizar una transición fluida y de bajo riesgo.

En términos generales, la estrategia de migración implica las siguientes fases:

Configura el nuevo balanceador de cargas.
Define reglas para controlar el tráfico entrante.
Implementa la configuración nueva y prueba el flujo de tráfico a la dirección IP de la puerta de enlace nueva.
Cambia el tráfico de producción a la API de Gateway.
Borra los recursos de Ingress restantes.

Configura el nuevo balanceador de cargas

En esta fase, implementarás un recurso de puerta de enlace de Kubernetes para balancear las cargas del tráfico en tu clúster de GKE. Cuando implementas un recurso de Gateway, GKE configura un balanceador de cargas de aplicaciones de capa 7 para exponer el tráfico HTTP(S) a las aplicaciones que se ejecutan en el clúster. Implementas un recurso de Gateway para cada clúster o para cada balanceador de cargas que necesites.

En el siguiente ejemplo, configurarás un balanceador de cargas de aplicaciones externo global. Para crear una puerta de enlace, 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

En el manifiesto anterior, se describe una puerta de enlace que incluye los siguientes campos:

gatewayClassName: gke-l7-global-external-managed: especifica la GatewayClass para esta puerta de enlace. Esta clase de Gateway usa un balanceador de cargas de aplicaciones externo global.
protocol: HTTP y port: 80: especifican que la puerta de enlace expone el puerto 80 para el tráfico HTTP.

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

Los recursos de ruta definen reglas específicas del protocolo para asignar tráfico de una puerta de enlace a servicios de backend.

En esta fase, traducirás tu manifiesto de Ingress en un recurso HTTPRoute. Para convertir el manifiesto de Ingress, sigue los pasos de la herramienta ingress2gateway.

En este ejemplo, se supone que tienes el siguiente recurso de 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 manifiesto con la herramienta ingress2gateway, el resultado es el manifiesto de HTTPRoute traducido.

Guarda el siguiente manifiesto de muestra 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 en el manifiesto de HTTPRoute corresponde directamente a las reglas de enrutamiento definidas en el manifiesto de Ingress original.

Implementa y prueba la nueva configuración

En esta fase, aplicarás los manifiestos de Gateway y HTTPRoute que creaste en las dos fases anteriores y probarás que el tráfico fluya a la nueva dirección IP de la puerta de enlace.

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 puerta de enlace. La asignación de la dirección IP puede tardar unos minutos:
```
kubectl get gateway external-http-gateway -o=jsonpath="{.status.addresses[0].value}" --watch
```
El resultado es la dirección IP externa de la puerta de enlace, por ejemplo, 203.0.113.90.
Prueba la nueva dirección IP de la puerta de enlace. Usa el siguiente comando de 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
```
Reemplaza 203.0.113.90 por la dirección IP externa que obtuviste en el paso anterior. El resultado confirma que la nueva dirección IP de Gateway enruta correctamente el tráfico para cafe.example.com sin realizar una búsqueda de DNS.

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

En esta fase, cambias el tráfico en vivo de tu Ingress anterior a la nueva puerta de enlace. Para ello, actualiza tus registros DNS para que apunten a la nueva dirección IP de la puerta de enlace. Los pasos exactos para actualizar los registros DNS varían según el proveedor de DNS.

Por ejemplo, si configuraste cafe.example.com en Ingress, ubicarías el registro A para cafe.example.com con tu proveedor de DNS y cambiarías el valor de la dirección IP de Ingress anterior a 203.0.113.90, que es la nueva dirección IP de la puerta de enlace.

Después de actualizar el registro DNS, el tráfico comienza a cambiar de Ingress a Gateway, pero la migración de sistemas no se produce de inmediato para todos los clientes. Los agentes de resolución de DNS que tienen el registro anterior almacenado en caché esperan a que caduque el valor del tiempo de actividad (TTL) del registro antes de volver a consultar el registro y recibir la dirección IP actualizada. Por este motivo, debes seguir ejecutando el Ingress existente y la nueva Gateway en conjunto hasta que verifiques que el tráfico al Ingress se detuvo, lo que indica que la propagación de DNS se completó y los clientes ya no se dirigen a la dirección IP anterior. Para verificarlo, supervisa el tráfico en el balanceador de cargas o el controlador de Ingress. Para obtener más información, consulta Verifica la propagación de DNS.

Si usas Cloud DNS, puedes usar pesos de destino para cambiar de forma incremental el tráfico de la dirección IP anterior a la nueva. Para obtener más información, consulta Configura políticas de enrutamiento de DNS y verificaciones de estado.

Limpia los recursos de Ingress restantes

Después de confirmar que tu nueva puerta de enlace se ejecuta correctamente, limpia los recursos de Ingress antiguos.

Borra el recurso Ingress:
```
kubectl delete ingress cafe-ingress
```
Desinstala el controlador ingress-nginx. Por ejemplo, si usaste 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

La API de Gateway proporciona una forma más estandarizada de configurar Ingress y tiene paridad de funciones para la mayoría de las funciones comunes, como el enrutamiento, los encabezados y la división del tráfico.

En la siguiente tabla, se compara la configuración que se usa para las funciones comunes en el controlador de Ingress y la API de Gateway.

Función	Anotación en Ingress	Configuración en la puerta de enlace de GKE	Paridad
Enrutamiento basado en el host	El campo `spec.rules.host` en el objeto Ingress	El campo `hostnames` en el objeto HTTPRoute	Paridad total.
Enrutamiento basado en rutas	El campo `spec.rules.http.paths` en el objeto Ingress.	El campo `rules.matches.path` en el objeto HTTPRoute	Paridad total.
División del tráfico	`nginx.ingress.kubernetes.io/canary` anotaciones	HTTPRoute con el campo `backendRefs` ponderado.	Paridad total. Además, puedes dividir el tráfico con un control detallado.
Afinidad de sesión	Anotaciones `nginx.ingress.kubernetes.io/affinity` y `nginx.ingress.kubernetes.io/affinity-mode`.	GCPTrafficDistributionPolicy con el campo `sessionAffinity`.	Paridad total. GKE Gateway admite varios tipos de afinidad de sesión, incluidos los tipos de afinidad basados en cookies (`HTTP_COOKIE`, `GENERATED_COOKIE` y `STRONG_COOKIE_AFFINITY` con estado), la afinidad basada en encabezados (`HEADER_FIELD`) y la afinidad basada en la IP del cliente (`CLIENT_IP`).
CORS (uso compartido de recursos de origen cruzado)	`nginx.ingress.kubernetes.io/enable-cors`	HTTPRoute con un filtro `CORS`.	Paridad total. Nota: GKE Gateway impone límites en la cantidad de patrones de comodín que puedes definir por objeto de escucha o nombre de host.
Reescrituras de URL	`nginx.ingress.kubernetes.io/rewrite-target`	HTTPRoute con un filtro `urlRewrite`.	Paridad parcial. GKE Gateway solo admite reemplazos 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.
Autenticación	`nginx.ingress.kubernetes.io/auth-url` para la autenticación externa.	Identity-Aware Proxy (IAP): recurso personalizado GCPBackendPolicy. 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 puerta de enlace y se configura en el backend.

¿Qué sigue?

Obtén más información para proteger tu puerta de enlace.
Lee cómo funciona la administración del tráfico de Gateway.