Why Enterprises Embrace Hybrid Multi‑Cloud and Kubernetes Multi‑Cluster Strategies

Enterprise Drivers for Hybrid Multi‑Cloud

Enterprises choose hybrid multi‑cloud primarily because of security concerns, illustrated by incidents such as the 2021 OVH data‑center fire that took down 3.5 million websites, the 2018 Facebook data leak, the 2020 Marriott breach affecting 5.2 million guests, and other high‑profile leaks that underscore the risk of a single‑point‑of‑failure.

2018 Facebook data leak caused a 7% stock drop and $36 billion market loss.

2020 Marriott exposed 5.2 million guest records.

2020 Weimeng “delete‑database” incident cost ¥116 million.

2020 Thai telecom leaked 8.3 billion user records.

Cloud providers also suffer incidents: Alibaba Cloud code‑hosting misconfiguration exposed over 200 projects, a 2020 Microsoft GitHub breach leaked 63.2 GB of source code, and the OVH fire again caused irreversible data loss.

A HashiCorp survey of 3,205 respondents showed that three‑quarters already use multi‑cloud, and nearly 90% expect to adopt it within two years.

Key Reasons for Adopting Hybrid Multi‑Cloud

Security considerations.

Regulatory requirements.

Leveraging distinct cloud‑provider features.

Avoiding vendor lock‑in and optimizing costs.

Driving future technological innovation.

Specific business and operational needs.

Kubernetes Multi‑Cluster Use Cases

Disaster recovery and active‑active deployment across public‑cloud and IDC clusters.

Geographically proximate access to reduce latency.

Business or department isolation via separate clusters.

Limiting fault impact to a single cluster.

Preventing single‑vendor lock‑in and preserving bargaining power.

Multi‑Cluster Solutions Overview

Solutions fall into two categories: control‑plane resource distribution (e.g., Federation v1/v2, Argo CD, Flux CD) and pod‑network connectivity (e.g., Cilium Mesh, Istio Multi‑Cluster, Linkerd Service Mirroring).

Federation v1

Federation v1 adds a dedicated API server and controller manager to a host cluster, which then propagates resources to member clusters. Drawbacks include extra maintenance overhead, poor version compatibility, lack of RBAC, and bulky annotation‑based resource distribution.

Separate API server increases operational cost.

Fixed GVK limits compatibility across cluster versions.

No built‑in RBAC for cross‑cluster permissions.

Annotation‑driven distribution is cumbersome and inelegant.

Federation v2 (Kubefed)

Kubefed replaces annotations with CRDs and controllers, eliminating the extra API server. A federated resource consists of Template, Override, and Placement sections, supporting multiple API versions and all resource types. Limitations include complex API definitions, reliance on kubefedctl for cluster join/leave, and the need for network reachability between host and member clusters.

CRD‑based design improves version compatibility.

No extra API server; native K8s API remains untouched.

Supports service discovery and scheduling across clusters.

Complexity and lack of SDK make adoption harder.

KubeSphere Implementation of Kubefed

KubeSphere defines a Host cluster (control plane with Kubefed) and Member clusters (managed clusters). It extends the Kubefed Cluster object with region, zone, and provider metadata. Clusters can be added via direct kubeconfig connection or through a proxy (Tower) that creates an agent in the member cluster to tunnel traffic.

Multi‑Tenant and Application Deployment

In KubeSphere, a tenant maps to a Workspace, with authorization implemented via CRDs that are federated to member clusters, ensuring continuity if the host fails. The UI allows selecting target clusters, customizing replica counts, images, and environment variables per cluster.

Case Study: Hongya Technology

Hongya Technology, an IT education provider, adopted a hybrid multi‑cloud setup using KubeSphere (QKE) on QingCloud, Alibaba Cloud ACK, and self‑managed K8s clusters. Requirements included avoiding vendor lock‑in, open‑source solutions, low deployment complexity, unified authentication, and easy operation. They leveraged Tower for proxy connections and contributed an IDaaS plugin to integrate DingTalk authentication as an OAuth provider.