# IaaS Capacity and Node Provisioning

The Capacity Pool is the foundational resource layer from which all OpenShift cluster resources are drawn. Understanding how capacity flows from physical infrastructure to schedulable cluster nodes is essential for planning and operating workloads on Sunrise.

---

## The Capacity Pool

The capacity pool consists of aggregated compute nodes (VMs or bare-metal servers), shared storage backends, and network fabric. Resources within the pool are expressed in three dimensions:

| Dimension | Unit |
|---|---|
| Compute | vCPU cores |
| Memory | GB of RAM |
| Storage | GB |
| GPU | NVIDIA H100 (`nvidia.com/gpu`) |

The pool is managed by the underlying infrastructure provider, which on Sunrise infrastructure is a private cloud environment. OpenShift's **Machine API** and **cluster autoscaler** can dynamically expand or contract the pool based on workload demand. Capacity is carved into worker nodes that join the OpenShift cluster, making resources schedulable by the Kubernetes control plane.

```
Capacity Pool
┌──────────────────────────────────────────────┐
│  Total vCPUs   │  Total RAM (GB)  │  Storage │
└────────┬───────┴─────────┬─────────┴────┬─────┘
         │                 │              │
    ┌────▼────┐       ┌────▼────┐   ┌────▼────┐
    │ Node 1  │       │ Node 2  │   │ Node N  │
    └─────────┘       └─────────┘   └─────────┘
         OpenShift Cluster (Schedulable Resources)
```

---

## Provisioning Flow

Provisioning follows a five-step top-down sequence from raw infrastructure to running workloads.

**Step 1, Capacity Pool**
Physical or virtual machines contribute CPU, RAM, and storage to the shared capacity pool.

**Step 2, Node Registration**
Worker nodes join the OpenShift cluster and advertise their allocatable resources to the Kubernetes scheduler.

**Step 3, Namespace Quota Assignment**
Platform administrators define `ResourceQuota` objects per namespace, reserving a governed slice of cluster capacity for each tenant.

**Step 4, Pod Scheduling**
When a workload is deployed, the Kubernetes scheduler places pods on nodes that have sufficient available resources, while respecting namespace quotas.

**Step 5, Resource Enforcement**
The `kubelet` agent on each node enforces CPU and memory limits at runtime. Persistent storage is provisioned separately via `PersistentVolumeClaims` (PVCs).

---

## Dynamic Scaling

OpenShift's cluster autoscaler monitors pending pod demand and triggers Machine API calls to provision additional nodes when the existing pool cannot satisfy scheduling requests. Nodes are also deprovisioned automatically when they are no longer needed, helping to keep infrastructure costs aligned with actual usage.

---

## GPU Nodes

GPU capacity is provided by HGX nodes, each with 8×NVIDIA H100 GPUs. GPUs are exposed to the scheduler as the `nvidia.com/gpu` resource and consumed the same way as CPU and memory.

You do **not** need to discover node labels or set a `nodeSelector` to land on a GPU node, and tenants cannot list nodes at tenant scope. Simply request `nvidia.com/gpu` in your workload, and the scheduler places it on a node with available GPUs.

For scheduling examples, deployment models (container vs. VM passthrough), driver responsibility, and GPU monitoring, see [GPU Infrastructure](./gpu-infrastructure.md).

---

## Related Pages

- [OpenShift Architecture Overview](./openshift-architecture-overview.md)
- [Namespaces, Quotas and RBAC](./namespaces-quotas-rbac.md)
- [GPU Infrastructure](./gpu-infrastructure.md)
- [Resource Pricing](../resource-pricing.md)