Ingress2gateway: migra de Kubernetes Ingress a Gateway API sin complicaciones

La herramienta Ingress2gateway está diseñada para simplificar la transición desde los recursos de Kubernetes Ingress hacia la Gateway API, más potente y expresiva. Ofrece un proceso de conversión sólido y automatizado que asegura una migración fluida y reduce al mínimo las interrupciones.

Funciones y capacidades clave:

✅ Conversión automática

• Analiza de forma inteligente los recursos Ingress existentes y genera configuraciones equivalentes de Gateway API, incluidos recursos Gateway, HTTPRoute y BackendPolicy.
• Procesa reglas, anotaciones y configuraciones complejas de Ingress, traduciéndolas a las especificaciones correspondientes de Gateway API.

✅ Conserva las reglas de enrutamiento:

• Mapea con precisión rutas de URL, hostnames y servicios backend desde las reglas de Ingress hacia las reglas de HTTPRoute.
• Garantiza que el comportamiento del enrutamiento se mantenga consistente tras la migración, evitando interrupciones inesperadas del servicio.
• Soporta varias funciones de enrutamiento, como coincidencia de rutas (prefijo, exacta, regex), coincidencia de hostnames y enrutamiento basado en headers.

✅ Soporta varios controladores Ingress

• Actualmente la herramienta soporta los proveedores apisix, cilium, ingress-nginx, istio, gce, kong y openapi, y la comunidad trabaja activamente para sumar más.

✅ Facilita la migración gradual:

• Permite una adopción incremental de Gateway API mediante la conversión selectiva de recursos Ingress.
• Soporta modos dry-run para previsualizar los resultados de la conversión antes de aplicar los cambios al clúster.
• Permite probar en paralelo los recursos de Ingress y Gateway API.

Para probar la herramienta necesitas un clúster de Kubernetes con Gateway API instalada. Varios proyectos soportan Gateway API y algunos proveedores de nube ofrecen una implementación totalmente gestionada.

En el siguiente ejemplo uso Google Kubernetes Engine y el controlador Ingress por defecto en GKE, ingress-gce.

Despliegue del workload de ejemplo y del recurso Ingress

• Despliega el workload de ejemplo httpbin.

---
apiVersion: v1
kind: Service
metadata:
  name: httpbin
  labels:
    app: httpbin
spec:
  ports:
  - name: http
    port: 8000
    targetPort: 80
  selector:
    app: httpbin
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: httpbin
spec:
  replicas: 1
  selector:
    matchLabels:
      app: httpbin
  template:
    metadata:
      labels:
        app: httpbin
    spec:
      containers:
      - image: docker.io/kennethreitz/httpbin
        imagePullPolicy: IfNotPresent
        name: httpbin
        ports:
        - containerPort: 80

Ejemplo de deployment y service de Kubernetes

• Crea un recurso Ingress para el deployment de httpbin.

---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: httpbin-ingress
  namespace: default
spec:
  rules:
  - host: httpbin.example.com
    http:
      paths:
      - backend:
          service:
            name: httpbin
            port:
              number: 8000
        path: /
        pathType: Prefix

Ejemplo de recurso Ingress

Instalar y ejecutar ingress2gateway

• Sigue la documentación de instalación para instalar ingress2gateway o descarga el binario desde la página de releases.
• Ejecuta ingress2gateway para tu proveedor específico. Esto lee los recursos Ingress y/o los CRDs específicos del proveedor desde un clúster de Kubernetes o un archivo, y entrega los recursos equivalentes de Gateway API en formato YAML/JSON por stdout.

La salida se verá así:

Ejemplo de recursos Gateway API generados por ingress2gateway

Nota: ingress2gateway no está pensado para copiar anotaciones de Ingress a Gateway API. En su lugar, convierte las anotaciones a CRDs de Gateway; aun así, algunas anotaciones y/o CRDs muy usados específicos de cada proveedor todavía pueden no estar soportados. Consulta supported providers para ver los proveedores soportados actualmente y su documentación.

Ejemplo de recursos Gateway API

• Revisa el manifiesto generado para confirmar que contiene todas las configuraciones necesarias antes de llevarlo a producción. Realiza una prueba de extremo a extremo antes de eliminar los recursos Ingress existentes.