[Feature] Upgrade guidelines for production deployment

[Sharathmk99]

Is your feature request related to a problem? Please describe.
Currently we run liqo 0.8.0 version in our cluster and looking forward to upgrade to latest version0.8.1 without disturbing the running workloads across many peered remote clusters.

We don't use liqo networking component as remote pod doesn't require any communication with home cluster services.

Mainly we have below component in our cluster

• liqo-auth
• liqo-controller
• liqo-crd-replicator
• liqo-metric-agent
• liqo-proxy

When we upgrade using helm upgrade ..... it updates only above component with new version docker images and manifest changes only, but it will not update any CRD related changes and also it will not update virtualkubelet docker images. As virtualkubelet deployment is created dynamically by liqo-controller.

When there is a breaking changing in liqo CRD can we have new version with support to older CRD version, so we can migrate to newer CRD version later? Similar to how Kubernetes does for core resources(eg. deployment).
How can we upgrade virtualkubelet deployment without distributing any offloaded workloads(eg namespace, pod, secret, configmap)

Guidelines of upgrading to newer version without any interruption to workload is key for production cluster.

Describe the solution you'd like
Not sure, need to brainstrom

Describe alternatives you've considered
Nothing for now. As we can't un-peer any remote cluster as it will interrupt running workloads.

Additional context
NA

[frisso]

This feature is becoming very very important; thanks for opening a feature request..
We should decide when to add this to the roadmap, likely after release 0.9 (whose features have already been decided).
If anybody wants to contribute to this feature, which definitely requires a non negligible amount of work, please add your rocket here :-)

[Sharathmk99]

I would be happy to be part of this effort. It’s very important feature for us. Thanks

[Sharathmk99]

Today tried to upgrade limo version from 0.8.1 to 0.8.3, all core services were fine. But how can I force the virtual-kubelet pod in all remote cluster namespace to use latest version 0.8.3 now?
If I delete the deployment will limo-controller automatically recreates the deployment? Or the only way is to unpeer and peer again?

[ryan-beisner]

Adding rockets :-) 🚀 🚀 🚀 Definitely something needed for prod.

[cheina97]

Today tried to upgrade limo version from 0.8.1 to 0.8.3, all core services were fine. But how can I force the virtual-kubelet pod in all remote cluster namespace to use latest version 0.8.3 now? If I delete the deployment will limo-controller automatically recreates the deployment? Or the only way is to unpeer and peer again?

Hi @Sharathmk99, this is one of the collateral features that will be introduced with VirtualNode CRD. For the moment we suggest to unpeer and peer again.

[frisso]

@Sharathmk99 I know that the previous answer is not a good news for you. On the good side, we're taking this into high consideration for the post-0.9 release.

[Sharathmk99]

Thank you @frisso & @cheina97 for the update and considering this feature for post 0.9 release. I’m looking forward for Virtual Kubelet CRD for better upgrade process.