Kublr Enables Rolling Kubernetes Upgrades
Kublr, a provider of a namesake set of tools for managing Kubernetes clusters, has added a rolling update capability that promises to make it easier to operationalize Kubernetes at scale.
Company CTO Oleg Chunikhin says that as organizations embrace Kubernetes, it has become apparent there is a need for a more efficient way to update multiple clusters deployed on-premises and in the cloud at the same time. Version 1.16 of Kublr makes it easier to achieve that goal by eliminating the need to replicate an application on to another Kubernetes cluster while the original cluster is being upgraded.
Kublr works by allowing IT teams to employ a self-service portal to upgrade Kubernetes nodes one by one while automatically rescheduling running applications to run on different nodes while that node is being upgraded. This ensures IT teams only need to keep the minimal number of instances of Kubernetes pods and clusters running at any time, Chunikhin says, noting it will be up to each IT team to decide to what degree they may want to interrupt services during a migration or take a Kubernetes cluster offline altogether.
Lifecycle management for Kubernetes clusters is increasingly becoming the responsibility of IT operations teams as the number of Kubernetes clusters that organizations deploy increases substantially. Most application owners prefer to have their own dedicated Kubernetes clusters, which results in clusters multiplying rapidly across the now-extended enterprise.
Kublr 1.16, to help meet those lifecycle management challenges, has also been integrated with Kublr’s previously announced role-based access control (RBAC) management software for Kubernetes.
Like many providers of tools for open source platforms, Kublr also makes available an enterprise edition of its platform that has additional capabilities. Each IT team will need to decide for themselves what level of support they require as they strive to make Kubernetes more accessible to the average IT administrator.
There are, of course, no shortage of tools for managing Kubernetes clusters, so deciding which tools make the most sense to configure and manage Kubernetes clusters can be a significant challenge. The bigger issue, however, may be defining the set of best DevOps practices organizations should embrace to manage Kubernetes clusters. The level of DevOps adoption may vary by organization, but regardless of the approach it’s simply not going to be feasible to manage multiple Kubernetes clusters without relying more on automated processes. The only real question is whether Kubernetes can be managed by the average IT administrator versus organizations having to find, hire and retain a site reliability engineer, who can cost the company tens of thousands of dollars more per year.
Naturally, the management tools required for Kubernetes are only one part of a larger skills equation. At this point, however, it’s not so much a question whether Kubernetes will become part of the IT firmament as much as it is to what degree and how soon. However, the rate of adoption of Kubernetes will be governed by the number of IT managers who have confidence in the tools need to manage it.
