Node placeholders - 2i2c Infrastructure Guide

Earlier, we saw that user placeholders do not scale above a single node. This is due to poor scheduling behaviour with respect to the pod disruption.

An alternative approach to reserving capacity on a hub is to use node placeholders. These differ in important ways:

User placeholders: Ensure that there is new capacity for $N$ users.
Node placeholders: Ensure that there is total capacity for $M$ nodes.

Node placeholders enable us to ensure that the cluster has $M$ nodes running. However, these are not new nodes — node placeholders ensure that there are $M$ total nodes running in the cluster. If existing users are on the hub, then there will already be several user nodes running and contributing to the total $M$ .

Add Helm configuration¶

Node placeholders are implemented as a Kubernetes deployment. Each pod is configured with tiny resource requests, and schedules on a dedicated node (that may already exist).

nodePlaceholder:
  enabled: true
  nodeSelector:
    node.kubernetes.io/instance-type: n2-highmem-4
    # Disable the hub selector
    # 2i2c/hub-name:

  # Control number of nodes required to run
  # Reserves baseline capacity, not surge capacity
  replicas: 0

The number of replicas governs how many nodes are required to be running that match the node selector.

Once nodes have started, you may wish to enable image pulling to ensure that the images required by users are available. See Enable continuous-image-puller for details.

Controlling replicas from CI¶

In GitHub Actions, we have a workflow for scaling the placeholders of a hub with the appropriate placeholder configuration. The Run workflow button can be used to trigger a CI-driven change to the placeholders of the cluster.