Kubernetes namespace rentals

Limited and unlimited namespaces

A limited namespace receives the selected CPU, RAM, disk, and optional GPU quota and is pinned to a chosen eligible node. It is the right default for a bounded team environment. An unlimited namespace receives the broader capacity semantics advertised by the provider and may reserve a node or cluster boundary; its workloads still follow the same security and purchased-node boundary.

“Unlimited” does not mean permission outside the rented cluster boundary or freedom from the provider’s acceptable-use requirements. Kubernetes authorization and platform isolation still apply.

A limited namespace reserves its GPU count even while no GPU pod is running. Its GPU quota applies across pods, not separately to each pod. Choose zero GPUs for CPU-only workloads. On cluster listings, GPU count selection currently requires a homogeneous pinned node; a mixed-model node is not a supported count-selection shortcut. Unlimited namespaces follow their pinned-node or cluster-wide ownership scope rather than individual GPU deselection.

Inspect the confirmed allocation and applicable per-device measurements. Do not interpret a host benchmark as the performance of a smaller reservation. Ending one rental releases its resources; another renter's allocation remains separate.

Configure the namespace

On a cluster listing, choose the supported namespace mode. For limited mode, select a pinned node and resource quantities within the listing’s remaining capacity. If GPUs are requested, choose a count the pinned node can satisfy. Review the hourly price and contract end date, then launch.

ComputeCubed creates a generated namespace name and a scoped service account, normally displayed as tenant-admin. The rental becomes active only after the access boundary is ready.

Connect with WireGuard and kubeconfig

Use the profile issued for this rental. Kubernetes Service ClusterIP addresses are internal and are not advertised as directly reachable from your device. To access a service in your namespace, use kubectl port-forward service/SERVICE_NAME 8080:SERVICE_PORT with the rental kubeconfig, then connect to 127.0.0.1:8080. Keep that command running while using the service.

1. 01

   Generate the rental WireGuard profile

   Install it on the device where kubectl will run and verify a current handshake.
2. 02

   Download kubeconfig

   The action is enabled for an active namespace rental. Store the file with owner-only permissions.
3. 03

   Verify identity and scope

   Set KUBECONFIG, inspect the current context, and confirm the namespace before applying anything.

chmod 600 ./computecubed-kubeconfig.yaml
export KUBECONFIG="$PWD/computecubed-kubeconfig.yaml"
kubectl config current-context
kubectl auth can-i --list
kubectl get pods

Operate inside the boundary

Use namespace-scoped Pods, Deployments, ReplicaSets, StatefulSets, Jobs or CronJobs, ClusterIP Services, ConfigMaps and newly provisioned PVCs. Quotas, limits, network policies, credentials, service accounts and authorization rules are platform-owned. You can inspect quotas and policies, but cannot change or delete them. Secrets and cluster-wide APIs are not exposed through rental credentials. DaemonSets, custom schedulers, affinity, arbitrary tolerations, host networking, host paths and privileged containers are not supported.

Choose a hostname from Purchased nodes in rental details. Every Pod and controller Pod template must include these fields, in addition to its containers and resource quantities:

spec:
  nodeSelector:
    kubernetes.io/hostname: PURCHASED_NODE_NAME
  serviceAccountName: tenant-workload
  automountServiceAccountToken: false
  securityContext:
    seccompProfile:
      type: RuntimeDefault

Every container, including init containers, must set securityContext.capabilities.drop: [NET_RAW] or [ALL]. Raw sockets are unsupported.

The downloaded kubeconfig identifies your login; do not use that login service account inside a Pod. Workload service accounts do not receive Kubernetes API credentials. Direct nodeName binding and attempts to select another node are rejected at admission. A retry preserves the purchased node list; newly joined provider nodes do not silently enlarge an existing rental.

Use explicit resource requests and limits. Limited workloads require positive CPU, memory and ephemeral-storage limits; zero does not mean free unbounded capacity. Keep each GPU workload on its selected purchased node. On an AMD rental, request amd.com/gpu in the container's GPU resource requests and limits. On an NVIDIA rental, list the claim templates supplied with your namespace using kubectl get resourceclaimtemplates, then reference only a template for a GPU in your rental. For example, add this to a Pod or Pod template to use one purchased NVIDIA GPU:

spec:
  resourceClaims:
    - name: rented-gpu
      resourceClaimTemplateName: contract-gpu-0
  containers:
    - name: worker
      resources:
        claims:
          - name: rented-gpu

Use one claim entry per Pod. Use an individual contract-gpu-N template when that Pod needs one card. On a single-node rental with multiple NVIDIA GPUs, use contract-gpus when one Pod needs all contracted cards together. List the available templates in your namespace before choosing. A Pod without a claim does not receive an NVIDIA GPU; a claim for an unpurchased GPU is rejected. NVIDIA rentals do not use nvidia.com/gpu count requests. GPU allocation does not permit privileged containers or direct host device mounts. Omit runtimeClassName: GPU access is supplied only for the devices allocated to each container. Custom runtimes and device-injection annotations are unsupported. Environment variables cannot grant additional devices. Pod-level resource budgets, hugepages and other device resource types are unsupported. Workloads needing host privileges are unsupported by namespace rentals.

Workloads can communicate within their namespace, resolve cluster DNS and reach public internet destinations. Direct traffic to other tenants and private provider networks is blocked. Image downloads run through the node’s image service; they do not give Pods access to registry credentials. Access your own services with kubectl port-forward; NodePort and externally addressed Services are unsupported. Root inside a container is allowed where an image needs it, but does not grant host or cluster administration. Namespace rentals are a shared-kernel boundary, not a dedicated virtual machine.

Quota or scheduling errors usually mean the manifest exceeds the selected allocation, the pinned node lacks remaining capacity, or the image does not support the accelerator. Describe pods and inspect events before assuming the cluster is offline.

kubectl get resourcequota
kubectl get events --sort-by=.lastTimestamp
kubectl describe pod <pod-name>

Back up and end

Export Kubernetes objects you need, copy persistent data to storage you control, and delete any externally billed resources you created. Ending the rental invalidates its kubeconfig and private access and initiates namespace cleanup. Disconnecting WireGuard alone does not stop billing.

The rental page includes Your rental reliability history, available only to you. It saves observed service interruptions, container restarts, and supported GPU measurements after a delay of at least six hours and five minutes. It remains useful after the raw chart window expires. See past rental reliability for coverage, sensor interpretation, and public aggregation rules. Historical chart windows for ended rentals end at that rental's completion time.