Kubernetes compute · OpenShift · Netherlands

Compute for every workload

GRN.CLOUD provides multiple Kubernetes-native compute models so applications can run in the environment that best matches their architecture — from traditional virtual machines to cloud-native containers and event-driven serverless functions.

All three models run on the same OpenShift platform. They share one control plane, one RBAC model, one network fabric, and one storage layer, so moving a workload between models is a change of packaging rather than a change of provider. Sizing, resource configuration, and pricing are handled on the Shared Public Cloud page.

Explore Shared Public Cloud View marketplace

Virtual machines · containers · serverless · one OpenShift platform, EU-hosted.

Compute models

One platform, three ways to run a workload.

Workloads differ in how they are packaged and how they consume resources. Some applications are delivered as a full operating system image and expect a virtual machine. Others are containerized and benefit from declarative orchestration. Some need code to execute only when an event arrives, and no reserved capacity in between. GRN.CLOUD supports all three on the same OpenShift platform, so modernisation does not require a second provider or a second operating model.

Legacy virtual machines

KubeVirt

Traditional virtual machines run as Kubernetes objects. A VirtualMachine resource is scheduled, networked, and given storage through the same primitives as a pod, so VMs and containers share one cluster, one API, and one set of policies.

Suitable for

Windows workloadsLinux serversERPLegacy applicationsLift-and-shift migrations
  • LifecycleCreate, start, stop, snapshot, and template VMs from the console or the API.
  • OrchestrationKubernetes scheduling, RBAC, quotas, and observability apply to VMs unchanged.
  • Live migrationRunning VMs move between nodes for maintenance without shutting down.
  • High availabilityVMs restart on surviving nodes when a node or zone is lost.
Learn more →

Cloud-native containers

Kubernetes

Containerized applications are described declaratively and reconciled by the cluster. Deployments, Services, and ConfigMaps define the desired state; the control plane keeps the running state matched to it and reports where the two diverge.

Suitable for

MicroservicesAPIsWeb applicationsCI/CDModern enterprise software
  • Rolling updatesProgressive rollout with automatic rollback when readiness probes fail.
  • Self healingFailed containers are restarted and unhealthy replicas replaced automatically.
  • Horizontal scalingReplica count is adjusted by the Horizontal Pod Autoscaler.
  • DeclarativeVersioned manifests, reproducible environments, GitOps-ready deployments.
Learn more →

Serverless functions

Knative

Stateless services scale automatically with incoming requests, including down to zero replicas when idle. A request or an event activates the service; between invocations no capacity is reserved and none is charged.

Suitable for

APIsAutomationEvent processingScheduled jobsLightweight services
  • Scale to zeroIdle services release their replicas; the platform reactivates them on demand.
  • Fast startupContainer images are pre-pulled and revisions are activated in seconds.
  • Event drivenCloudEvents sources and triggers connect functions to queues, storage, and timers.
  • Active-only usageResources are consumed while a revision is serving, not while it waits.
Learn more →

Application marketplace

Provision compute together with a ready-to-deploy application.

Compute resources can be provisioned together with curated application images. Each marketplace entry ships as a template with defaults for storage, networking, and resource requests, so an application reaches a running state with minimal manual configuration. Images are deployed into your own project and remain yours to configure, update, and remove.

Databases

  • PostgreSQL
  • MariaDB
  • MySQL
  • Redis

Web

  • NGINX
  • Apache
  • WordPress

Office & collaboration

  • Nextcloud
  • OnlyOffice
  • Collabora

Artificial intelligence

  • Ollama
  • Open WebUI
  • OpenDataHub

Developer tools

  • GitLab
  • Gitea
  • Jenkins
  • Harbor

Deploy your own

  • Container image
  • Helm chart
  • Operator
  • VM image

How it works. Select an image, choose a compute model and size, and the platform creates the workload, its storage claim, and its route in one operation. Everything it creates is a standard Kubernetes object you can inspect, edit, or export.

Platform features

Scaling, load balancing, and traffic routing are part of the platform.

These capabilities apply to every compute model. They are configured as Kubernetes resources rather than as separate managed services, so the same manifests work for a container, a virtual machine, or a serverless revision.

Horizontal auto scaling

Horizontal Pod Autoscaler (HPA)

Automatically adjusts the number of running application instances based on CPU, memory, or custom metrics. Thresholds and minimum and maximum replica counts are declared per workload, and the controller reconciles the replica count continuously.

Load balancing

MetalLB

Distributes incoming traffic across healthy workloads and provides Kubernetes-native LoadBalancer services on bare-metal infrastructure. Addresses are advertised with BGP, so traffic follows capacity rather than a fixed appliance.

Traffic management

Gateway API

Kubernetes-native traffic routing with centralised ingress management: hostname- and path-based routing, TLS termination, and policy-driven traffic control such as weighted splits for canary and blue/green releases.

Architecture

Every compute model runs on the same platform stack.

Requests enter through the Gateway API layer, which terminates TLS and routes by hostname to a backing service. Below it, OpenShift schedules and reconciles the workload, whatever its shape. Containers, virtual machines, and serverless revisions are peers at the same level of the stack and draw on the same storage and networking layers beneath them.

Figure 1. The compute stack. Only the workload layer differs between compute models — everything above and below it is shared.

Choosing a model

Why the platform supports three compute models rather than one.

Compute models, their typical workloads, and the technology behind each
Compute modelBest forTechnology
Virtual machinesLegacy applicationsKubeVirt
ContainersCloud-native applicationsKubernetes
ServerlessEvent-driven workloadsKnative

In practice, organisations run all three models at once rather than replacing one with another. A modernisation programme typically starts by migrating existing servers into virtual machines, then re-platforms the components that benefit most from orchestration into containers, and finally moves the intermittent parts — webhooks, scheduled jobs, batch handlers — to serverless. Because all three run on the same cluster and share the same network, storage, and identity model, that sequence can be done application by application, without a migration deadline and without a second platform to operate in parallel.

Ready to deploy your workloads?

Provision virtual machines, containers, or serverless workloads on GRN.CLOUD Shared Public Cloud and deploy applications from the integrated marketplace.

Explore Shared Public Cloud Browse marketplace
X
Compute

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, Michigan

  • info@domain.com

    Online Support

  • 906-624-2565

    Mon-Fri 8am-5pm
Purchase Now