kubernetesSubstrates
A pool substrate is the managed Kubernetes cluster behind a pool whose policy has a `substrate` (`kind: 'kubernetes'`, an `account`, and `cluster: { create }` or `cluster: { adopt }`). The `kubernetes.substrates` reconciler records it here: it creates the cluster with one node pool per flavor (or adopts an existing cluster and adds the flavors' node pools to it, named `bc-<pool>-<flavor>` so they never collide with the tenant's own pools), server-side applies bcd's DaemonSet with a hosted join token, and the cluster's Nodes join the pool. Every object it applies carries the label `better-compute.dev/substrate-pool=<pool id>`; on an adopted cluster an object of the same name it did not create is never taken over or deleted. There is nothing to call to create or delete a substrate: change the pool's policy, or archive the pool to tear it down.
A pool substrate is the managed Kubernetes cluster behind a pool whose policy has a substrate (kind: 'kubernetes', an account, and cluster: { create } or cluster: { adopt }). The kubernetes.substrates reconciler records it here: it creates the cluster with one node pool per flavor (or adopts an existing cluster and adds the flavors' node pools to it, named bc-<pool>-<flavor> so they never collide with the tenant's own pools), server-side applies bcd's DaemonSet with a hosted join token, and the cluster's Nodes join the pool. Every object it applies carries the label better-compute.dev/substrate-pool=<pool id>; on an adopted cluster an object of the same name it did not create is never taken over or deleted. There is nothing to call to create or delete a substrate: change the pool's policy, or archive the pool to tear it down.
All 1 methods are served by @better-compute/server 0.3.0.
| Method | Kind | Authorization | Phase | Status |
|---|---|---|---|---|
get | read | compute:kubernetes:read @ compute-tenant | v1.0 | registered |
get
POST /api/compute/kubernetesSubstrates/get
Returns the pool's substrate: poolId, tenantId, providerAccountId, mode (create or adopt), the clusterId of its kubernetesClusters row once recorded, state (pending, provisioning, ready, updating, error, deleting, deleted) with a message when there is something to fix or wait for, nodesListed and nodesJoined (the substrate's Nodes the cluster last listed, and of them the ones whose bcd joined the pool), waitingToJoin ({ nodes, since }: how many listed Nodes have no joined bcd, and since when none has joined; after 15 minutes the message says what to check, while the state stays ready), and upgrade ({ version, since }) while an upgrades: 'drain' upgrade waits for bookings to end. It never returns the join token, its id or a credential. A pool without a substrate is NOT_FOUND. Decided as compute:kubernetes:read on the pool owner's tenant.
- Kind: read
- Authorization:
compute:kubernetes:read@compute-tenant - Module:
kubernetes - Phase: v1.0 (registered)
Input
| Field | Type | Required | Constraints |
|---|---|---|---|
tenantId | string | yes | at most 128 characters; matches ^[A-Za-z0-9._:-]{1,128}$ |
poolId | string | yes | at most 57 characters; matches ^pool_[0-9a-hjkmnp-tv-z]{26,52}$ |
Better Compute is created by Sean Filimon
Last updated
kubernetesNodePools
Node pools are the groups of worker nodes of a `standard` Kubernetes cluster ([kubernetesClusters](/docs/reference/api/kubernetes-clusters)); an `autopilot` cluster has none, because the provider runs its nodes. A cluster's first node pools are created with it; these calls add, resize and remove pools later. Every call records what the tenant wants and returns at once: the node pool shows `pending`, `ready`, `updating`, `deleting`, `deleted` or `error` (with a `message`), and its cluster goes `updating` until the reconciler has converged the change, then `ready` again. A node pool the provider refuses is `error`, and so is its cluster, with the pool named in its `message`, until the pool is changed or deleted. The reconciler publishes `kubernetes.nodepool.ready`, `kubernetes.nodepool.error` and `kubernetes.nodepool.deleted` on the cluster's subject. A node pool's name is also its provider-side name.
loadBalancers
Load balancers on a provider account (DigitalOcean regional and global first). Every call records what the tenant wants and returns at once; the `vps.provider-resources` reconciler converges the provider through `ProviderImpl.loadBalancers`. Reading takes `compute:load-balancers:read`, everything else `compute:load-balancers:manage`, on `provider-load-balancer/{id}`. A load balancer books one `loadBalancers` quota on the pool (no quota row grants none) and bills `vps.load-balancer.hours` from `ready` until deleted.