Kublr is making available a technical preview of an update to its namesake Kubernetes management platform that can reach out to external clusters that have already been deployed.
Previously, Kublr could only manage distributions of Kubernetes that it has directly provisioned.
Kublr CTO Oleg Chunikhin says this new capability will make it possible for IT administrators to incorporate external clusters that developers might have spun up on public clouds using, for example, CloudFormation from Amazon Web Services (AWS).
At the same time, Kublr has released a separate 1.18 update that isolates the core Kublr Platform and the agent software the company installs on a cluster. That approach eliminates any dependencies between the Kublr management console and the company’s agent software, says Chunikhin.
Just as significantly, he says Kublr agent software from now on will closely follow the Kubernetes release schedule set by the technical oversight committee that oversees the development of Kubernetes.
Kublr 1.18 also adds support for clusters with restricted PodSecurityPolicy along with version 3 of the Helm package manager. IT teams also now can set up master-only clusters when it’s not feasible to maintain separate masters alone and make use of simplified and improved air-gapped deployment packages.
There have also been usability improvements made to authentication and Grafana dashboards included with the console.
Finally, Kublr is adding an in-place update capability that makes it possible to update the management platform itself via a single click. Previously, upgrades to the core Kubler management platform involved a lot of manual processes.
The 1.18 version of Kublr follows a previous update that added support for rolling upgrades of Kubernetes clusters.
Kublr can be accessed via either a graphical user interface (GUI) or an application programming interface for DevOps teams that want to programmatically manage Kubernetes clusters. The GUI is designed to appeal to IT administrators, who are increasingly taking responsibility for Kubernetes lifecycle management.
The number of Kubernetes clusters being deployed in the enterprise continues to grow. Most application owners prefer to have their own dedicated Kubernetes clusters, which results in clusters multiplying rapidly across an extended enterprise that spans local data centers and the network edge to the public cloud.
The challenge many IT organizations face is the IT operations team often has limited programming skills. As such, graphical tools through which fleets of Kubernetes clusters can be managed are gaining traction. Chunikhin says most organizations will employ a mix of best ITIL and DevOps processes to manage fleets of Kubernetes clusters that will be distributed across a hybrid cloud computing environment.
Going forward, Kublr will add support for platforms such as a service mesh that is a natural extension of a Kubernetes cluster, he says.
It may be a little while before the average IT administrator is managing fleets of Kubernetes clusters. The issue now is not so much whether that will happen as much as it will be how much and how soon. In the meantime, IT organizations should prepare to find a way to manage Kubernetes clusters now before they wake up one day to discover they have already sprawled beyond their control.