Tiene múltiples microservicios, cada uno exponiendo API REST como Kubernetes Services separados. Para evitar romper los consumidores de API y las integraciones de terceros al lanzar nuevas versiones de API, ¿cómo debería enrutar las solicitudes?

Un Ingress es la solución más adecuada aquí. Permite definir reglas de enrutamiento basadas en la URL de la API, el host u otros criterios, dirigiendo las solicitudes a diferentes versiones de sus microservicios (por ejemplo, /api/v1/users a un servicio y /api/v2/users a otro). Esto desacopla a los consumidores de las implementaciones de backend y facilita las actualizaciones sin tiempo de inactividad. Las otras opciones son menos efectivas: Un sistema de descubrimiento de servicios ayuda a los servicios internos a encontrarse entre sí, pero no gestiona el enrutamiento externo de API ni el versionado de forma transparente para los clientes. Desplegar múltiples clústeres es excesivo y complejo para el simple enrutamiento de versiones de API. Combinar versiones en el mismo Service complica la gestión del código y la implementación, y no es una práctica recomendada para el versionado de API.