How to Build a Multi-Cloud Kubernetes Cluster Instantly Using KubeKey and Budget VPS

Introduction to Multi-Cloud Kubernetes on Budget Infrastructure

In the contemporary enterprise landscape, high availability and vendor independence are paramount. However, deploying a distributed Kubernetes (K8s) cluster across multiple cloud providers often introduces significant architectural complexity and cost overhead. Traditional bootstrapping tools can require extensive manual provisioning, making multi-provider synchronization a tedious endeavor.

This technical guide demonstrates how to break those barriers by utilizing KubeKey—an advanced, open-source installation tool developed under the KubeSphere ecosystem. We will walk through the exact, step-by-step process of configuring and deploying a production-ready, multi-node Kubernetes cluster across three distinct, budget-friendly Virtual Private Server (VPS) providers. By leveraging KubeKey’s declarative configuration, you can achieve single-command cluster initialization across heterogeneous networks, drastically reducing deployment velocity while maintaining strict budget discipline.

The Multi-Cloud Architecture Design

To ensure true fault tolerance and mitigate single-point-of-failure risks at the provider level, our cluster topology spans three separate infrastructure vendors. We will designate one primary control plane node and two worker nodes distributed as follows:

• Node 1 (Master / Control Plane): Provisioned on Provider A (e.g., DigitalOcean or Linode). Acts as the cluster API endpoint and manages the etcd state.
• Node 2 (Worker Node): Provisioned on Provider B (e.g., Vultr or Hetzner). Executes containerized application workloads.
• Node 3 (Worker Node): Provisioned on Provider C (e.g., Contabo or OVHcloud). Provides additional compute capacity and geographic redundancy.

Architectural Note: Because these nodes reside on completely separate physical networks and data centers, latent network performance and secure cross-node communication are critical vectors. KubeKey natively handles these discrepancies through explicit network interface mappings.

Step 1: Network and Security Prerequisites

Before executing any KubeKey commands, the underlying operating systems and networking layers must be uniformly prepared. Each VPS must be running a clean installation of a supported Linux distribution, such as Ubuntu 22.04 LTS or Debian 12.

1. Firewall and Port Configuration

Since the nodes communicate over the public internet (or via a secure overlay mesh), you must configure your provider firewalls or iptables to permit traffic across the following vital ports:

• TCP Port 6443: Kubernetes API Server (Required for Master node access).
• TCP Ports 2379-2380: Etcd server client API and peer communication.
• UDP Port 8472: VXLAN overlay networking (essential for the Flannel/Calico Container Network Interface).
• TCP Port 10250: Kubelet API (Required for control plane-to-worker health checks).

2. SSH Key Distribution

KubeKey operates as an agentless installer over standard SSH. The machine running the installation (which can be your local workstation or the Master node itself) must have passwordless SSH access to all three target VPS nodes. Generate a keypair and copy the public key to each node:

ssh-copy-id root@master_public_ip
ssh-copy-id root@worker1_public_ip
ssh-copy-id root@worker2_public_ip

Step 2: Installing KubeKey on the Bootstrapper Machine

KubeKey streamlines binary management by compiling required dependencies into a single executable called kk. Log into your designated execution node and run the zone-optimized download script to fetch the latest stable release:

curl -sfL [https://get-kk.kubesphere.io](https://get-kk.kubesphere.io) | VERSION=v3.1.0 sh -

Verify the binary is functional and grant it executable permissions:

chmod +x kk
./kk version

Step 3: Generating and Optimizing the Declarative Configuration File

The core power of KubeKey lies in its config-sample.yaml manifest file. We will generate a base cluster configuration template by running:

./kk create config --with-kubernetes v1.28.2 -f cluster-config.yaml

Open the generated cluster-config.yaml file. We must customize the hosts, roleGroups, and network parameters to accurately reflect our heterogeneous VPS environment. Pay close attention to mapping both public and private IP addresses accurately:

apiVersion: kubekey.kubesphere.io/v1alpha2
kind: Cluster
metadata:
  name: multi-cloud-k8s
spec:
  hosts:
  - name: master-node
    address: 203.0.113.10  # Public IP of Provider A
    internalAddress: 10.0.1.5 # Internal/Private IP if applicable
    user: root
    privateKeyPath: "~/.ssh/id_rsa"
  - name: worker-node-1
    address: 198.51.100.22 # Public IP of Provider B
    internalAddress: 192.168.1.12
    user: root
    privateKeyPath: "~/.ssh/id_rsa"
  - name: worker-node-2
    address: 203.0.113.85 # Public IP of Provider C
    internalAddress: 172.16.0.4
    user: root
    privateKeyPath: "~/.ssh/id_rsa"
  roleGroups:
    etcd:
    - master-node
    control-plane:
    - master-node
    worker:
    - worker-node-1
    - worker-node-2
  plugins:
  - name: calico
    type: network
    properties:
      vethMTU: 1440  # Optimized for cross-provider public routing overhead

Critical Configuration Tip: When running nodes across distinct clouds, lower the maximum transmission unit (MTU) size for your network plugin (e.g., Calico or Flannel) to 1440 or 1400. This compensates for the generic encapsulation overhead over public WAN lines and prevents packet fragmentation.

Step 4: Executing the High-Velocity Cluster Initialization

With the environment prerequisites fulfilled and the cluster-config.yaml explicitly declared, you can trigger the automated installation sequence. Execute KubeKey with the deployment flag:

./kk create cluster -f cluster-config.yaml -y

During this automated sequence, KubeKey performs several internal operations sequentially without requiring user intervention:

1. Performs environment pre-checks on all host systems to ensure memory, storage, and kernel modules (such as conntrack and socat) are ready.
2. Downloads and configures the optimized container runtime interface (typically containerd).
3. Initializes the secure etcd datastore cluster on the control plane.
4. Bootstraps the master services and issues secure TLS certificates for the Kubernetes API server.
5. Joins the distributed worker nodes from the alternative VPS providers securely via token exchange.
6. Deploys the CNI network overlay, enabling cross-node pod communication.

Step 5: Verifying Cluster Health and Cross-Cloud Connectivity

Once KubeKey outputs the successful deployment summary, initialize your administrative environment parameters to access the freshly provisioned cluster:

mkdir -p $HOME/.kube
sudo cp /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

Execute validation commands using kubectl to ensure all nodes across the various cloud networks have successfully joined and transition to the Ready state:

kubectl get nodes -o wide

To rigorously test the network fabric across your budget providers, deploy a globally distributed Nginx test application:

kubectl create deployment multi-cloud-test --image=nginx --replicas=3
kubectl get pods -o wide

Verify that individual pods are allocated across the distinct node groups and can resolve internal cluster DNS routing continuously without losing packets.

Conclusion: Enterprise Agility at Scale

By leveraging KubeKey, engineering teams can bypass the complexities of single-cloud lock-in and high platform premiums. You have effectively designed, configured, and initialized a robust, production-grade Kubernetes cluster spanning three distinct VPS providers within minutes. This configuration provides a highly optimized, cost-efficient playground or production canvas for testing decentralized applications, ensuring that failure at a single hosting vendor will not compromise your global operational capability.