Kubernetes POD versions

Question

Does Kubernetes allow multiple versions of same micro service (not Kubernetes service) to be deployed in a Kubernetes cluster at any given point in time?

So, let's say I have a micro-service "MyCalculator". I create a POD to host this service. this is v1 of the "MyCalculator". I need that as new versions of the services are created, Kubernetes cluster allows these services to be deployed in the cluster, like so.

"MyCalculatorKubeService"/v1

"MyCalculatorKubeService"/v2

...

"MyCalculatorKubeService"/vn

The idea here is dynamically allow new versions, and allow access to these versions through a convention specified above. In the example above, I am thinking that the "MyCalculatorKubeService" is a kubernetes service. The unused versions get decommissioned over a period of time through a manual trigger after reviewing which services are not getting any traffic for say x days.

Thanks,

Answer 1

For this scenario you will have to maintain a separate pod for each versions you want to keep alive. Use ingress to create separate virtual paths to each version of your application

  - host: example.com
    http:
      paths:
      - backend:
          serviceName: app-v1
          servicePort: 80
        path: /app/v1/
      - backend:
          serviceName: app-v2
          servicePort: 80
        path: /app/v2/

Answer 2

Posting this as Community Wiki as its extension of @Charlie's answer.

As it was mentioned in @Charlie's answer you can do it using Ingress.

There are some Ingress Controllers, however Kubernetes officially supports only two.

Kubernetes as a project currently supports and maintains GCE and nginx controllers.

If you would like to use Nginx Ingress on GKE you need to add annotation to your Ingress manifest.

annotations: 
  kubernetes.io/ingress.class: nginx

You could also use Nginx Ingress Rewrite annotation.

When you are using Ingress, your services can be NodePort or ClusterIP types.

Depends on your needs you can specify which path should redirect to which service but you can also use default backend if you provide some random path like on example below:

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: my-ingress
spec:
  backend:
    serviceName: hello-world
    servicePort: 60000
  rules:
  - http:
      paths:
      - path: /v1
        backend:
          serviceName: MyCalculatorKubeService/v1
          servicePort: 60000
      - path: /v2
        backend:
          serviceName: MyCalculatorKubeService/v2
          servicePort: 80

If you would provide path like MyCalculatorKubeService/vasdsadsa it would redirect to default backend which is hello-world service in this case. It might be used in some workarounds.