Kublr 1.18 Supports In-Place Platform Upgrades and External Clusters
Kublr’s CTO Oleg Chunikhin explained, “This is yet another step in making enterprise-grade Kubernetes adoption a breeze.”
While Kublr supports automated rolling cluster updates and upgrades with zero downtime, since our last release (1.17) updating the platform itself was still a semi-manual project supported by the Kublr team. Now, all it takes is the click of a button. This allows you to maintain all clusters and the platform with the newest software versions, minimizing vulnerabilities and leveraging their newest features.
This significantly simplifies operational and planning processes. We’ll continue to support the upgrade process from planning to execution if desired, but you can also do it in a self-service manner.
Support for External Clusters (Technical Preview)
In previous versions, Kublr only supported Kublr provisioned clusters. That meant that if your clusters were deployed through different platforms you had to manage them separately. As of today, users can bring existing clusters into Kublr and add an additional centralized management layer on top of it. These could be cloud-hosted clusters such as AKS, EKS, or GKE or clusters managed through other platforms without a centralized console such as Openshift, extending centralized logging and monitoring as well as centralized identity management to non-Kublr clusters.
Decoupling Kublr Platform from Agent Releases
The Kublr Platform and Kublr Agent are the two main components of Kublr. The platform is the centralized management console while the agent runs inside the managed cluster, essentially operating the Kubernetes cluster. Until now, the Kublr team released platform and agent updates together, which sometimes created an unneeded dependency when supporting new Kubernetes versions. Without that dependency, Kublr 1.18 will now allow us to support new Kubernetes alpha releases within a week.
While the Kublr Platform will be upgraded on a three to four month schedule, the Kublr Agent will closely follow the Kubernetes release schedule.
Additionally, Kublr 1.18 now supports platform installations in clusters with restricted PodSecurityPolicy, Helm 3 in Kublr Helm packages and web command line console, master only clusters when it’s not feasible to maintain separate masters, as well as usability improvements for OIDC authentication, Grafana dashboards, simplified and improved air-gapped deployment packages, among many other improvements.
To date, Kublr is the only multi-cloud, multi-cluster independent centralized Kubernetes management platform that supports zero-downtime 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.
Incubated by EastBanc Technologies, a technology agnostic custom- software development firm working with Kubernetes since its inception, Kublr was launched in 2016. Continuously addressing the same challenges while helping customers transition to containers and Kubernetes, we developed a set of best practices and engineering solutions to simplify containers and Kubernetes implementation in our projects. With no ready-to-use solution on the market that met the strict requirements of our customers, we saw ourselves recreating the wheel over and over again. We decided to bundle all that know-how and best practices into a platform built specifically with enterprise needs in mind. Because we always leveraged open-source, cloud-native technologies in our client work, that approach is ingrained in our team’s DNA. Committed to keeping the open-source promise, the Kublr Platform is designed to remain flexible and extensible. While fully preconfigured to speed up adoption, every aspect can be customized—Kubernetes being the only constant.