Add node selector and tolerations options into Korifi helm chart schema

[panevpla]

Is there a related GitHub Issue?

No

What is this change about?

Adding the nodeSelector and tolerationsoptions to the Korifi helm chart schema.
This will allow the users to determine the assignment of the korifi-api and korifi-controllers pods on specific nodes.
Also, used together with taints and tolerations, certain nodes can be designated for Korifi api and controllers pods only.

Does this PR introduce a breaking change?

No.

Acceptance Steps

1. You need to have a Kubernetes cluster with at least 2 nodes.
2. Label one of the nodes with some label of your choice, e.g. role=korifi-controlplane;
3. Taint the same node with some taint of your choice, e.g. role=korifi-controlplane:NoSchedule;
4. Checkout this branch and install Korifi from it by adding the following settings to the helm install korifi command:

        --set=nodeSelector.role=korifi-controlplane \
        --set tolerations[0].key=role \
        --set tolerations[0].operator=Equal \
        --set tolerations[0].value=korifi-controlplane \
        --set tolerations[0].effect=NoSchedule

This will allow the korifi-api and korifi-controllers pods to only be scheduled on the designated node for them. Pods that don't tolerate the taint of the node will not be scheduled on it.

Tag your pair, your PM, and/or team

N/A

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: panevpla / name: Plamen Panev (c77d8ec, 3c572c5)

[danail-branekov]

The new values configure the cluster itself, I wonder whether it would make sense fo group them under a k8s section. I.e. instead of using --set nodeSelector.role=something, use --set k8s.nodeSelector.role=something

Korifi itself does not have the concept of tolerations and node selectors, so having those in the values "root" seems a bit odd to me.

[danail-branekov]

Hey @panevpla, thanks for the PR. Besides the comment I left above, you would also have to sign the CLA.

I also wonder would it make sense to have separate node selector and tolerations per api and controllers so that the api deployment could run on one node and the controllers one on another. Or would that be an overkill?

[panevpla]

Hey @panevpla, thanks for the PR. Besides the comment I left above, you would also have to sign the CLA.

I also wonder would it make sense to have separate node selector and tolerations per api and controllers so that the api deployment could run on one node and the controllers one on another. Or would that be an overkill?

That seems also reasonable. If we accept this approach, I guess we don't need the k8s group, right?
I think I have signed the CLA, at least I received a confirmation email about it.

[danail-branekov]

I guess we don't need the k8s group

My instinct first told me that we need k8sgroups, one under api and one under controllers. But then in api and controllers groups we already have k8s-specific values, replicas and resources. So puting the new k8s values directly under api and controllers would at least be consistent with them.

I think I have signed the CLA, at least I received a confirmation email about it.

Yes, the CLA check is now happy

[panevpla]

@danail-branekov as discussed, moved nodeSelector and tolerations under api and controllers groups.