Designing Scalable Kubernetes Deployments: Single & Multi‑Cluster Strategies

Kubernetes Cluster Overview

In this talk from the Volcano Engine Developer Community meetup, the speaker introduces the architecture and deployment modes of Kubernetes clusters.

Kubernetes Cluster Components

Key components include API Server, Controller Manager, Scheduler, Kubelet, Kube‑Proxy, and Kubectl.

These components interact as follows:

Kubectl creates a Deployment via a YAML file or command.

The request is sent to the API Server, which validates and stores the data in etcd.

etcd triggers the Deployment Controller to create a ReplicaSet.

The ReplicaSet Controller creates the corresponding Pods.

The Scheduler selects suitable nodes for the Pods.

Kubelet on each node receives the Pod creation task, mounts required volumes, and starts the container runtime (Docker or containerd).

Kube‑Proxy configures network routing, available in iptables or IPVS mode (IPVS recommended).

Single Kubernetes Cluster Deployment

For private‑cloud PaaS scenarios without public network access, the deployment includes pre‑installing an HTTP file server for binaries, a private image registry, and a container running Ansible playbooks to orchestrate node setup.

The deployment steps, based on kubeadm, are:

Configure OS jump host (ssh‑proxy).

Initialize the operating system (kernel parameters, dependencies).

Pre‑deployment checks and configuration.

Install the container runtime (containerd, replaceable with Docker).

Download binaries and pre‑pull component images.

Deploy etcd (binary installation).

Install Kubelet and Kubectl on all nodes; initialize the first master with kubeadm init and join additional masters with kubeadm join --control-plane, then join worker nodes.

Install the network plugin (Calico + VXLAN) to bring nodes to Ready state.

Store cluster metadata in a ConfigMap for future maintenance.

Multi‑Kubernetes Cluster Deployment

In private‑cloud environments, multiple clusters address isolation, scalability, and independent business lines. The design stores all cluster configurations in a control cluster while user clusters keep only their own settings.

A single deployment node runs an HTTP server, an image registry, and an Ansible container. It uses env and inventory files to drive Ansible scripts that SSH‑proxy through a master node to reach all target nodes.

The control cluster runs kubeadm and the runtime on each node, deploying cluster components and a Cluster Controller that handles scaling and user‑cluster creation. User clusters reuse the same installation logic, with the Cluster Controller limited to node add/remove operations.

Conclusion and Outlook

The presented approaches reduce operational effort, eliminate single‑cluster size limits, and enable business isolation through multi‑cluster architectures. Future trends point toward broader adoption of multi‑cluster deployments, containerized business components, and customizable cluster configurations.