Ha pasado casi un año y medio desde que la comunidad de Kubernetes anunció oficialmente la disponibilidad general de Gateway API, un hito que redefinió la forma de gestionar las redes y el tráfico en los clústeres de Kubernetes. No se trató de una mera actualización incremental, sino que supuso un cambio fundamental en las redes de los entornos nativos de la nube, al ofrecer un marco potente, extensible y expresivo para gestionar la conectividad.
La API Gateway sustituye las capacidades limitadas de la API Ingress por un diseño orientado a roles, recursos estandarizados y extensibilidad. Desde la incorporación de funciones avanzadas de enrutamiento y distribución del tráfico hasta la habilitación de la tenencia múltiple mediante su diseño orientado a roles, la API Gateway permite abordar casos de uso complejos que antes resultaban difíciles de gestionar. No es de extrañar que este cambio impulsara una innovación generalizada en todo el sector, ya que proveedores como F5 reconocieron su potencial para definir el futuro de las redes de Kubernetes.
Sin embargo, la adopción de un nuevo estándar como este no se produce de la noche a la mañana. Aunque la API Gateway ofrece ventajas claras, muchas organizaciones siguen actuando con cautela. Están sopesando detenidamente la complejidad de la migración y las herramientas de Ingress existentes frente a la configuración de enrutamiento estandarizada, pero flexible, de la API Gateway. Además, su decisión de adoptarla no depende únicamente de las limitaciones técnicas, sino de encontrar un equilibrio entre ventajas e inconvenientes. El tiempo, el esfuerzo y el riesgo que implica la transición deben verse compensados por mejoras significativas y tangibles en sus capacidades de red.
El ritmo más lento de adopción en el sector refleja este enfoque prudente. Aunque la API Gateway está ampliamente considerada como el futuro de las redes de Kubernetes, muchas organizaciones siguen explorando sus capacidades o evaluando las ventajas y los inconvenientes antes de comprometerse con una adopción a gran escala. Los informes de la comunidad de Kubernetes indican que la experimentación con la API Gateway aumenta de forma constante. Los primeros usuarios la están aprovechando para diversos casos de uso, desde el enrutamiento HTTP sencillo hasta arquitecturas multiinquilino avanzadas. Esto demuestra un interés creciente por las posibilidades de la API Gateway, aunque muchos equipos siguen adoptando una postura de cautela y prefieren esperar a ver cómo evoluciona.
En F5, hemos observado una dinámica similar. Muchos de nuestros clientes prefieren no dar el salto de inmediato. No es por falta de interés, sino porque buscan equilibrar la innovación con la seguridad operativa que ofrecen las soluciones de Ingress consolidadas. Por eso creemos que no es necesario apresurarse en la transición a Gateway API. Basta con abordarla de forma estratégica.
Analicémoslo en detalle. Algunos de los retos que plantea la migración a Gateway API son:
- Reestructuración compleja de la infraestructura: La migración puede requerir reescribir la automatización y modificar los flujos de trabajo de las aplicaciones existentes.
- Carencias en la compatibilidad del ecosistema: La compatibilidad total con herramientas y controladores aún está evolucionando.
- Falta de tiempo y conocimientos: La curva de aprendizaje y la refactorización requieren tiempo específico.
- Aversión al riesgo: Los equipos dudan a la hora de alterar lo que ya funciona.
Sin embargo, también hay ventajas considerables:
- Diseño orientado a roles: Los recursos de Gateway API se dividen según el rol dentro de la organización. Esto permite a los desarrolladores realizar cambios sin interferir en el trabajo de otros equipos.
- Políticas de tráfico estandarizadas: Muchas políticas de tráfico habituales están estrechamente integradas en la propia API, lo que permite una configuración uniforme en todas las implementaciones y mucho más fácil de gestionar que las anotaciones de Ingress.
- Extensibilidad: Los puntos de extensión permiten que las implementaciones amplíen la API de Gateway para ofrecer funcionalidades personalizadas dentro del marco de la API.
Si algo sabemos sobre la entrega de aplicaciones y la infraestructura, es esto: el cambio requiere tiempo y convencer a toda la empresa. El apoyo, la orientación y la innovación continuos son esenciales incluso para iniciar la transición.
Cómo abordar la adopción de Gateway API: perspectivas de F5
En F5, hemos participado activamente en el desarrollo y la evolución de las redes de Kubernetes. Hemos afrontado estos retos de primera mano y ayudado a los equipos a superarlos.
Nuestra experiencia confirma una verdad fundamental: adoptar con éxito la API de Gateway no consiste únicamente en implementar un nuevo estándar, sino en sentar las bases para el éxito futuro. Para lograrlo, las organizaciones necesitan soluciones que prioricen la sencillez, el rendimiento, la flexibilidad y un soporte sólido. Así es como estos principios facilitan una transición más fluida y sientan las bases para generar valor a largo plazo:
- Simplicidad mediante un enfoque desde cero: Migrar a la API Gateway requiere algo más que cambios técnicos. Supone un cambio cultural y operativo. Al partir de cero, podemos abordar todos los puntos débiles de Ingress y ofrecer una experiencia de red superior a través de una única interfaz: la API Gateway. Aunque esto puede requerir un mayor esfuerzo inicial, los beneficios a largo plazo —procesos optimizados, menor sobrecarga y resultados más rápidos— compensan con creces las dificultades.
- El rendimiento como base: El rendimiento de la red es fundamental, especialmente en entornos de Kubernetes de gran tamaño. Las implementaciones ligeras de Gateway API deben basarse en un plano de datos que procure minimizar la sobrecarga arquitectónica, lo que a su vez mejora la latencia, la eficiencia de los recursos y la escalabilidad. Las soluciones deben combinar la flexibilidad de Gateway API con un alto rendimiento predeterminado para garantizar que los equipos puedan realizar la transición sin sacrificar la velocidad ni la fiabilidad.
- Flexibilidad mediante un diseño modular: Los entornos de Kubernetes varían enormemente, desde necesidades básicas de enrutamiento hasta arquitecturas complejas. Las soluciones modulares de Gateway API permiten a los equipos adoptar funcionalidades junto con otras soluciones, como las mallas de servicios, para adaptarse a las necesidades de su entorno sin añadir complejidad. Este enfoque fomenta la experimentación y garantiza que las soluciones sigan siendo escalables y adaptables.
- El soporte como catalizador del éxito: El asesoramiento de expertos puede ser de gran ayuda a la hora de adoptar la API de Gateway. Una documentación completa, recursos fiables y asistencia práctica reducen las dificultades de la transición desde Ingress. Contar con socios de confianza y la participación de la comunidad simplifica enormemente la migración, convirtiendo un cambio abrumador en un proceso fluido y eficiente.
El futuro es Gateway API... a tu propio ritmo
Sabemos que 18 meses no es mucho tiempo y que, aunque la Gateway API haya abierto un mundo de posibilidades, eso no significa que todas las organizaciones estén ya preparadas para adoptarla.
Para muchos equipos, la API Ingress no solo es una solución eficaz, sino también un componente fundamental de su infraestructura actual. Durante años, la API Ingress ha sido la columna vertebral de las redes de Kubernetes. Las organizaciones con entornos consolidados no tienen por qué sentirse obligadas a abandonar una solución estable y satisfactoria.
En F5, somos plenamente conscientes de esta realidad, por lo que no vamos a abandonar la API de Ingress. Seguimos invirtiendo en el desarrollo de F5 NGINX Ingress Controller e incorporando innovaciones y funcionalidades que garantizan que siga siendo una solución sólida, segura y relevante para los casos de uso modernos.
Para las organizaciones que deseen seguir utilizando Ingress, nos comprometemos a garantizar que continúe siendo una solución de gran valor que permita ejecutar con confianza las cargas de trabajo actuales de Kubernetes. Para los equipos que estén explorando la API Gateway, nuestra solución diseñada específicamente para este fin, F5 NGINX Gateway Fabric, combina simplicidad moderna, rendimiento y flexibilidad para ayudar a las organizaciones a adoptar el estándar con confianza.
La decisión de migrar a la API Gateway supone un cambio importante que no tiene por qué producirse de la noche a la mañana. Sin embargo, a largo plazo, las organizaciones que den el paso estarán mejor posicionadas para crecer e innovar, al tiempo que sentarán las bases de su éxito futuro con un sistema moderno, escalable e interoperable que definirá el futuro de las redes de Kubernetes. Ya sea hoy o más adelante, en F5 estaremos preparados cuando usted lo esté. Para obtener más información, póngase en contacto con nosotros en F5.
Sobre los autores
Artículos relacionados del blog
Únete a F5 NGINX en AppWorld 2024
Descubre las numerosas razones para asistir al evento insignia de F5, que incluirá un emocionante anuncio sobre la cartera de productos NGINX.
Rotación de certificados SSL/TLS sin reinicios en NGINX Open Source
La función de diccionario compartido permite configurar NGINX sin necesidad de reiniciarlo al renovar los certificados SSL/TLS.
Exposición de APIs en Kubernetes
La unidad 2 de Microservices March 2022 se centra en cómo exponer tus API en Kubernetes. Aquí tienes enlaces a los recursos que necesitas: la retransmisión en directo del 14 de marzo, artículos de blog y otros recursos de preparación, y el laboratorio práctico «Protege las API de Kubernetes mediante la limitación de solicitudes».
NGINX Sprint 2.0: visión clara, código renovado y nuevos compromisos con el código abierto
Hoy, en NGINX Sprint 2.0, anunciamos cómo respaldaremos nuestra visión del futuro de las aplicaciones modernas con una mayor presencia en la comunidad de código abierto, incluida la participación en el proyecto comunitario Kubernetes, nuevos proyectos de software de código abierto y la arquitectura de referencia para aplicaciones modernas.
Presentamos NGINX Plus R22
NGINX Plus R22 incorpora nuevas funcionalidades, como la compatibilidad con OCSP para verificar la revocación de certificados en TLS mutuo, el uso de varios proveedores de identidad OIDC en una configuración, el seguimiento en tiempo real de la limitación de solicitudes y conexiones en el panel de NGINX Plus y mejoras en NGINX JavaScript.
Presentamos NGINX Plus R17
NGINX Plus R17 incorpora compatibilidad con la limitación de velocidad en dos fases y con TLS 1.3, la versión más reciente del protocolo Transport Layer Security. La configuración de OpenID Connect es más sencilla y NGINX ModSecurity WAF es el doble de rápido que antes. También se ha actualizado el módulo JavaScript de NGINX.