Skip to content

Core concepts

GRN.CLOUD is a set of distributed OpenShift and Kubernetes clusters in the Netherlands. Compute, storage, networking and data services are objects in the same cluster API rather than separate products with separate consoles.

Five ideas underpin every other page on this site. Read them once.

Project

A project is your unit of tenancy — a Kubernetes namespace with quotas, limits, RBAC bindings and network policy attached. A new project accepts connections from its own workloads and from the other projects of your tenant on every port, and from anyone else on the web ports only. Every other connection is opt-in, with a firewall.

Everything you deploy lands in a project. Billing, access control and resource limits are all scoped to it.

Cluster and distribution

Workloads run on a managed cluster with a highly available control plane. GRN operates the control plane, upgrades and the storage, networking, observability and backup plumbing. You keep cluster-admin and standard tooling.

Three distributions are available, all CNCF-conformant:

Distribution What it is
OKE Vanilla upstream Kubernetes
OKD Open-source OpenShift
OCP Red Hat OpenShift

All three present the same Kubernetes API, so manifests are portable between them and off the platform entirely.

Availability zone

Each regional site has three independent availability zones, each with its own power, cooling, uplinks and network fabric. Workloads spread across zones using topology spread constraints; Ceph replicates volumes across zones so a zone can be lost without data loss.

The object model

A virtual machine is a VirtualMachine. A volume is a PersistentVolumeClaim. A firewall rule is a NetworkPolicy. A load balancer address comes from a Service of type LoadBalancer. A served model is a Deployment running an inference engine.

Because these are all API objects, your infrastructure configuration lives in Git next to the application it belongs to, is applied by the same pipeline, and is reviewed as a diff.

flowchart TB
    subgraph Project["Your project (namespace)"]
        VM["VirtualMachine<br/>KubeVirt"]
        POD["Deployment<br/>containers"]
        KSVC["Knative Service<br/>scale to zero"]
        ISVC["Deployment<br/>vLLM on a GPU"]
    end
    subgraph Shared["Shared platform foundation"]
        API["One Kubernetes API"]
        RBAC["One RBAC model"]
        NET["One network fabric"]
        STOR["One storage layer"]
    end
    Project --> Shared

Isolation levels

Isolation is decided per workload rather than per account. Three levels are available:

  • Public Cloud — a project on shared infrastructure
  • Virtual Private Cloud (VPC) — dedicated virtual resources, KubeVirt VM workers
  • Dedicated Private Cloud (DPC) — dedicated bare-metal hosts, physical isolation

The API and the manifests are the same at all three levels. Only where the workload is placed changes.

Next

Accounts & projects →