I’m excited to announce the release of Rancher 2.2 Preview 2, which contains a number of powerful features for day two operations on Kubernetes clusters.
Please visit our release page or the release notes to learn more about all of the features we shipped today.
In this article I introduce one of the features: multi-cluster applications. Read on to learn how this will dramatically reduce your workload and increase the reliability of multi-cluster operations.
If you’ve been using Kubernetes and have two or more clusters, you are familiar with at least one of the following use cases:
In the high reliability use case operators often mitigate the risks associated with running in a single AZ by pulling nodes from a multiple AZs into a single cluster. The problem with this approach is that even though it resists the failure of an AZ, it will not withstand a failure of the cluster itself. The likelihood of a cluster failure is higher than that of an AZ failure, and if the cluster fails, it might affect the applications running within it.
An alternate approach is to run a separate cluster in each AZ and run a copy of the application on each cluster. This process treats each Kubernetes cluster as its own availability zone, but manually maintaining applications on each cluster is both time consuming and prone to error.
The edge computing use case suffers from the same issue as the multi-AZ cluster: maintenance of the application is either manual, time-consuming, and prone to error, or else the operations team has created sophisticated scripts to handle deployments and upgrades. This additional process overhead moves the point of failure to a different location in the workflow. These scripts require support and maintenance, and they introduce a dependency on the person or people with the knowledge to not only codify the process, but also to understand and manually execute the process if the scripts fail.
Beginning with Rancher 2.2 Preview 2, available from the 2.2.0-alpha6 release tag and up, Rancher will simultaneously deploy and upgrade copies of the same application on any number of Kubernetes clusters.
This feature extends our powerful Application Catalog, built on top of the rock-solid Helm package manager for Kubernetes. Before today the Application Catalog features only applied to individual clusters. We’ve added an additional section at the Global level where those with the correct privileges can deploy apps to any cluster managed by Rancher.
For a full demonstration of this feature and other features released with Rancher 2.2 Preview 2, join us for the upcoming online meetup, where we’ll give a live demo of the features and answer any questions you have.
Read on for a quick introduction to how multi-cluster applications work in Rancher.
If you navigate to the Workloads tab of the target clusters, you’ll see one of them change its status to Updating. This cluster will update, then Rancher will pause for 20 seconds (or for the interval you chose) before continuing to the next cluster and updating its copy of the application.
Multi-cluster applications will reduce the workload of operations teams and make it possible to deploy and upgrade applications quickly and reliably across all clusters.
To test these features in your lab or development environment, install the latest alpha release. If you have any feedback, please open an issue on Github, or join us in the forums or on Slack.