Segal Clusters
Coordinate application workloads through a managed Kubernetes cluster and explicitly sized node pools.
The supported upstream service is Managed Kubernetes Service. Segal supplies the branded application and support boundary; activation depends on the approved customer configuration and applicable provider terms.
Request and resource flow
- Create a dedicated cluster in the customer’s project.
- Attach the required CPU or GPU-capable node pools.
- Deploy workloads with persistent volumes and network policies.
Configuration responsibilities
- Control plane and worker-node responsibilities are separate.
- Container images come from a controlled registry.
- GPU scheduling requires the appropriate device integration.
Supported scope
Kubernetes clusters and worker node pools. This is not a promise of a dedicated NVLink or InfiniBand fabric.
- A Kubernetes cluster is not a guaranteed NVLink domain.
- Interconnect and GPU topology need a workload-specific review.
- Cluster and node-pool lifecycle can incur separate charges.
Read your organization’s inventory
Open the Clusters workspace after signing in. The server resolves your active organization and its allowed OVHcloud resources. It does not accept a provider project ID from the browser.
The authenticated endpoint is GET /api/infrastructure/clusters. Supply an allowed region where needed, and a zero-based page for inventory pagination. Each response reports the requested region and the next page when one exists. Project-wide inventories may contain resources from more than one region; an unreported resource region is not inferred from a seed catalog.
The endpoint uses the Segal browser session. Demonstration sk_segal_ keys do not grant production access. Provider credentials stay server-side. A missing connection returns an explicit error rather than sample resources.
Submit a configuration
POST /api/infrastructure/clusters accepts requestId (UUID), operation: "create", acknowledgeCharges: true and a parameters object containing name, region (control plane only; worker node pools are separate).
An organization owner or administrator must submit the operation from the same origin. The operator must first activate provisioning and confirm reseller terms. An atomic database operation record claims the request ID before the upstream mutation. Reusing that ID does not submit a second mutation; a conflicting payload is rejected.
An accepted response means the provider accepted the request, not that the resource is ready. If a response is lost, use GET /api/infrastructure/operations/REQUEST_UUID and ask engineering to reconcile the state. Do not issue a new request ID as an automatic retry.
Activation and service evidence
Follow provider setup before enabling live access. Demo resources, website imagery and documentation examples do not verify capacity, certification, latency or delivery. Confirm regional availability, contract scope, recovery ownership and final customer pricing before production use.
Read the product architecture. Upstream technical reference: Managed Kubernetes Service (reviewed 24 October 2026).