Support for Kubernetes

[dvaldivia]

Support for Kubernetes

[rgrandl]

Hi @dvaldivia, @ShotaKitazawa and all,

We implemented a vanilla Kubernetes deployer that enables to run Service Weaver applications in any Kubernetes environment.

The main missing piece is traffic-shifting, which we plan to add soon. We are considering using argo rollouts for that.

If you would like to try the kubernetes deployer, provide any feedback, or help us improve it, please let us know.

[cloudxu]

I would love to see it can align with argocd and argo rollouts paradigm. As for real large application. clusters are managed by other configuration manager code. we don't really need to have the weaver command to support the whole global traffic management.

[rgrandl]

@cloudxu, @dvaldivia, @ShotaKitazawa you can add argocd / argo in the mix. We've played around with it and it should work. Let us know if you have any other questions.

[spetrovic77]

Hi @dvaldivia,

We would love to support vanilla Kubernetes. The main reasons we launched with GKE support are:

1. GKE supports multi-region/multi-cluster applications, and
2. GKE load-balancers come with traffic-shifting capabilities.

Of the two, (2) was more important. Service Weaver makes the guarantee that a version X of an application only talks to other instances of version X. This typically means that a blue/green deployment is required (i.e., can't update Pods via rolling updates). An automated blue/green deployment strategy requires traffic shifting. Note that traffic-shifting can be achieved in vanilla Kubernetes using Istio, but we haven't done that yet.

Would you be interested in helping create a vanilla Kubernetes deployer?

[dvaldivia]

Totally, what is needed?

[ShotaKitazawa]

I knew Weaver recently, and I'm interested in supporting a vanilla Kubernetes.

I think traffic-shifting can be supported as the following.

• Pods of main process, which is entrypoint from the external, have a same label on blue/green versions. And Service tied to Ingress is specified this label on labelSelector.
  • My understanding, this way should be the same as Argo Rollout without Istio.
• Pods of other processes are tied to the label of individual versions.

I don't understand the implementation of deployer still now, So I'll investigate to know it at first.

[spetrovic77]

Hi Kanata,

That would be excellent! Please let us know if you need anything from us in this process. Feel free to use the GKE deployer as a reference: it uses the Go K8s libraries extensively.

Re: blue/green. I think what you suggested is good except that gradual traffic shifting isn't supported by Kubernetes constructs. In other words, it would be ideal if Ingress slowly transitions traffic from the old deployed version to the new.

At least for GKE, this support added a ton of complexity. However, perhaps for vanilla Kubernetes we should just start with an atomic switch from the old version to the new? We can worry about adding Istio or some such later, if people really care about it. WDYT?

[ShotaKitazawa]

Re: blue/green. I think what you suggested is good except that gradual traffic shifting isn't supported by Kubernetes constructs. In other words, it would be ideal if Ingress slowly transitions traffic from the old deployed version to the new.

Regarding the above, it is possible to be almost realized by vanilla K8s way.

For example, in case we want to forward 20% of traffic to the new version, and in case the number of replicas is 5, it is good to be deployed 1 new Pod and 4 old Pods.

• FYR: https://argoproj.github.io/argo-rollouts/features/canary/#overview → Important column

Anyway, I agree with your following opinion!

However, perhaps for vanilla Kubernetes we should just start with an atomic switch from the old version to the new? We can worry about adding Istio or some such later, if people really care about it.