Support for Specifying Custom Node Taints via Machine Configuration

[melbruki]

Description:

In the current implementation of Talos, there is no native support for specifying custom node taints directly through the machine configuration. While control plane nodes are automatically tainted, other nodes lack this configurability.

Problem Statement:

Node taints are a critical part of Kubernetes cluster management, enabling operators to control which nodes specific pods can be scheduled on. The lack of support for custom taints within Talos's machine configuration makes it difficult to manage taints at scale and can lead to inefficiencies and inconsistencies across the cluster.

Current Workaround:

At present, custom taints can be applied using the kubectl command after the node is installed. While this method does provide a way to apply taints, it introduces extra manual steps and can lead to inconsistencies in the configuration of nodes within a cluster. Automating this process within Talos would greatly streamline cluster configuration, ensuring that taints are applied uniformly and without requiring individual manual intervention.

Proposed Solution:

Introduce native support in Talos for specifying custom node taints within the machine configuration. This would allow taints to be defined as part of the machine's initial setup, ensuring a consistent configuration across all nodes in the cluster. The solution would provide cluster administrators with a more efficient and robust way to manage node taints, aligning with common Kubernetes best practices.

[james-callahan]

It looks like you can currently do it via passing registerWithTaints in the kubelet extraConfig?

[frezbo]

It looks like you can currently do it via passing registerWithTaints in the kubelet extraConfig?

not entirely, kubelet has restrictions on what can be passed

[camaeel]

IMHO the only limitation for registerWithTaints is that you can pass those only on first startup of this node. If the node is created in cluster, then those taints can't be changed this way anymore.
Limitations are on labels that can be set by kubelet itself, but this is different use case.

[smira]

yes, the limitation is that they are not reconciled properly, you can't remove/add later. this doesn't work like a spec