 |
VOOZH | about |
|
VOOZH | about |
We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.
Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.
Follow TNS on your favorite social media networks.
Become a TNS follower on LinkedIn.
Check out the latest featured and trending stories while you wait for your first TNS newsletter.
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.”
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.
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.
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.
“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:
