Kubernetes networking · OpenShift · Netherlands
Networking on GRN.CLOUD is Kubernetes-native and software-defined. It runs on distributed OpenShift clusters spread across regional sites, each built from three independent availability zones. Routing, load balancing, and policy are declarative objects reconciled by the cluster, so workloads keep operating through hardware, network, and site failures rather than waiting for an operator to intervene.
Every regional site is autonomous: it has its own power, cooling, internet uplinks, and network fabric, and it continues to serve traffic when other sites are unreachable. Traffic is drawn toward healthy capacity using BGP and anycast, and the whole platform is operated under Dutch jurisdiction as sovereign infrastructure.
High availability · redundancy · autonomous regional infrastructure · sovereign cloud.
Regional site — three availability zonesSite 1 live
Each zone fails independently. The site keeps serving on the remaining two.
Every other cloud service is reached over the network. Its behaviour under failure sets the ceiling for everything running above it.
Compute and storage are only useful once something can reach them. In a Kubernetes platform the network is what turns a set of machines into a cluster: it assigns addresses to pods, resolves service names, admits external requests, enforces which workloads may talk to each other, and carries the replication traffic that keeps state durable. When the network degrades, the symptoms appear as application failures — timeouts, partial outages, stale data — even when every node is still running.
Traffic in a cluster falls into two planes, and they fail differently:
Both planes depend on the same properties: predictable latency, working service discovery, connectivity across sites, and a security model that does not assume the internal network is trusted. Distance sets a floor on latency that no software removes, which is why regional placement is a networking decision as much as a facilities one.
Modern applications are built on the assumption that components fail. Networking has to make the same assumption: multiple paths, health-aware routing, and automatic convergence, instead of a single path that is expected to stay up.
GRN.CLOUD is building a nationwide distributed infrastructure across the Netherlands: many small, independent sites instead of a few large ones.
Conventional cloud regions concentrate capacity in a small number of very large facilities. That concentration creates correlated failure: a facility-wide power event, a cooling failure, or a fibre cut affects everything inside it at once, and the blast radius grows with the size of the building. It also fixes latency for everyone who is not near one of those few locations.
The GRN.CLOUD architecture inverts that. The target topology is approximately 100 regional sites distributed across the country. Each site operates independently and is built from three availability zones. Each zone is a shipping-container-sized micro datacenter with its own power feed, cooling, internet uplinks, and network equipment. No zone depends on another zone to stay running, and no site depends on another site to keep serving its workloads.
micro datacenter · container form factor
micro datacenter · container form factor
micro datacenter · container form factor
Target topology — approximately 100 regional sites, Netherlands
Each square is one regional site of three zones. The first regional site is operational today; additional regions are being deployed.
A site holds everything it needs to run: control plane, compute, storage, and network. It does not call home to a central region for scheduling, authentication, or routing decisions. If the links to the rest of the country are cut, the site continues to serve the workloads it hosts.
Small independent units bound the blast radius. Losing a zone removes one third of a site’s capacity, not the site. Losing a site removes one site, not a region. Failure domains are explicit and physical rather than a logical label attached to shared equipment.
Recovery targets are declared as scheduling and replication policy rather than as a runbook. Workloads are spread across zones, volumes are replicated, and a second site can be used as the recovery target for workloads whose recovery objectives require geographic separation.
Distance is the one component of latency that cannot be optimised away in software. Many sites spread across the country place compute physically closer to users, branch offices, factories, and devices than a centralised region can.
Capacity distributed over many sites means no single facility is systemically important. Regional incidents — grid events, roadworks cutting fibre, local flooding — affect a bounded part of the platform, and traffic is drawn to the sites that remain healthy.
Small sites connect to local power and local heat demand. Sites run on renewable energy, reuse server heat in nearby greenhouses and buildings, and use peak shaving to reduce pressure on a congested national grid — which is also what makes deploying many sites practical.
Current status. The first regional site is operational and serving production workloads. Additional regions are being deployed. Multi-region placement options are introduced as sites come online — the architecture below describes the design the platform is built to, and the zone-level mechanisms are in use today.
Networking is configured with Kubernetes and OpenShift objects, not with a parallel proprietary console. The API is the interface.
Firewalling, load balancing, VPN termination, multi-cluster connectivity, and virtual machine networks are all expressed as resources in the cluster API and reconciled by controllers. That means network configuration lives in Git alongside the application it belongs to, is applied by the same pipeline, and is portable to any conformant Kubernetes cluster.
Traffic between workloads is controlled by Kubernetes NetworkPolicy objects
enforced by the CNI plugin in the data plane. A namespace with a default-deny policy accepts only
the connections it explicitly allows, selected by pod label, namespace, port, and protocol.
A Kubernetes Service gives a stable address to a changing set of pods and spreads
connections across the endpoints that pass their readiness probes. MetalLB assigns external
addresses to LoadBalancer services on bare metal and advertises them to the network
with BGP, so upstream routers learn the path to a service address directly.
Encrypted tunnels are deployed as container images and run as ordinary workloads in the cluster, managed by the same manifests, secrets, and lifecycle as the applications behind them. Both OpenVPN and WireGuard are available.
Endpoints stay off the public internet: services reachable only over a tunnel are never exposed by a public route.
Clusters in different zones, sites, or premises are connected at the network layer. BGP EVPN provides layer-2 and layer-3 overlays across sites with dynamic route distribution, and Submariner connects Kubernetes clusters directly — pods and services in one cluster reach services in another using the same DNS names.
Virtual machines run on the platform through KubeVirt and OpenShift Virtualization. User-defined networks (UDN) give those virtual machines their own layer-2 or layer-3 networks, separate from the default cluster network, so a migrated VM keeps the addressing and segmentation it had before.
Cluster DNS resolves service names to current endpoints, so applications address services rather than addresses and survive rescheduling. Flow and endpoint metrics are exported to the platform monitoring stack, which is what makes a policy or route change reviewable after it is applied.
Redundancy is applied at every layer, because a redundant component behind a single point of failure is not redundant.
Availability is a property of the whole stack. Each layer below removes a class of single point of failure, and each has an automatic recovery path that does not require a person to be paged first.
Three availability zones per site, each with its own power, cooling, uplinks, and network equipment. Absorbs: a zone-level power, cooling, or facility failure.
Redundant uplinks and multiple routed paths per zone, with BGP recalculating routes when a path is withdrawn. Absorbs: an uplink loss, a fibre cut, a router or switch failure.
Volumes are replicated across zones by Ceph, so a copy of the data is present in more than one failure domain. Absorbs: a disk, host, or zone loss without data loss.
Capacity is pooled across nodes in all three zones; the scheduler spreads replicas using topology constraints. Absorbs: a node failure, without capacity landing in one zone.
The OpenShift control plane runs with members in separate zones and keeps quorum when one is lost. Absorbs: loss of a control-plane node; the API stays available.
Multiple replicas behind a service, health probes, pod disruption budgets, and rolling updates. Absorbs: an unhealthy instance or a bad deployment, without a maintenance window.
Virtual machines run as Kubernetes workloads under OpenShift Virtualization. When a node or a whole zone becomes unavailable, the affected virtual machines are restarted automatically on healthy nodes in another availability zone.
This works because the disks are not local to the failed node: VM volumes live on replicated shared storage that is reachable from every zone, so the new instance attaches the same volume and boots with its state intact. Live migration is used for planned maintenance; restart-in-another-zone is the response to an unplanned failure.
Service addresses are advertised into the network with BGP by MetalLB. Several nodes announce the same address, and upstream routers distribute flows across the available next hops using ECMP. When a node, zone, or path stops passing health checks, its announcement is withdrawn and the routers converge on the remaining paths.
The same address can be announced from more than one location as an anycast address, so client traffic follows the shortest available path and shifts toward healthy regions when one stops announcing. Clients keep using one address; no DNS change or manual cut-over is required.
Persistent volumes are provided by Ceph through OpenShift Data Foundation and provisioned with CSI drivers. Data is replicated across failure domains, and placement rules keep the copies of an object in different zones so that no single zone holds every replica.
Within a site, replication is synchronous and a write is acknowledged once the required copies are durable — a zone can be lost without data loss. Between sites, volume replication is used for regional protection, where the recovery point is bounded by the replication interval rather than by the last backup.
Infrastructure failover restores a process; it does not by itself keep an application’s data consistent across sites. Event-driven architectures close that gap by replicating state asynchronously through a message layer — Kafka, RabbitMQ, or NATS — instead of relying on a synchronous database write path stretched across regions.
Producers append events to durable, replicated topics or queues; consumers in another zone or site apply them at their own pace and track their position. Messages survive a broker restart, and a consumer that was unavailable resumes from its last committed offset rather than losing the work. The trade-off is explicit: the remote copy lags by the replication delay, and the application is designed to tolerate that.
The properties below are architectural choices, not operational procedures — which is what makes them repeatable.
Most serious incidents are not caused by a component failing. They are caused by the recovery being manual, undocumented, or different from the last time it was performed. A declarative platform reduces that risk by making the desired state explicit and letting controllers drive the system back to it.
No single node, uplink, disk, or zone is required for a workload to keep running. Redundancy is applied at the infrastructure, network, storage, compute, cluster, and application layers.
Each site runs its own control plane and makes its own scheduling and routing decisions. There is no central region whose loss stops the rest of the platform.
The system is designed to degrade rather than stop: reduced capacity during a zone loss, not a full outage, and recovery to full capacity once the zone returns.
Failure domains are physical and bounded — a zone, a site — and namespaces plus NetworkPolicy bound the logical domains, so a compromised or misbehaving workload does not spread laterally.
Failed pods are restarted, unschedulable workloads are rescheduled, unhealthy endpoints are removed from services, and degraded storage is re-replicated — automatically, and continuously.
Platform and application updates replace instances incrementally while health probes and disruption budgets hold availability. A failed rollout is rolled back to the previous revision.
Sites are built from the same declarative definitions. A new zone or site is provisioned from code, which is what makes deploying many small sites practical instead of bespoke.
Operators encode the operational knowledge for a component — install, upgrade, backup, failure handling — as software, so the response to a failure is the same every time it happens.
Controllers compare declared state to observed state continuously and correct the difference. Drift is repaired without a change request; recovery is the normal control loop, not an exception.
The platform is owned and operated in the Netherlands under EU jurisdiction, so the operational model, the data, and the legal control of the infrastructure stay in the same place.
What this reduces. Fewer manual recovery steps means fewer opportunities for an incident to be extended by a mistake made under pressure. The recovery path is exercised by the platform continuously, rather than being tested for the first time during an outage.
What the design produces, stated as properties you can verify rather than claims.
Regional sites place compute physically closer to users and devices.
Capacity in multiple zones and, as sites come online, multiple regions.
Routing, scheduling, and storage recovery converge without manual steps.
Networks, policies, and routes are API objects, versioned in Git.
Default deny between namespaces; every allowed path is explicit.
Kubernetes, BGP, EVPN, WireGuard, Ceph — no proprietary control plane.
Clusters across zones, sites, and premises connected as one network.
Separate power, cooling, uplinks, and network per zone — no shared fate.
Owned and operated in the Netherlands, under EU jurisdiction and GDPR.
Adding a site adds a failure domain; the topology grows without redesign.
Where distributed, policy-driven networking changes what the architecture can commit to.
Line-of-business systems that were built for a datacenter network. UDN preserves existing VLAN segmentation for migrated virtual machines while new components run as containers alongside them.
VM + container on one networkPatient data stays under EU jurisdiction, segmented per system with NetworkPolicy, reachable from clinical networks over a VPN rather than a public endpoint, and replicated across zones.
data residency · segmentationRecovery objectives are met with multi-zone placement and replicated storage; every allowed network path is declarative and auditable, and exit is possible because nothing is proprietary.
DR · auditability · DORA exitSovereign infrastructure operated in the Netherlands, isolated networks per department or programme, and no exposure to non-EU legal instruments over the operating entity.
sovereignty · isolationPer-customer namespaces and networks with default-deny policy between them, one operating model across all tenants, and multi-cluster gateways to reach customer premises.
multi-tenant isolationProcessing runs at the regional site nearest the source instead of a distant central region, and the site keeps operating when the link back to the rest of the platform is down.
proximity · offline toleranceInference is latency-sensitive and bandwidth-hungry. Serving from a nearby regional site shortens the round trip, and load balancing spreads requests across accelerator-backed endpoints.
low-latency servingDevice fleets connect over VPN into segmented networks. Telemetry is buffered in durable message queues, so a network interruption delays delivery instead of discarding measurements.
durable ingest · segmentationPlant systems require deterministic local connectivity and continuity through a WAN outage. A nearby autonomous site keeps control and monitoring workloads running while the link is down.
continuity · OT/IT separationThe components the platform is built from, and what each one is responsible for.
| Category | Technology | Role |
|---|---|---|
| Container platform | Red Hat OpenShift | Kubernetes distribution providing the API, control plane, and operator framework. |
| Networking | Kubernetes CNI | Pod addressing and the cluster data plane; enforces NetworkPolicy in the kernel. |
| Firewall | NetworkPolicy | Declarative, label-selected allow rules for east–west and ingress traffic. |
| Load balancing | MetalLB | External addresses for LoadBalancer services on bare metal, advertised over BGP. |
| Routing | BGP | Dynamic route distribution and reconvergence when a path or node is withdrawn. |
| Multi-cluster | Submariner | Cross-cluster pod and service connectivity with shared service discovery. |
| Virtual networking | KubeVirt UDN | User-defined layer-2 and layer-3 networks for virtual machine workloads. |
| VPN | OpenVPN, WireGuard | Encrypted remote access and site-to-site tunnels, deployed as container workloads. |
| Storage replication | Ceph / OpenShift Data Foundation | Replicated block, file, and object storage with zone-aware placement rules. |
| Messaging | Kafka, RabbitMQ, NATS | Durable, replicated event and message transport for asynchronous application replication. |
| High availability | Multi-zone | Three availability zones per site; topology-aware scheduling and quorum across zones. |
| Regional failover | BGP anycast | One service address announced from multiple locations; traffic follows healthy paths. |
| Infrastructure | Distributed micro datacenters | Container-sized sites with independent power, cooling, uplinks, and networking. |
All components are open standards or open source. Configuration is expressed as Kubernetes resources and is portable to any conformant Kubernetes cluster.
Answers at the level of detail an architect needs to evaluate the platform.
Service addresses are advertised into the network with BGP. Several nodes — and, where a service is deployed in more than one location, several sites — announce the same address, and upstream routers select a path. When a node, zone, or site stops passing health checks, its announcement is withdrawn and routers converge on the remaining announcements, so traffic shifts toward healthy capacity without a DNS change or a manual cut-over.
Failing over the traffic is only half the design. The application must also have somewhere to land: replicas scheduled in another zone or site, and data that is present there through storage replication or asynchronous application-level replication.
The zone stops announcing its service addresses, so traffic moves to the other two zones within the routing convergence time. Pods that were running there are rescheduled onto nodes in the remaining zones, and virtual machines are restarted there because their volumes are on replicated shared storage rather than on local disk in the failed zone.
The cluster keeps quorum because control-plane members are spread across all three zones. Storage continues to serve from the surviving replicas and re-replicates to restore the configured redundancy. The site runs at reduced capacity until the zone returns, at which point it rejoins and data is resynchronised.
An availability zone is one container-sized micro datacenter with its own power, cooling, internet uplinks, and network equipment. A regional site is a group of three such zones that operates as one autonomous location with a shared low-latency network between them.
Zones protect against equipment and facility failures and are close enough for synchronous replication. Regions protect against events that affect a whole location, and are far enough apart that replication between them is normally asynchronous.
Virtual machines run under OpenShift Virtualization (KubeVirt) as Kubernetes workloads, so they use the same scheduling, health, and storage mechanisms as containers. Their disks are persistent volumes on replicated shared storage reachable from every zone.
For planned maintenance, a VM is live-migrated to another node with no restart. For an unplanned node or zone failure, the VM is restarted automatically on a healthy node in another zone and reattaches the same volume. Networking follows: with UDN, the VM keeps its network identity on the user-defined network rather than being re-addressed.
Yes. Submariner connects Kubernetes clusters so that pods and services in one cluster reach services in another using normal cluster DNS names, and BGP EVPN provides routed layer-2 and layer-3 overlays between sites. From the application’s point of view, a remote service is addressed the same way a local one is.
The physical constraint remains: cross-region calls carry the round-trip time between sites. Chatty synchronous request paths should stay within a site; cross-region traffic is best used for replication, asynchronous events, and failover.
The model is zero trust: being on the cluster network grants no access by itself. Namespaces with a default-deny NetworkPolicy accept only explicitly allowed connections, selected by pod label, namespace, port, and protocol, and enforced by the CNI data plane rather than by application code.
Traffic that leaves the platform is encrypted — TLS for public endpoints, and VPN or encrypted tunnels for site-to-site and administrative access. Because every rule is a Kubernetes object, the complete set of allowed paths can be reviewed in Git and audited against what is running.
OpenVPN and WireGuard are both available as container images and run as ordinary workloads in the cluster. OpenVPN is TLS-based with wide client support and a mature certificate model; WireGuard is a smaller modern protocol with an in-kernel data path and lower connection overhead.
Both are used for remote administrative access and for site-to-site links to offices and on-premises networks, which lets services stay unreachable from the public internet while remaining reachable from trusted networks.
Yes. Submariner connects conformant Kubernetes clusters regardless of where they run, including clusters on your own hardware or at another provider. Where connectivity is needed at the network layer instead, BGP EVPN and VPN tunnels link the underlying networks.
Nothing about this requires proprietary agents or a vendor control plane: the connectivity is built from standard Kubernetes objects and standard routing protocols.
Yes, and it is a common starting point. An on-premises cluster and a GRN.CLOUD cluster can be joined so that services are discoverable in both, which supports gradual migration, keeping specific systems on-premises for regulatory reasons, and using GRN.CLOUD as the recovery target for on-premises workloads.
Because the platform is standard Kubernetes and OpenShift, the same manifests, pipelines, and network policies apply on both sides.
Persistent volumes are provided by Ceph through OpenShift Data Foundation and provisioned with CSI drivers. Placement rules are zone-aware, so the replicas of a volume are distributed across availability zones and no single zone holds every copy.
Within a site, replication is synchronous — a write is acknowledged once the required number of copies are durable — so a zone can be lost without data loss. Between sites, volume replication is asynchronous and the recovery point is bounded by the replication interval. For application state that must be reconciled rather than mirrored, asynchronous replication through Kafka, RabbitMQ, or NATS is used instead.
Bring your availability targets, recovery objectives, and network constraints. We will walk through the zone and region topology, the failover paths, and how your workloads would be placed across them.
Far far away, behind the word moun tains, far from the countries Vokalia and Consonantia, there live the blind texts. Separated they live in Bookmarksgrove right at the coast of
759 Pinewood Avenue
Marquette, Michiganinfo@domain.com
Online Support906-624-2565
Mon-Fri 8am-5pmSwitch The Language
Nederlands (Dutch)
English