Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support node taints in cluster config #189

Closed
9 of 13 tasks
jiayiwang7 opened this issue Sep 13, 2021 · 2 comments
Closed
9 of 13 tasks

Support node taints in cluster config #189

jiayiwang7 opened this issue Sep 13, 2021 · 2 comments

Comments

@jiayiwang7
Copy link
Member

jiayiwang7 commented Sep 13, 2021

What would you like to be added:

Add node taints option in cluster config for both control plane and worker node groups. So that the defined taints can be attached to the node(s) automatically during cluster creation/upgrade.

cluster config

We add taints option at the cluster level, eg:

apiVersion: anywhere.eks.amazonaws.com/v1alpha1
kind: Cluster
metadata:
  name: cluster-1
spec:
  ...
  controlPlaneConfiguration:
    count: 2
    endpoint:
      host: "198.18.100.27"
    machineGroupRef:
      kind: VSphereMachineConfig
      name: cluster-1-cp
    taints: # optional
    - key: key1
      value: val1 # optional
      effect: NoSchedule # Valid effects are NoSchedule, PreferNoSchedule and NoExecute.
  workerNodeGroupConfigurations:
  - count: 2
    machineGroupRef:
      kind: VSphereMachineConfig
      name: cluster-1
    taints: # optional
    - key: key2
      value: val2 # optional
      effect: PreferNoSchedule # Valid effects are NoSchedule, PreferNoSchedule and NoExecute.

implementation

Cluster API already supports taints for both control plane and machine deployment:

We might easily pass down the taints option to the CAPI spec before applying.

The CAPI taints option does not work for worker nodes (kubeadmconfigtemplates). We https://github.com/kubernetes-sigs/cluster-api/blob/main/controlplane/kubeadm/controllers/controller.go#L267might add taints for worker nodes in the CLI workflow, or as a postKubeadmCommands defined in the kubeadmconfigtemplates.

Why is this needed:

User requests to allow the retention of node taints during an upgrade. Currently the rolling update recreates VMs and the new nodes joined do not have the taints defined in the original nodes. User needs to manually attach those taints back after upgrade.

We'd like to provide a descriptive way to let user define node taints in the cluster config, so that the nodes being created/upgraded can have the proper taints (if defined) on the node(s) automatically without manual setup.

TODO list

TBD:

  • support worker nodes taints update without VM recreate
@jiayiwang7 jiayiwang7 changed the title Include node taints in cluster config Support node taints in cluster config Sep 13, 2021
@jaxesn jaxesn added this to the next milestone Sep 13, 2021
@mitalipaygude mitalipaygude modified the milestones: next, next+1 Oct 28, 2021
@jaxesn jaxesn modified the milestones: next+1, next Nov 8, 2021
@danbudris danbudris mentioned this issue Jan 18, 2022
1 task
@danbudris danbudris modified the milestones: next, next+1, next-patch Jan 26, 2022
@jaxesn jaxesn modified the milestones: next-patch, next+1 Jan 26, 2022
@jaxesn jaxesn modified the milestones: next+1, next Feb 1, 2022
@danbudris
Copy link
Member

danbudris commented Feb 4, 2022

an update on this issue:

In order to provide controller support for taints, we'll need to add a mechanism by which we generate new kubeadmconfigtemplates with an update joinConfiguration containing the requisite taints, and then modify the machineDeployemnts which reference those kubeadmconfigtemplates to reference the new kubeadmconfigtemplate; this way we can trigger a rollout of the machinedeployments, causing new machines to be launched, and the updated joinConfiguration in the kubeadmconfigtemplate to go into effect. This will also address SSH key rolling.

As of right now, upstream intentionally does not support 'immutable' kubeadmconfigtemplates, but the official guidance is to treat them in the same way we treat the immutable machineTemplates -- e.g. create a new one with the updates, modify the machineDeployment to use it, trigger rollout & node recreation.

See:

@danbudris
Copy link
Member

this feature is released in 0.7.1

@jaxesn jaxesn removed this from the next milestone May 13, 2022
testerIbix pushed a commit to testerIbix/eks-anywhere that referenced this issue Aug 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants