“I think in the future, organizations won’t just be building one gigantic Kubernetes cluster,” Liang wrote. “They create a cluster for a small number of apps or even for a team. Sometimes they create a cluster for a single app. If they run an app across many clusters, there could even be more clusters than apps. Kubernetes is very flexible this way.”
The company points to two scenarios with the need for applications to span multiple clusters:
- Applications requiring higher fault tolerance when deployed across multiple availability zones.
- Edge computing, which might involve a single application running on hundreds of clusters.
When you deploy Kubernetes, you want to use Kubernetes to make applications reliable, Liang pointed out. While some public clouds allow spreading an application across multiple availability zones, that’s not ideal.
“Whether you run your own Kubernetes or rely on one of the cloud providers, having this pretty complicated layer of software technology sitting between these availability zones and your application effectively become a single point of failure in itself,” he pointed out. “What if I upgrade Kubernetes? What if there’s a bug in the software? For whatever reason, the master nodes crash down and that impacts the application. There’s always been this level of discomfort with deploying this sophisticated layer of orchestration in Kubernetes.
“So people started deploying separate clusters in different availability zones. So if the software fails or the zone fails, there’s no way it’s going to impact the others.
But then there are multiple clusters to manage. But you don’t want to manage those two clusters separately. Manually maintaining applications on each cluster is both time-consuming and prone to error, Rancher’s Ankur Agarwal points out in a blog post.
With this multicluster app feature, you can specify once: This app is going to go to these clusters. It might be configured a little differently in these clusters, but then in one shot they are deployed and managed by Rancher.
In Rancher 2.2, due for GA release at the end of March, you create a Helm chart, then you can deploy it across a large number of clusters. Multicluster applications use Kubernetes controllers running in the Rancher management plane to fetch Helm charts and deploy the application to each target cluster. Then the upgrades, rollbacks and maintenance can all be done at once.
Automated network operations management vendor B-Yond INFINITY uses the multicluster capability in telco environments and for high availability.
“This is beneficial for lifecycle management and in the edge deployments that we see emerging in 5G edge cloud. With Rancher 2.2, we can now fully automate the process and integrate with our lifecycle management process, reducing time and risk while remaining compliant with telco-grade requirements,” said Rikard Kjellberg, its chief product officer.
Rancher Labs’ focus and upcoming features are centered on making Kubernetes easier to use for people who are not well-versed in it.
“They should just be concerned about deploying their apps,” Liang said. “We want to know what kind of interfaces would people like to use, but also not make it so abstracted that people can’t do anything useful with it.”
In November, the company announced it had extended availability for its Kubernetes platform to China’s three largest cloud providers. It also has teamed up with Arm to bring Kubernetes management to clusters running on edge and low-power data center nodes.
In a December episode of The New Stack Makers, Shannon Williams, co-founder and vice president of sales, talked about how the company discovered the recent Kubernetes vulnerability (CVE-2018-1002105).