Resource Management
On this page
Oakestra’s resources are managed by the Resource Abstractor. An instance of this component is deployed at the root orchestator and at each cluster orchestrator.
The resource abstractor exposes a REST API by which resource availability statistics can be delivered, and available resources queried. The data is stored in a mongo database. The resource abstractor stores information on the available resources reported by the cluster and nodes, and on the statuses of services and their instances.
Did you know?
Since the Conga release, Oakestra utilises the resource abstractor at the root and cluster.
Canonical Resources
Oakestra differentiates between canonical and non-canonical resources.
| Canonical Resources | Non-canonical Resources |
|---|---|
| Worker and cluster are assumed to have (e.g. vCPUs, Memory) | Supplementary resources (e.g. electricity price, TPUs) |
| Static aggregation scheme | Automated aggregation scheme |
| Always collected by resource abstractor | Always collected by resource abstractor |
| Always served by resource abstractor | Only served when explicitly requested |
Resource Aggregation
The cluster orchestrator aggregates resources from its worker nodes and abstracts the cluster’s internal composition to the root orchestrator. Canonical and non-canonical resources are aggregated in the following ways:
- Canonical Resources: A static, hard-coded aggregation scheme is used for each resource type. E.g. vCPUs are summed up, for memory usage the average is calculated, and the available runtimes are appended to a list.
- Non-canonical Resources: Since the cluster orchestrator has no prior knowledge on the resource types a worker might report, it falls back on the following schema based on the resource value type:
- Number: Summate
- String: Append to list
- List: Flatten to list
Aside from scheduling, the resource abstractor enables the Addons system for the root and cluster orchestrator. Read more on extending Oakestra here.
