I have a REST API with multiple API-versions. Each API backend is composed of several micro-services. It is fair to assume that only the latest REST API resources/code has most churn. The older versions will see churn due to feature backport (rarely) or bug fixes (mostly). I'd like to get recommendations on what DevOps pattern would best fit this scenario - assuming we are using Kubernetes to model our service mesh.
Note that our APIs are mostly async and so it is possible to support several API versions all in the same codebase (packaged in a single container).
Given the above, these configurations are all possible
Additional points to ponder:
I'm looking for any prescribed patterns or suggestions based on your prior experience.
In general, Deployments manage replicas of Pods, and each Pod runs a specific container image. If your API backend consists of multiple microservices, then each microservice is a Deployment. The microservice that handles API requests is exposed with a (client-facing) Service.
For the multiple API versions, you could just replicate this for each version and you could put an Ingress in front of the Services which routes traffic to one of them based on the requested API version.
If you put all the API versions in the same container, you may have a problem of inconsistent state during updates: 1) inside a Deployment, for a short time both Pod versions exist side by side (if you use the default rolling update); 2) for a short time you might have both updated and not yet updated microservices next to each other.