Beyond Kubernetes: Implementing Cilium Service Mesh Across Independent Linux VPS Environments

Introduction: The Evolution of Service Mesh Beyond Kubernetes

For years, the concept of a Service Mesh has been deeply intertwined with Kubernetes. Technologies like Istio and Linkerd revolutionized cloud-native networking by introducing sidecar proxies to manage traffic, enforce security policies, and provide deep observability. However, this architectural paradigm often left traditional, VM-based infrastructures in the dark. Many enterprises still operate substantial workloads on independent Linux Virtual Private Servers (VPS) due to legacy constraints, cost efficiencies, or compliance requirements.

Enter Cilium. Traditionally known as the gold standard for Kubernetes networking and security, Cilium has evolved. Leveraging the power of eBPF (Extended Berkeley Packet Filter), Cilium now extends its Service Mesh and high-performance networking capabilities directly to independent Linux environments. This blog post explores how to architecture, deploy, and secure a multi-VPS Linux environment using Cilium Service Mesh without the overhead of a Kubernetes control plane.

Why Cilium? The Power of eBPF-Powered Networking

Traditional service meshes rely heavily on the sidecar pattern, injecting a proxy (such as Envoy) into every application pod. While effective, this introduces noticeable latency and high memory overhead because traffic must traverse the Linux networking stack multiple times to pass through the proxy.

Cilium revolutionizes this approach by shifting the data path into the Linux kernel using eBPF. Instead of intercepting traffic at the user-space level via a sidecar, Cilium runs eBPF programs directly at the kernel level. This provides several distinct advantages for multi-VPS environments:

Near-Zero Latency: Packets are routed efficiently within the kernel, bypassing heavy iptables rules and unnecessary context switching.
Sidecarless Architecture: Service mesh features like Layer 7 traffic management, mutual TLS (mTLS), and observability are handled globally per host, significantly reducing resource consumption.
Deep Observability: Through Hubble, Cilium provides granular visibility into network flows, protocol metrics, and security violations directly from the kernel.

By bringing Cilium to standalone Linux VPS instances, you can unify networking policies across mixed infrastructures and achieve container-like security abstraction on bare metal or standard virtual machines.

Architectural Overview: Multi-VPS Mesh Topology

To implement Cilium in a standalone multi-VPS environment, we must establish a reliable overlay or routing network between independent nodes. Unlike a Kubernetes cluster where a central API server coordinates state, independent Linux hosts require an external key-value store or a direct routing mechanism to synchronize endpoints and security identities.

Key Architectural Components:

Independent Linux Hosts (VPS): Standard Linux distributions (such as Ubuntu 22.04 LTS or Debian 12) running a modern kernel (5.15 or higher recommended for full eBPF feature support).
Consul or Etcd Cluster: A highly available key-value store used by Cilium to synchronize endpoint routing state, security identities, and policy configurations across the independent nodes.
Cilium Agent (cilium-agent): Running as a systemd service on each Linux host, responsible for compiling eBPF programs and managing the local kernel datapath.
WireGuard or VXLAN Tunneling: Used to establish secure, encrypted data paths for cross-VPS communication across the public internet or private provider networks.

Note: A modern Linux kernel is critical. eBPF capabilities are highly dependent on kernel features, and running a kernel version below 5.10 may severely limit your ability to use advanced Layer 7 traffic management.

Step-by-Step Implementation Guide

Let us walk through the practical deployment of Cilium across two independent Linux VPS nodes: node-01 and node-02.

Step 1: System Prerequisites and Kernel Verification

Before installing Cilium, ensure your system meets the necessary kernel configuration requirements. Run the following command on all participating VPS instances:

uname -r
sudo modprobe bpfilter

Verify that the BPF filesystem is mounted. Most modern distributions mount this automatically at /sys/fs/bpf. If it is not mounted, execute:

sudo mount -t bpf bpf /sys/fs/bpf

Step 2: Deploying the Distributed Key-Value Store

Cilium requires a shared state mechanism to coordinate identities across independent hosts. For this guide, we will use a lightweight etcd cluster. Install etcd on a dedicated node or bootstrap it across your existing VPS instances, ensuring that ports 2379 (client communication) and 2380 (peer communication) are tightly secured via firewalls to only allow traffic between your node IPs.

Step 3: Installing the Cilium Agent on Standalone Linux

Since we are operating outside of Kubernetes, we install Cilium directly onto the host operating system. Download the compiled Cilium binaries and set up the systemd service configuration:

curl -L --remote-name-all [https://github.com/cilium/cilium/releases/download/v1.14.0/cilium-linux-amd64.tar.gz](https://github.com/cilium/cilium/releases/download/v1.14.0/cilium-linux-amd64.tar.gz)
sudo tar -C /usr/local/bin -xzvf cilium-linux-amd64.tar.gz

Next, create a configuration directory at /etc/cilium/ and define the node configuration file (/etc/cilium/ciliumd.yaml):

kvstore: etcd
kvstore-opt:
  etcd.config: /etc/cilium/etcd-config.yaml
datapath-mode: vxlan
tunnel: vxlan
identity-allocation-mode: kvstore
enable-l7-proxy: true
enable-hubble: true
hubble-listen-address: ":4244"

Create a systemd unit file at /etc/systemd/system/cilium.service to ensure the agent runs continuously and restarts automatically on failure.

Step 4: Configuring Cross-Node Networking and Tunneling

To enable communication between node-01 and node-02, define the explicit node allocations within the key-value store or via local configurations. When using VXLAN, Cilium encapsulates cross-node traffic dynamically. Ensure your cloud provider's security groups or your local UFW/iptables configurations allow UDP port 8472 (for VXLAN) or UDP port 51820 (if utilizing WireGuard encryption).

Enforcing Security Policies and L7 Traffic Management

One of the main advantages of a Service Mesh is the ability to enforce fine-grained security policies based on application identity rather than fragile IP addresses. In a standalone environment, Cilium allows you to define Cilium Network Policies (CNPs) via JSON or YAML configuration files parsed directly by the Cilium CLI tool.

Example: Layer 7 HTTP Restrictive Policy

Consider a scenario where an application service on node-01 needs to communicate with a database API on node-02. We want to restrict access so that it can only perform GET operations on the /api/v1/public endpoint.

labels:
  - org: enterprise
  - app: api-gateway
ingress:
  - fromEndpoints:
      - matchLabels:
          app: web-frontend
    toPorts:
      - ports:
          - port: "8080"
            protocol: TCP
        rules:
          http:
            - method: "GET"
              path: "/api/v1/public"

Applying this policy instructs the local host's eBPF datapath to intercept traffic destined for port 8080, direct it through Cilium's integrated Envoy process to validate the HTTP path and method, and instantly drop unauthorized requests (such as POST or alternative administrative paths) without hitting the application layer.

Observability: Gaining Deep Insights via Hubble

Operating a distributed architecture across multi-VPS environments introduces significant observability challenges. Cilium solves this via Hubble, its built-in observability platform. Because Hubble leverages eBPF, it captures deep network insights without modifying your application code or adding sidecars.

By enabling Hubble in your configuration, you can utilize the Hubble CLI or connect the Hubble UI to visualize traffic flows in real-time. For instance, executing the following command on your VPS gives an instantaneous view of network transactions:

hubble observe --identity app=web-frontend -f

This output provides exact metrics regarding packet drops, HTTP response codes, and TCP handshake latencies, enabling system administrators to pinpoint network degradation or security policy misconfigurations instantly.

Conclusion and Best Practices

Implementing Cilium Service Mesh on standalone Linux VPS environments bridges the gap between traditional VM infrastructure and modern cloud-native capabilities. By breaking free from the dependency on Kubernetes, organizations can achieve high-performance networking, absolute kernel-level security isolation, and transparent observability at a fraction of the operational complexity.

When deploying this architecture in production, ensure you adhere to these essential best practices: always enforce strong mutual TLS authentication for your backend etcd/Consul cluster, keep your Linux kernel updated to benefit from continuous eBPF optimizations, and gradually roll out Layer 7 network policies in audit mode before switching to strict enforcement to avoid accidental service disruptions.