When evaluating Kubernetes providers, you’ll quickly see that they ALL support upgrades. But here’s a little dirty secret, no independent Kubernetes multi-cloud, multi-cluster platform supports rolling updates. Instead, you’ll need to deploy a different cluster and replicate your app to ensure service delivery while the original cluster is updated. That process is cumbersome and requires far too many resources. That’s why we are thrilled to announce Kublr’s rolling updates capability.

Rolling Updates with Zero Downtime

You probably don’t need to be sold on rolling updates, the benefits are obvious. Whether you want to ensure your infrastructure, applications, or production component are upgraded in a timely matter, this functionality will speed up security upgrades as well as the ability to benefit from the newest application and infrastructure functionalities.

However, in a Kubernetes and cloud native world, this ability is more critical than ever. Components are changing fast. Just think of Kuberentes’ quarterly updates. And then there are all the other components, each of which has its own release schedule. This is a far cry from the traditional hardware/VM infrastructure where updates were released at a far slower pace. Your Ops and DevOps teams will want to leverage new functionalities right away and shutting clusters down each time to do so, is just not feasible.

While cloud providers have been offering rolling updates for some time, this isn’t the case for providers that allow you to deploy clusters in your own infrastructures. That’s why our team is excited about this new release allowing users to upgrade their Kubernetes clusters with zero app downtime.

How it works

Kublr will upgrade nodes one by one automatically rescheduling  running applications from the nodes under upgrade. This ensures you keep the minimal amount of running instances according to your settings and that, during the upgrade, the app can serve the clients without experience downtime. The cluster and infrastructure upgrades work equally in all supported environments, whether AWS, Azure, GCP, or on-prem.

Users can opt for rolling upgrades without downtime or upgrades with some degree of service interruption. While the latter will ensure a faster upgrade, it will turn the cluster off for some limited time. It’s up to you to decide whether speed or availability should be prioritized.

Rolling Kubernetes upgrades vs blue-green upgrade

While upgrading Kubernetes in itself is no easy task, ensuring there is no service disruption is really hard. It requires advanced Kuberentes component and infrastructure orchestration and is probably the reason why it’s not widely available yet. So yes, our competitors do offer upgrades but will force you to run two parallel clusters to ensure service delivery and upgrade them one after another. That’s not the experience we want you to have.

To date, Kublr is the only multi-cloud, multi-cluster independent Kubernetes platform that supports rolling upgrades on all supported infrastructures including on-prem, bare metal and even air-gapped environments. Together with our strong governance and security capabilities (e.g. RBAC), Kublr provides enterprises with even more control over their infrastructure. But don’t take our word for it. Deploy Kublr for free today and see for yourself.