Managed Kubernetes for your teams or customers.

No. A cluster has one worker group, and GPU worker nodes are not part of the Kubernetes service: GPU batch and simulation workloads run on the HPC platform, and dedicated model serving runs on the LLM service. Users can change that group's worker count; a different machine configuration belongs in a separate cluster created for it.

On the OpenStack infrastructure your organization or service provider controls. The deployment agreement defines its location and capacity controls.

Yes. The deployment engagement can include WECORE deploying and validating the underlying OpenStack environment on hardware you own or lease; if you already operate a compatible OpenStack, we integrate with it. Physical infrastructure is sourced separately.

You can: this service exists for teams that don't want to own that layer. What the engagement adds to plain kubeadm or Kubespray is the operated product around the cluster: approved templates, server-side preflight with a cost estimate from the billing rate table, per-download credentials that are never stored, verified deletion with a leak scan, and agreed operations, on the same platform that runs your HPC and research services.

No. Each authorized kubeconfig download creates a fresh client credential in memory. The private key is streamed to the user and is not written to the panel database or logs.

Authorized users can create clusters after group access, available templates, and the production gate have been approved. These controls are defined with your infrastructure team for each deployment.

The estimate and hourly charge use the same deployment rate table. The panel shows hourly and 730-hour monthly figures before creation; when rates are not configured, it says so.

Users can change the worker count of the cluster's one worker group. The service does not offer multiple worker groups.

The service includes neither ingress nor a monitoring stack. Optional node repair or worker autoscaling is available only when your infrastructure team enables it in a compatible template.

Each cluster runs a single control-plane machine today; you choose its size from the approved template. Resilience of the underlying OpenStack infrastructure is defined in the deployment engagement.

Versions come from the templates your infrastructure team approves. In-place upgrade to a compatible newer template is an option your infrastructure team can enable per deployment: one minor version at a time, never a downgrade. Otherwise teams migrate workloads to a cluster created from a newer template.

WECORE deploys the service, validates the production gate, and operates the agreed service lifecycle. Your infrastructure team owns the template catalog, access, rates, optional capabilities, and the read-only kill switch. Your users own the clusters they create: their workloads and worker counts. WECORE monitors service health, coordinates upgrades, and works incidents within the responsibility split agreed for your deployment. Panel access is role-based, and administrative actions are recorded in tamper-evident audit records. Hardware and facility stay with the infrastructure owner unless included separately; the pricing page carries the full responsibility and access model.

Deletion revokes the cluster application credential and performs a leak scan across servers, volumes, floating IP addresses, load balancers, and credentials. Repeating a deletion request is safe and ends in the same clean state.