Published on 00/00/0000
Last updated on 00/00/0000
Published on 00/00/0000
Last updated on 00/00/0000
Share
PRODUCT
7 min read
Published on 02/26/2020
Last updated on 06/18/2024
Four ways to build hybrid clouds with Kubernetes
Share
There has been a lot of talk about multi- and hybrid-clouds over the past years. Some cloud vendors see these trends as a threat, others look at them as an opportunity. We think that beneath the buzzwords lie some very important use-cases driven by the needs of enterprises and SaaS providers. However, delivering and operating multi- and hybrid-clouds has been too complex for most organizations so far. One major area of focus for Banzai Cloud has been hybrid clouds, to create and automate a seamless and consistent operational experience for a concept that has a lot of underlying complexities.
#multicloud #hybridcloud #banzaicloud
Hybrid clouds — multiple options, one platform
The Banzai Cloud Pipeline platform allows enterprises to run their workloads in single-, multi-, or hybrid-cloud environments. Our goal was to allow any application that can be deployed to Kubernetes to run on different hybrid cloud environments without modification. As we have learned, a single approach does not cover all use-cases, so the Banzai Cloud Pipeline platform supports the following four different ways to build and use hybrid clouds.
Cluster groups and deployments
Production ready Kubernetes clusters should provide enterprise-grade security, centralized logging, federated monitoring, security scans, disaster recovery, workload management, and other similar services. Creating production ready Kubernetes clusters in multiple clouds and on-premises using a single control plane is an expectation that all Kubernetes container management platforms should offer in 2020, but only a few actually do. The Banzai Cloud Pipeline platform allows you to:- create Kubernetes clusters across 5 cloud providers and on-premises, and
- group them in a single virtual cluster, so you can
- roll deployments out simultaneously, and manage their lifecycle together, regardless of where those clusters reside.
Federation based hybrid clouds
Kubernetes Federation (kubefed v2) brings the ability to manage deployments and services across multiple Kubernetes clusters located in different clouds, regions, or datacenters. It allows you to coordinate the configurations of multiple Kubernetes clusters on the basis of a single set of APIs from within a host cluster. Pipeline has added support for Kubernetes federation quite a while ago, and has automated and simplified the installation, management, and application deployment to federated clusters. Using a single control plane you can add, remove, and update federated cluster groups, while the Pipeline platform automatically takes care of all the magic behind these tasks. If you'd like to learn more about federated deployment and scheduling, read the following posts:
Connecting multiple clusters with a service mesh
In the microservices era, applications are deployed across multiple clusters, often managed by different teams with different release cadence and velocity. Making things work together properly can quickly become a burden for the teams. Service meshes like Istio were meant to fix these problems, but they are highly complex and difficult to set up and maintain, for which many devops teams are not prepared for. To make the appealing features of Istio available to our customers, we created Backyards (now Cisco Service Mesh Manager). As more and more of our Backyards (now Cisco Service Mesh Manager) customers are moving towards hybrid environments, we have added support to create multi-cluster and multi-cloud meshes. If you'd like to kickstart your Istio experience across single, multiple, or hybrid clouds in literarily less then 5 minutes, read our [Create multi-cluster Istio service meshes the easy way]({{< relref "backyards-multicluster-istio) blogpost.
Cloud Fusion - the next generation Kubernetes cloud controller {#cloud-fusion}
Kubernetes has not been designed to run in heterogenous and hybrid environments, and when a mixture of (cloud) controllers are installed (due to a hybrid cloud environment), they step on each others’ toes. The end result is that various things break and nodes are removed from the cluster (stay tuned for a blog that goes into more detail on these issues). We’ve built our own, Hybrid Cloud Controller, called Cloud Fusion, which installs and manages cloud controllers, Container Storage Interface (CSI) drivers, and Load Balancers. This allows for seamless scaling between nodes, whether on-premise or in different clouds, and is accomplished in such a way that you interact with a single Kubernetes cluster that straddles both data centers and clouds. You don’t need to manage multiple API servers and etcd clusters, as new nodes join the existing Kubernetes cluster. Read more about Cloud Fusion and the Banzai Cloud Pipeline platform.Conclusion
We hope that this post was useful and covered the benefits of each solution and gave technical insights of the under the hood components of Banzai Cloud Pipeline, our open source container management platform for hybrid clouds.| Cluster groups | Federation | Backyards | Cloud Fusion | |
|---|---|---|---|---|
| Resource syncing | To CRUD resources across clusters | To keep resources in multiple clusters in sync | Does not keep resources cross cluster in sync | No need, there is one single K8s cluster |
| Discovery | Not intended to provide discovery. | Can auto-configure DNS servers and load balancers with backends from all clusters | Includes a centralized service registry, with locality load balancing support | No need, there is one single K8s cluster |
| High Availability | Deploys the same workload across clusters, thus minimizes the impact of failure. | Spreads load across clusters and maintains predefined replicas, cross cluster. | Services can be spread across clusters, it minimizes the impact of service failures. | Although it's a single cluster, replicas can be spread across clouds. |
| Latency | Clusters are unrelated, there no communication between them. | Requests are served from the cluster that is closest to them. | If clusters are spread in multiple regions, requests are served from the cluster that is closest to them, using locality load balancing. | Not an issue, there is one single K8s cluster |
| Fault isolation | Clusters are unrelated, there is no communication between them. | It might be better to have multiple small clusters rather than a single large cluster for fault isolation | It is better to have services spread across clusters for fault isolation | There is one single K8s cluster |
| Network bandwidth | Clusters are unrelated, no communication between them. | The federation control plane watches all clusters, can lead to increased network bandwidth and cost. | The Istio control plane watches all clusters, can lead to increased network bandwidth and cost. | There is one single K8s cluster |
| Cross cluster isolation | Clusters are unrelated, no communication between them. | An issue with the federation control plane can impact all clusters. | Core Backyards components and the Istio control plane is HA. | There is one single K8s cluster |
Subscribe to
the Shift!
Get emerging insights on innovative technology straight to your inbox.
