Taints and Tolerations
If users want to create nodes with large storage spaces and/or CPU resources for Longhorn only (to store replica data) and reject other general workloads, they can taint those nodes and add tolerations for Longhorn components. Then Longhorn can be deployed on those nodes.
Notice that the taint tolerations setting for one workload will not prevent it from being scheduled to the nodes that don’t contain the corresponding taints. See Kubernetes’s taint and toleration for details.
Follow the instructions to set init taint tolerations: Customize default settings
The taint toleration setting can be found at Longhorn UI:
Setting -> General -> Kubernetes Taint Toleration
Users can modify the existing tolerations or add more tolerations here, but noted that it will result in all the Longhorn system components to be recreated.
Before modifying the toleration setting, users should make sure all Longhorn volumes are
detached. Since all Longhorn components will be restarted then the Longhorn system is unavailable temporarily. If there are running Longhorn volumes in the system, this means the Longhorn system cannot restart its components and the request will be rejected.
During the Longhorn system updates toleration setting and restarts its components, users shouldn’t operate the Longhorn system.
When users set tolerations, the substring
kubernetes.io shouldn’t be contained in the setting. It is used and considered as the key of Kubernetes default tolerations.
Multiple tolerations can be set here, and these tolerations are separated by the semicolon. For example:
Available since v0.6.0