Chart option to disable default toleration of all taints

[risinger]

Is this a bug fix or adding new feature?
bug fix
What is this PR about? / Why do we need it?
I would like to use a taint to prevent EBS CSI Driver components from running on a node. In the helm chart, the Controller Service and Node Service currently tolerate all taints. I believe this was introduced by mistake during a merge, since neither of the parents include the removal of the key in 0c243cd.

[k8s-ci-robot]

Welcome @risinger!

It looks like this is your first PR to kubernetes-sigs/aws-ebs-csi-driver 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes-sigs/aws-ebs-csi-driver has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

[k8s-ci-robot]

Hi @risinger. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[coveralls]

Pull Request Test Coverage Report for Build 1274

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 81.253%

---

Totals
Change from base Build 1269:	0.0%
Covered Lines:	1595
Relevant Lines:	1963

---

💛 - Coveralls

[risinger]

/kind bug

[leakingtapan]

See: kubernetes-sigs/aws-efs-csi-driver#122 and #441 for the reason why it was removed originally

[leakingtapan]

I would like to use a taint to prevent EBS CSI Driver components from running on a node.

What's ur use case for this?

[risinger]

Thanks for the links. What's the point of .Values.tolerations and .Values.node.tolerations if all taints are tolerated by default, and the user is unable to disable that without using kustomize? I would personally prefer (and expect) to manually specify any tolerations on services in my cluster than have them automatically tolerate all taints. To me at least, it's a logical requirement that pods I want to run on tainted nodes will need to tolerate that taint.

My current use case: I'm running a cluster with both public and private nodes. I want to specify exactly which pods are allowed to run on the public nodes to limit exposed attack surface. No pods running on the public nodes require persistent storage so I do not want the CSI Node Service or the CSI Controller Service to run on those public nodes.

If you or others feel strongly that tolerating all taints should be the default, I could work with a toggle for it instead.

[wongma7]

i am inclined to agree with @risinger, seems a bit heavy handed to default tolerate all taints. more control should be given to the admin to decide whether a pod runs on a given node or not. If they anticipate a node will need to run stateful pods then the onus is on them to ensure ebs pod is colocated there

/ok-to-test

[wongma7]

with that said, tolerating all taints is the 'backwards compatible' way since in the non-csi world, the in-tree aws ebs plugin will be ready in kubelet whether you want it or not.

[risinger]

I updated the default behavior to maintain backward compatibility.
Please let me know if there is something else you'd like to see before merge @leakingtapan @wongma7

[leakingtapan]

/lgtm
/approve

[leakingtapan]

Fixes: #591

[risinger]

/retest

[risinger]

Initial 2 failures look like the same io2 flake on #593
Seems like this is the most relevant ticket #545. Happy to create a more specific issue on request.

After merging master, there's a critical failure almost immediately. Not sure if flake or what. I'll give it one more shot.

/retest

[wongma7]

/test pull-aws-ebs-csi-driver-e2e-single-az

[risinger]

Thanks @wongma7.
The merge from master wiped the approval. Can I get another /lgtm?

[krmichel]

@leakingtapan This is clean now but your lgtm got removed when master got merged in

[leakingtapan]

/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: leakingtapan, risinger

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [leakingtapan]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment