Architecture of a Sovereign
Kubernetes Platform

Orista is a managed Kubernetes platform that decouples the control plane from the data plane, enabling organizations to use their own infrastructure for worker nodes—regardless of where that infrastructure is located. You provide the hardware; Orista manages everything else: the control plane, node networking, updates, and monitoring.

Traditional managed Kubernetes services (EKS, GKE, AKS) require worker nodes to run within the same cloud provider's network. This creates vendor lock-in, limits infrastructure flexibility, and often requires complex networking setups for hybrid or multi-cloud deployments.

Orista solves this by combining three key technologies:

• Managed Kubernetes Control Plane — Highly available API server, scheduler, controller-manager, and etcd, hosted in Orista's secure European infrastructure.
• NetBird — A WireGuard-based mesh networking solution that creates encrypted point-to-point tunnels between nodes, regardless of NAT, firewalls, or network topology.
• Cilium — An eBPF-based Container Network Interface (CNI) that provides pod networking, network policies, and observability on top of the NetBird underlay.

The result is a Kubernetes cluster where worker nodes can be located anywhere—public clouds, private data centers, edge locations, or even behind residential NAT—while maintaining full Kubernetes compatibility and enterprise-grade security.

Managed Kubernetes has become the default choice for organizations adopting container orchestration. Services like Amazon EKS, Google GKE, and Azure AKS remove the operational burden of managing the Kubernetes control plane. However, they introduce significant constraints:

2.1 Vendor Lock-in

Worker nodes must run within the cloud provider's infrastructure. While some providers offer "hybrid" options (EKS Anywhere, GKE On-Prem), these require significant investment in proprietary tooling and don't support true multi-cloud scenarios.

2.2 Network Complexity

Connecting nodes across different networks requires complex VPN setups, transit gateways, or dedicated interconnects. Each cloud provider has its own networking model, making multi-cloud deployments expensive and difficult to maintain.

2.3 Data Sovereignty Concerns

Organizations with strict data residency requirements struggle with managed Kubernetes. Even if the control plane is in a compliant region, the tight coupling between control and data planes makes it difficult to ensure workloads run only on approved infrastructure.

2.4 Cost Inefficiency

Organizations often have existing infrastructure—bare metal servers, reserved instances from other providers, or on-premise hardware—that sits underutilized because it can't easily join their managed Kubernetes clusters.

Orista's architecture is built on a simple principle: the control plane and data plane should be independent. This separation enables true infrastructure flexibility while maintaining the operational simplicity of managed Kubernetes.

3.1 Managed by Orista: Control Plane + Node Operations

Each Orista cluster gets a dedicated Kubernetes control plane running in Orista's European infrastructure:

• API Server — The entry point for all cluster operations, exposed via a dedicated endpoint.
• etcd — Distributed key-value store for cluster state, running in a highly available configuration.
• Scheduler — Assigns pods to worker nodes based on resource requirements and constraints.
• Controller Manager — Runs core controllers (ReplicaSet, Deployment, Service, etc.).
• Cloud Controller Manager — Orista's custom controller for managing node lifecycle and cloud-provider integrations.

Beyond the control plane, Orista also manages node operations:

• Mesh Networking — Automatic setup and maintenance of encrypted connectivity between all nodes.
• Node Updates — OS patches, Kubernetes component updates, and security fixes are applied automatically.
• Monitoring — Health checks, resource metrics, and alerting for all nodes in the cluster.
• CNI Management — Cilium installation, configuration, and upgrades.

Customers interact with their cluster via standard Kubernetes APIs using a provided kubeconfig. The underlying infrastructure management is handled transparently by Orista.

3.2 Customer-Provided: The Hardware

Worker nodes run on customer-provided infrastructure. You provide the servers—Orista handles everything else. Any Linux server can become a worker node by running the Orista join command:

This command installs and configures:

• NetBird agent — Establishes encrypted connectivity to the mesh network.
• Kubelet — The Kubernetes node agent that communicates with the control plane.
• Cilium agent — Provides pod networking and network policy enforcement.
• Container runtime — containerd for running containers.

3.3 Architecture Diagram

┌─────────────────────────────────────────────────────────────────┐
│                    ORISTA CONTROL PLANE                         │
│                   (Managed European Region)                     │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────────────────┐  │
│  │  API Server │  │  Scheduler  │  │  Controller Manager     │  │
│  └──────┬──────┘  └─────────────┘  └─────────────────────────┘  │
│         │                                                       │
│  ┌──────┴──────┐  ┌─────────────────────────────────────────┐   │
│  │    etcd     │  │  NetBird Coordination Server            │   │
│  │  (HA, 3+)   │  │  (STUN/TURN, Signaling)                 │   │
│  └─────────────┘  └─────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────────────┘
                              │
                    WireGuard Tunnels (E2E Encrypted)
                              │
        ┌─────────────────────┼─────────────────────┐
        │                     │                     │
        ▼                     ▼                     ▼
┌───────────────┐     ┌───────────────┐     ┌───────────────┐
│  Worker Node  │     │  Worker Node  │     │  Worker Node  │
│   (AWS EC2)   │     │  (Hetzner)    │     │  (On-Prem)    │
│               │     │               │     │               │
│ ┌───────────┐ │     │ ┌───────────┐ │     │ ┌───────────┐ │
│ │  NetBird  │ │     │ │  NetBird  │ │     │ │  NetBird  │ │
│ │   Agent   │◄├─────┼─►   Agent   │◄├─────┼─►   Agent   │ │
│ └───────────┘ │     │ └───────────┘ │     │ └───────────┘ │
│ ┌───────────┐ │     │ ┌───────────┐ │     │ ┌───────────┐ │
│ │  Cilium   │ │     │ │  Cilium   │ │     │ │  Cilium   │ │
│ │   Agent   │ │     │ │   Agent   │ │     │ │   Agent   │ │
│ └───────────┘ │     │ └───────────┘ │     │ └───────────┘ │
│ ┌───────────┐ │     │ ┌───────────┐ │     │ ┌───────────┐ │
│ │  Kubelet  │ │     │ │  Kubelet  │ │     │ │  Kubelet  │ │
│ └───────────┘ │     │ └───────────┘ │     │ └───────────┘ │
│    [Pods]     │     │    [Pods]     │     │    [Pods]     │
└───────────────┘     └───────────────┘     └───────────────┘
                              │
                    P2P WireGuard Mesh
                   (Direct pod-to-pod traffic)
                        

Orista's networking stack is the key innovation that enables bring-your-own-nodes. It consists of two layers: the underlay network (NetBird) and the overlay network (Cilium).

4.1 Underlay Network: NetBird

NetBird is an open-source networking solution built on WireGuard that creates a secure mesh network between nodes. It solves the fundamental challenge of connecting machines across different networks.

How NetBird Works

1. Registration — When a node joins, the NetBird agent registers with Orista's coordination server, exchanging public keys and network information.
2. Peer Discovery — The coordination server provides each node with information about other peers in the cluster.
3. Connection Establishment — Nodes establish direct WireGuard tunnels using various NAT traversal techniques:
   • Direct connection (if both nodes have public IPs)
   • UDP hole punching (for most NAT configurations)
   • TURN relay (fallback for symmetric NAT)
4. Mesh Formation — Each node maintains WireGuard tunnels to every other node, forming a full mesh topology.

NetBird Interface

NetBird creates a virtual network interface (typically wt0) on each node. This interface is assigned an IP address from the mesh network range (e.g., 100.64.0.0/10). All inter-node traffic is routed through this interface, encrypted by WireGuard.

4.2 Overlay Network: Cilium

Cilium is an eBPF-based CNI that provides Kubernetes networking, network policies, and observability. In Orista, Cilium runs on top of the NetBird underlay.

Cilium Configuration

Cilium is configured to use the NetBird interface as its underlying network:

• Tunnel Mode: Disabled (target) — Since the mesh already provides encrypted node-to-node connectivity, Cilium should operate in native routing mode, avoiding double encapsulation. This is in development: the mesh only routes node addresses, so the prototype currently falls back to a VXLAN overlay with a reduced MTU.
• Device Selection — Cilium is configured to use the NetBird interface (wt0) for inter-node traffic.
• Pod CIDR — Each node receives a pod CIDR allocation (e.g., /24) from the cluster's pod network range.

Traffic Flow: Pod-to-Pod Communication

When a pod on Node A communicates with a pod on Node B:

1. The packet leaves the source pod via its veth interface.
2. Cilium's eBPF programs route the packet based on the destination pod IP.
3. For cross-node traffic, Cilium forwards the packet to the NetBird interface.
4. NetBird encrypts the packet and sends it through the WireGuard tunnel to Node B.
5. On Node B, NetBird decrypts the packet and passes it to Cilium.
6. Cilium delivers the packet to the destination pod.

Pod A (10.42.1.5)                                    Pod B (10.42.2.8)
     │                                                    ▲
     ▼                                                    │
┌─────────┐                                          ┌─────────┐
│ Cilium  │  ──────────────────────────────────────► │ Cilium  │
│ (eBPF)  │        Routed via NetBird interface      │ (eBPF)  │
└─────────┘                                          └─────────┘
     │                                                    ▲
     ▼                                                    │
┌─────────┐         WireGuard Tunnel               ┌─────────┐
│ NetBird │ ═══════════════════════════════════════│ NetBird │
│  (wt0)  │  100.64.1.15 ◄─── E2E Encrypted ───► 100.64.2.22  │
└─────────┘                                          └─────────┘
     │                                                    ▲
     ▼                                                    │
  [Internet / Any Network Path]  ────────────────────────┘
                        

4.3 Key Networking Benefits

Orista's architecture provides strong security guarantees through multiple layers of protection.

5.1 Control Plane Security

• Dedicated per-customer — Each cluster has its own control plane instances, with no multi-tenant sharing of API servers or etcd.
• TLS everywhere — All control plane communication uses TLS 1.3 with certificate-based authentication.
• etcd encryption — Cluster state is encrypted at rest using AES-256.
• RBAC enforcement — Kubernetes RBAC is enforced for all API requests.

5.2 Data Plane Security

• WireGuard encryption — All node-to-node traffic is encrypted using WireGuard (ChaCha20-Poly1305).
• Mutual authentication — Nodes authenticate to the mesh using cryptographic keys managed by NetBird.
• Network policies — Cilium enforces Kubernetes NetworkPolicies at the eBPF level.
• No Orista access — Orista has no access to customer workloads or inter-node traffic.

5.3 Zero-Knowledge Architecture

Orista is designed so that we cannot access customer data:

• The control plane issues commands to kubelets but never receives workload data.
• Inter-node traffic flows directly between customer nodes, encrypted end-to-end.
• Secrets stored in etcd are encrypted with customer-managed keys (optional).
• Ingress traffic uses SSL passthrough—Orista terminates TCP, not TLS.

Orista provides a streamlined process for adding and removing worker nodes from a cluster.

6.1 Node Join Process

1. Generate join token — User generates a time-limited join token via the Orista dashboard or CLI.
2. Run join command — On the target server, run:
   curl -sL orista.eu/join | sh -s -- --token <token>
3. Hardware detection — The installer detects CPU, memory, storage, and network configuration.
4. NetBird setup — The NetBird agent is installed and connects to the mesh network.
5. Kubernetes components — Kubelet and Cilium are configured and started.
6. Node registration — The node registers with the Kubernetes API server and becomes schedulable.

The entire process completes in under 60 seconds on most systems.

6.2 Node Labels and Taints

Orista automatically applies labels to nodes based on detected characteristics:

These labels enable sophisticated scheduling rules, such as ensuring databases run only on nodes in specific jurisdictions.

6.3 Node Removal

Nodes can be gracefully removed via the Orista CLI or dashboard:

1. Node is cordoned (no new pods scheduled).
2. Existing pods are drained (evicted to other nodes).
3. Node is removed from the Kubernetes cluster.
4. NetBird agent is disconnected from the mesh.
5. Local Orista components are uninstalled.

7.1 Multi-Cloud Deployment

Run a single Kubernetes cluster spanning multiple cloud providers. Use AWS for global edge presence, Hetzner for cost-effective compute in Europe, and GCP for specific managed services—all managed as one cluster.

7.2 Hybrid Cloud

Connect on-premise servers to a managed Kubernetes control plane. Keep sensitive workloads on-premise while leveraging cloud resources for burst capacity, without complex VPN setups.

7.3 Edge Computing

Deploy Kubernetes workloads to edge locations—retail stores, factories, or remote sites—managed centrally through a single control plane. NetBird handles connectivity even for sites behind restrictive firewalls.

7.4 Data Sovereignty

Ensure workloads processing EU citizen data run exclusively on nodes in EU jurisdictions, while using a managed control plane that handles orchestration without accessing the data.

7.5 Cost Optimization

Utilize existing infrastructure investments—bare metal servers, reserved instances from various providers, or underutilized hardware—as part of a managed Kubernetes cluster.

Orista represents a new approach to managed Kubernetes—one that provides the operational simplicity of fully managed services while preserving infrastructure flexibility and data sovereignty.

By combining a managed Kubernetes control plane with NetBird's mesh networking and Cilium's eBPF-based networking, Orista enables organizations to:

• Use any infrastructure as Kubernetes worker nodes
• Let Orista handle networking, updates, and monitoring automatically
• Connect nodes across any network topology without VPN complexity
• Maintain end-to-end encryption for all inter-node traffic
• Keep workloads and data on their own infrastructure
• Meet data sovereignty and compliance requirements

The result is Kubernetes that works the way organizations actually need it to: flexible, secure, and simple.