Description:
We have a use case where we need to ensure that the pods created by the Job defined in the Helm chart only run on amd64 architecture nodes. However, the current Helm template does not pass nodeSelector or nodeAffinity settings to the Job specification. This limitation makes it impossible to restrict the Job’s pods to specific node types, which is a requirement in environments with heterogeneous node architectures (e.g., clusters with both amd64 and arm nodes).
Proposed Solution:
Please add support for nodeSelector and nodeAffinity in the Job specification. This can be done by allowing these fields to be configurable via values.yaml and then passing them to the Job’s pod template spec.
Impact:
Without this capability, users in mixed-architecture clusters are at risk of having their Jobs scheduled on incompatible nodes, leading to failures. This change would allow for more flexible and robust deployments across diverse Kubernetes environments.
Workaround:
Currently, the lack of support for nodeSelector or nodeAffinity forces users to consider complex workarounds, such as setting up a custom Mutating Admission Webhook, which is over-engineered for this purpose and adds unnecessary operational complexity.
Request:
Please consider implementing this enhancement to make the Helm chart more versatile and applicable to a broader range of Kubernetes environments.
Description: We have a use case where we need to ensure that the pods created by the Job defined in the Helm chart only run on
amd64
architecture nodes. However, the current Helm template does not passnodeSelector
ornodeAffinity
settings to the Job specification. This limitation makes it impossible to restrict the Job’s pods to specific node types, which is a requirement in environments with heterogeneous node architectures (e.g., clusters with bothamd64
andarm
nodes).Proposed Solution: Please add support for
nodeSelector
andnodeAffinity
in the Job specification. This can be done by allowing these fields to be configurable viavalues.yaml
and then passing them to the Job’s pod template spec.Example configuration in
values.yaml
:These values should then be injected into the Job’s pod spec like this:
Impact: Without this capability, users in mixed-architecture clusters are at risk of having their Jobs scheduled on incompatible nodes, leading to failures. This change would allow for more flexible and robust deployments across diverse Kubernetes environments.
Workaround: Currently, the lack of support for
nodeSelector
ornodeAffinity
forces users to consider complex workarounds, such as setting up a custom Mutating Admission Webhook, which is over-engineered for this purpose and adds unnecessary operational complexity.Request: Please consider implementing this enhancement to make the Helm chart more versatile and applicable to a broader range of Kubernetes environments.