Hai più microservizi, ognuno dei quali espone API REST come Kubernetes Services separati. Per evitare di interrompere i consumer di API e le integrazioni di terze parti durante il rilascio di nuove versioni di API, come dovresti instradare le richieste?

Un Ingress in Kubernetes è progettato per gestire l'accesso esterno ai servizi all'interno del cluster, offrendo funzionalità come il bilanciamento del carico, la terminazione SSL e il routing basato su host o percorso. In questo scenario, un Ingress può essere configurato per instradare le richieste a diverse versioni di un microservizio (ad esempio, /api/v1/users a un Service e /api/v2/users a un altro Service), consentendo di rilasciare nuove versioni senza interrompere i consumer esistenti. Le altre opzioni sono meno efficaci: Un sistema di service discovery aiuta i microservizi a trovarsi a vicenda, ma non gestisce il routing esterno basato su URL per la compatibilità delle API. Distribuire più cluster e usare DNS è una soluzione più complessa e costosa, tipicamente usata per l'isolamento o la resilienza geografica, non primariamente per il versioning delle API all'interno di un'applicazione. Combinare più versioni API nello stesso Service e richiedere al client di specificare la versione nelle richieste POST sposta l'onere della gestione del versioning sul client e può essere problematico per le integrazioni di terze parti esistenti.