adding node affinity for Fargate #792
Conversation
| - key: eks.amazonaws.com/compute-type | ||
| operator: NotIn | ||
| values: | ||
| - fargate |
There was a problem hiding this comment.
@nithu0115 is this addressing a specific problem you've run into with customers? I closed a similar issue (#755) stating that we didn't want to place EKS-specific configuration values into the CNI plugin's YAML manifests because CNI can and should run everywhere, not just EKS. Do you disagree with that?
There was a problem hiding this comment.
@jaypipes I agree up to a point, but the source of truth for customer to upgrade to latest CNI version (to 1.5.5) from default 1.5.3 version is still GitHub as per EKS public documentation.
IMO, we should have this node affinity params to provide clean upgrade experience, and should have a strategy to remove them (like introducing customer to helms charts) going forward.
There was a problem hiding this comment.
Chatted with @mogren about this some more this morning. He has convinced me that this won't do any harm, and although my objective is to keep EKS-specific items out of the VPC CNI configuration, this won't harm anyone running the VPC CNI plugin on non-EKS k8s on AWS
| - key: eks.amazonaws.com/compute-type | ||
| operator: NotIn | ||
| values: | ||
| - fargate |
There was a problem hiding this comment.
Chatted with @mogren about this some more this morning. He has convinced me that this won't do any harm, and although my objective is to keep EKS-specific items out of the VPC CNI configuration, this won't harm anyone running the VPC CNI plugin on non-EKS k8s on AWS
(cherry picked from commit 02e55fd)
(cherry picked from commit 02e55fd)
Issue #, if available: N/A
Description of changes:
Upon creating new EKS version ( 1.14 k8s version), it comes with default 1.5.3 CNI version which comes with nodeAffinity for Fargate. However, the same parameters are missing on Github.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.