Skip to content

Core concepts

GRN.CLOUD is not a catalogue of separate products with separate consoles. It is a set of distributed OpenShift and Kubernetes clusters in the Netherlands, where compute, storage, networking and data services are objects in the same cluster API.

Understanding these five ideas makes the rest of the documentation predictable.

Project

A project is your unit of tenancy — a Kubernetes namespace with quotas, limits, RBAC bindings and network policy attached. Workloads inside a project can talk to each other; traffic across projects is opt-in.

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

Same Kubernetes API in every case, 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.

Everything is an object

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 an InferenceService.

The practical consequence: your infrastructure configuration lives in Git next to the application it belongs to, is applied by the same pipeline, and is reviewable 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["InferenceService<br/>KServe"]
    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 is a choice

Isolation is decided per workload, not per account:

  • 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 do not change between them. The placement does.

Next

Accounts & projects →