DPTCloud
Back to articles
Technology Insight

Building a Multi-Region K3s Cluster Without VPN: Leveraging Cilium eBPF and ClusterMesh on Budget VPS

June 4, 2026

Introduction: The Multi-Region Edge Challenge

In modern cloud architecture, achieving high availability and low latency often means distributing workloads across multiple geographic regions. For enterprises and startups alike, relying on a single cloud provider or region introduces a single point of failure. However, traditional multi-region Kubernetes deployments typically require expensive managed services (like EKS or GKE) or complex, resource-heavy Virtual Private Networks (VPNs) to interconnect nodes across datacenters.

For organizations operating on budget Virtual Private Servers (VPS), these traditional approaches are often non-viable due to high costs and CPU/memory overhead. This is where K3s (a lightweight Kubernetes distribution) combined with Cilium eBPF and ClusterMesh becomes a game-changer. This architecture allows you to build a secure, high-performance, multi-region cluster topology directly over the public internet, completely eliminating the need for a traditional VPN tunnel.

The Architectural Components

To understand how this architecture functions without a VPN, we must look at the unique capabilities of the underlying open-source technologies used:

  • K3s: Developed by Rancher, K3s is a highly optimized, lightweight Kubernetes distribution. It reduces the memory footprint required for the control plane, making it ideal for budget VPS instances with limited resources (e.g., 1GB–2GB RAM).
  • Cilium: Instead of traditional iptables-based networking, Cilium uses eBPF (Extended Berkeley Packet Filter) inside the Linux kernel. This allows for dynamic insertion of bytecode into the kernel integration points, providing ultra-high-performance networking, security, and observability.
  • ClusterMesh: A core feature of Cilium that extends pod networking across multiple distinct Kubernetes clusters. It facilitates cross-cluster service discovery, routing, and network policy enforcement without masquerading or complex NAT configurations.

Why Skip the VPN? The eBPF Advantage

Traditional multi-region setups route traffic through VPN tunnels (like WireGuard or IPSec). While secure, VPNs introduce several bottlenecks on low-cost VPS nodes:

  1. CPU Overhead: Encrypting and decrypting every single packet at the user-space/kernel-space boundary consumes significant CPU cycles.
  2. MTU Issues and Fragmentation: VPN encapsulation alters the Maximum Transmission Unit (MTU), often leading to packet fragmentation and mysterious network degradation.
  3. Single Point of Failure: VPN gateways themselves become bottlenecks and complex to manage in a mesh topology.

Cilium's ClusterMesh avoids these pitfalls by routing traffic directly between nodes over the public internet using secure native encapsulation or direct routing combined with WireGuard integration embedded directly into the eBPF datapath. This ensures that encryption happens transparently inside the kernel, maximizing throughput and minimizing latency.

Prerequisites and Network Planning

Before initiating the deployment, careful network planning is crucial to prevent IP address overlapping across your regions. Each VPS location must be treated as an independent K3s cluster that will be meshed together.

Critical Rule: Every cluster in the mesh must have a unique PodCIDR and ServiceCIDR block. If Cluster A uses 10.244.0.0/16, Cluster B must use 10.245.0.0/16.

System Requirements per VPS:

  • Ubuntu 22.04 LTS or newer (with a modern Linux kernel ≥ 5.15 for full eBPF support).
  • At least 1 Public IPv4 address per node.
  • Open ports for Cilium ClusterMesh control plane (usually 2379 or 42379) and data plane (UDP 8472 for VXLAN or UDP 51820 for WireGuard).

Step-by-Step Deployment Strategy

Step 1: Preparing the Base OS

First, ensure the Linux kernel is ready for eBPF by mounting the BPF filesystem and disabling standard firewalls that might conflict with Cilium, such as ufw.

sudo mount bpffs /sys/fs/bpf -t bpf
sudo ufw disable

Step 2: Installing K3s without the Default CNI

Because we are utilizing Cilium, we must instruct K3s not to install its default network plugin (Flannel). On the primary node of Region 1 (Cluster Alpha), run:

curl -sfL [https://get.k3s.io](https://get.k3s.io) | INSTALL_K3S_EXEC="--flannel-backend=none --disable-network-policy --cluster-cidr=10.244.0.0/16 --service-cidr=10.96.0.0/16" sh -

Repeat a similar process for Region 2 (Cluster Beta), ensuring you change the CIDR blocks:

curl -sfL [https://get.k3s.io](https://get.k3s.io) | INSTALL_K3S_EXEC="--flannel-backend=none --disable-network-policy --cluster-cidr=10.245.0.0/16 --service-cidr=10.97.0.0/16" sh -

Step 3: Deploying Cilium and Enabling ClusterMesh

With the Cilium CLI installed on your local management machine, point your context to Cluster Alpha and install Cilium with a specific cluster name and ID:

cilium install --cluster-name alpha --cluster-id 1

Switch context to Cluster Beta and execute:

cilium install --cluster-name beta --cluster-id 2

Once both installations are validated, enable the ClusterMesh feature. This spins up an internal etcd-backed control plane for cross-cluster communication:

cilium clustermesh enable --context alpha
cilium clustermesh enable --context beta

Step 4: Connecting the Clusters Over the Public Internet

To connect the clusters without a corporate VPN, expose the ClusterMesh service using NodePort or a LoadBalancer IP accessible over the public internet (secured via TLS certificates automatically managed by Cilium). Connect them using the following command:

cilium clustermesh connect --context alpha --destination-context beta

Verify the status of the link to ensure bidirectional connectivity is established:

cilium clustermesh status --context alpha

Cross-Region Service Discovery and Load Balancing

Once ClusterMesh is active, pods in Cluster Alpha can seamlessly communicate with pods in Cluster Beta using their native Pod IPs. To leverage cross-region load balancing, define a global service by adding a specific annotation to your Kubernetes Service definition:

apiVersion: v1
kind: Service
metadata:
  name: my-global-service
  annotations:
    io.cilium/global-service: "true"
spec:
  ports:
  - port: 80
  selector:
    app: web-backend

With this annotation, if the local instances of web-backend fail or become overloaded in Region 1, Cilium will automatically reroute traffic through the eBPF data path over the internet to the healthy instances running in Region 2.

Security Considerations for Public Interconnects

Operating a cluster mesh over low-cost VPS instances across the public internet requires strict adherence to security best practices:

  • Enable Cilium WireGuard Encryption: Ensure that all cross-node data plane traffic is encrypted in transit by enabling Cilium's built-in WireGuard transparent encryption flag during installation: --encryption-type wireguard.
  • Firewall Hardening: Use provider-level firewalls (security groups) to restrict traffic on ClusterMesh ports solely to the specific public IPs of your cluster nodes.
  • TLS Certificates: Cilium strictly uses mutual TLS (mTLS) to secure control plane state propagation between clusters, preventing unauthorized nodes from tampering with the network configuration.

Conclusion: High Availability on a Budget

By pairing the minimal footprint of K3s with the kernel-level efficiency of Cilium eBPF and ClusterMesh, you can eliminate the complexity and financial burden of enterprise WAN architectures and managed cloud platforms. This architecture empowers developers and small businesses to run resilient, multi-region, high-performance applications across affordable VPS infrastructure with optimal resource efficiency.