KaaS deployment requirements

Required: what the environment provides

On customer-owned infrastructure these come from your OpenStack environment or from the foundation scope of the engagement; on WECORE Hub they are part of the operated infrastructure.

• OpenStack with the container-infra service

  A working OpenStack cloud with the container-infrastructure service and its management cluster, deployed by the engagement where you don't run one yet.

• External network and floating IP capacity

  An external network for cluster access, with network quotas and floating-IP policy; preflight validates them before anything is created.

• A working load-balancer service

  Each cluster gets one load balancer and floating IP for its API server; preflight confirms the enabled provider matches the template before create.

• Machine sizes with quota headroom

  Approved control-plane and worker sizes resolvable in your project, with root-disk properties and enough compute quota; shortfalls block in preflight.

• Application-credential headroom

  Each cluster runs under its own minted application credential, so the project needs credential quota for one per cluster.

• A cluster image matching the template

  The template's Kubernetes version must match a validated cluster image made available in the environment; templates and images are prepared by the deployment.

• Block-storage capacity for declared volumes

  Templates declare their system volumes; the environment needs the matching volume type and storage quota, accounted in preflight.

Supported today: the default service

• One worker group, one control-plane machine

  Every cluster has a single worker group and a single control-plane machine, both sized from the approved template.

• Worker-count resize on a running cluster

  Authorized users change the worker count; every change is re-validated server-side. The reference staging run converged a resize in 10.9 seconds.

• Fresh credentials per download

  Each authorized kubeconfig download mints a fresh credential in memory and streams it with no-store handling; nothing is written to the panel database or logs.

• Verified deletion

  Deletion revokes the cluster credential and scans servers, volumes, floating IPs, load balancers, and credentials for leftovers; repeats are safe.

• Hourly metering on the deployment rate table

  The create-time estimate and the hourly charge use the same configured rates.

• Versions from approved templates

  Kubernetes versions come from the templates your infrastructure team approves; the reference staging lifecycle ran Kubernetes v1.36.1.

Conditional, enabled per deployment

These capabilities exist in the service but are off by default; your infrastructure team enables them per deployment where the environment supports them.

• In-place upgrades

  Upgrade to a compatible newer template: one minor version at a time, never a downgrade. Otherwise teams migrate workloads to a cluster created from a newer template.

• Worker autoscaling

  A single min–max range for the cluster's worker group, with an operator-configured span cap.

• Additional node groups, ingress, monitoring, workload storage

  Feature-gated; shown to users only when enabled for a compatible template in your deployment.

Not currently offered

• Multiple worker groups in one cluster

  A different machine configuration belongs in a separate cluster created for it; multi-group requests are refused before any resource is created.

• Multi-master control planes through the panel

  Each cluster runs one control-plane machine today; resilience of the underlying infrastructure is defined in the deployment engagement.

• GPU worker nodes

  GPU batch and simulation workloads run on the HPC platform, and dedicated model serving runs on the LLM service.

• Per-user cluster permissions

  A downloaded kubeconfig carries cluster-admin for that cluster; scoping inside the cluster is your team's Kubernetes RBAC.