Dedicated Nodes
Based on your cluster capacity you might want to segregate the pool of worker nodes available for building and running Pergola Projects. This can be achieved by "marking" a set of nodes (or a node pool) in order to reserve capacity for a specific type of workloads.
Pergola leverages the scheduling functionality of the underlying Kubernetes cluster, including via taints and tolerations, to achieve proper assignment of workloads to the desired set of nodes. In simple terms, Pergola distinguishes between two types of workloads:
- Builds, i.e. git fetch, docker build, image scans, etc.
- Runtime workloads, i.e. a Release, its Components running on a Stage
Depending on the type of workload, Pergola automatically adds following tolerations to each workload:
Builds:
tolerations:
- key: pergola.cloud/project
value: "<name of project>"
- key: pergola.cloud/build
operator: Exists
Runtime:
tolerations:
- key: pergola.cloud/project
value: "<name of project>"
- key: pergola.cloud/stage
value: "<name of stage>"
- key: pergola.cloud/stage-type
value: "<dev | qa | prod>"
- key: pergola.cloud/stage-type
value: any
By adding according taints to your nodes (or node pools) you can reserve capacity for a specific set of workloads, e.g. for:
- seperating Builds from Runtime workloads
- having a dedicated node pool for production (
stage-type=prod) workloads, with high throughput and redundancy for increased availability - having a cost-efficient node pool for development workloads, with low or no redundancy
- having a dedicated node pool for a specific Project and/or Stage
- etc.
Examples
Nodes tainted as follows:
taints:
- key: pergola.cloud/build
effect: NoSchedule
... run Build related workloads only.
taints:
- key: pergola.cloud/project
value: "my-project"
effect: NoSchedule
... run Build or Runtime workloads of Project my-project only.
taints:
- key: pergola.cloud/stage-type
value: any
effect: NoSchedule
... run Runtime workloads only, any Stage, any Project, no Builds.
taints:
- key: pergola.cloud/project
value: "my-project"
effect: NoSchedule
- key: pergola.cloud/stage-type
value: any
effect: NoSchedule
... run Runtime workloads of Project my-project only, any Stage.
taints:
- key: pergola.cloud/project
value: "my-project"
effect: NoSchedule
- key: pergola.cloud/stage
value: "emea"
effect: NoSchedule
... run Runtime workloads of Project my-project on Stage emea only.
taints:
- key: pergola.cloud/stage-type
value: "prod"
effect: NoSchedule
... run production workloads only, any Project, no Builds.
Adding taints to existing nodes, as described above with effect: NoSchedule, has no impact on workloads already running, but prevents new workloads from being scheduled if they do not tolerate the taints.
You can also use effect: NoExecute instead which is more intrusive as it also evicts workloads already running which do not tolerate the taints just added.
If you do not add taints to any of your nodes at all, the above tolerations do not affect scheduling. In fact, workloads will run on any available node, as long as its capacity (e.g., CPU, memory) can accommodate and infrastructure-related constraints (e.g., region, zone) are satisfied.
Make sure that you have at least one set of nodes (recommended 3 or more) without any additional taints, except those automatically added by your Kubernetes provider. Otherwise system and other custom workloads might not be able to run on your cluster and can impact the overall cluster functionality and availability.