Kublr Brings Rolling Updates to Kubernetes

The newly-released Kublr 1.16, a tool that facilitates deploying enterprise-grade Kubernetes clusters, is the first multicloud and multiplatform Kubernetes platform to offer rolling updates for the open source container orchestration engine, the company behind the technology claims.

“This functionality is essential whether you want to ensure your infrastructure, applications, or production components are upgraded in a timely manner, or apply security fixes and patches as soon as they become available to avoid exploits,” said Oleg Chunikhin, chief technology officer of Kublr.

The typical process before the rolling updates capability was that IT professionals would need to deploy a different cluster and replicate the application to deliver service consistently while updating the original cluster. However, this new feature saves both time and resources because there is no need to run parallel clusters.

“In a Kubernetes and cloud native world, this ability is more critical than ever,” he said. “The ecosystem is evolving quickly and components are changing fast. Just think of Kubernetes’ 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 not feasible.”

“While cloud providers have been offering rolling updates for some time,” said Chunikhin, “this isn’t the case for providers that allow you to deploy clusters in your own infrastructures. Kublr being able to upgrade clusters in-place with no downtime and uniformly in all supported environments (whether cloud or on-prem) enables IT operations teams to scale without sacrificing flexibility and operational agility.”

How Does the New Feature Work?

Kublr posted a blog on its website that gives some insights into what IT teams can expect if they decide to utilize the rolling updates.

During an upgrade, Kublr automatically reschedules running applications from the nodes associated with the one being updated. This approach means users minimize the total number of running instances according to the specifics they set. Then, the app serves clients without causing downtime.

No matter if companies operate in on-premise environments or depend on Amazon Web Services (AWS), the Google Cloud Platform (GCP) or Microsoft Azure, version 1.16 supports them. Kublr also offers compatibility for bare metal and air-gapped environments. Users should expect the cluster and infrastructure upgrades to occur equally well in all of them.

Although other Kubernetes products allow performing updates, Kublr stands alone in offering these rolling updates because it is the first independent Kubernetes engine to provide them. People who are not yet Kublr customers can deploy the tool for free to see how it works for them and try out this new option.

Rolling Updates Can Integrate with Role-Based Access Control (RBAC)

Support for role-based access control (RBAC) is another recent development offered by Kublr, first made available in version 1.15. While accessing the Kublr user interface, people can choose either the company’s RBAC or the RBAC associated with Kubernetes. Kublr’s RBAC allows systems administrators to set the level of cluster access afforded to different user groups. The RBAC allows determining whether a person can create or update a cluster’s infrastructure or the Kubernetes version associated with that cluster.

Then, the RBAC that Kubernetes offers enables configuring permissions for what people associated with various user groups can do within the clusters. For example, people with the appropriate privileges within the system can edit and manage a cluster’s resources, including its resources and objects.

The Kublr user interface simplifies RBAC concerns. Regardless of whether a cluster uses RBAC from Kublr or Kubernetes, a user can access all of them in one place, which reduces confusion. Moreover, this setup bolsters security because it allows an authorized Kublr user to verify that the proper permissions are in effect for each cluster. Furthermore, there is a centralized RBAC feature that extends any RBAC permissions to the logs that clusters collect.

When announcing the rolling updates feature, Kublr announced that its RBAC capabilities remain present for people who use version 1.16.

Kubernetes Usage Is Rising

It should be easy for IT teams to understand why the rolling upgrades and RBAC capabilities associated with Kublr could streamline the way their companies use Kubernetes. Eliminating unnecessary steps associated with cluster deployment and management is essential, especially considering the growing number of companies of all sizes that are working with Kubernetes clusters.

According to a 2019 survey from the Cloud Native Computing Foundation, 78% of respondents said they are using Kubernetes in production. That percentage represents a 20% increase from the previous year’s findings. Also, the number of people in the evaluation stage decreased by nearly half (48%), as many of those former evaluators moved to the production phase.

Most of the respondents using Kubernetes said they had 2-5 clusters in production, with 43% choosing that amount. Relatedly, there was a 10% in the parties that said they had from 2-10 clusters in production.

These statistics collectively and strongly suggest that more IT decision-makers are concluding that Kubernetes is a smart choice for them. As their adoption rate of it continues to go up, features like those offered by Kublr could become increasingly relevant and appreciated.

More Straightforward Cluster Management

“Our ultimate goal is to become a true meta-cloud, Chunikhin said. “A new type of infrastructure with flexible, cloud native, enterprise-grade modules including storage, networking, data management, and BCDR, and deployable across different public cloud, private cloud, and on-prem infrastructure. That is pretty ambitious — we know that. It’s also reflected in our extensive roadmap, with each iteration we are getting a little closer and that’s pretty exciting.”

“We’ll expand the IT ops team’s ability to deliver Kubernetes across their organization in a reliable and well-governed manner,” he said. Planned features include:

• Maintaining Kubernetes and other components version parity
  Kublr is one of very few enterprise Kubernetes solutions that support the latest released Kubernetes version
• Support for externally provisioned clusters (e.g. cloud-managed Kubernetes and other Kubernetes provisioning and management tools). This feature will extend Kublr’s operational features such as centralized log collection, monitoring, security and RBAC to non-Kublr provisioned clusters.
• Extensive governance policies that will allow IT operations to define governance rules and limits within which software development teams can use and operate Kubernetes clusters, including network, access control, resource quotas, etc.
• Advanced capabilities related to multisite (multicloud, multiregion, hybrid) Kubernetes deployment including network connectivity, federation, data replication, multisite orchestration, and DR.
• A multitude of application packages and partner integrations such as CI/CD (Spinnaker, Jenkins), service meshes  (Istio, Linkerd), FaaS (OpenFaaS), security (NeuVector), storage (Ceph/Rook, Portworx, Yugabyte, HDFS), data science (Spark).