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

add arch, os, and provisioner anti-affinities for the karpenter deployment #468

Merged
merged 3 commits into from
Jun 23, 2021

Conversation

bwagner5
Copy link
Contributor

Issue #, if available:
N/A

Description of changes:
There are a few ways that karpenter pods can get scheduled on bad compute nodes:

  1. Karpenter pods can be scheduled to nodes that were provisioned by karpenter which is not a good idea
  2. Karpenter pods can be scheduled to Windows nodes which we do not publish a docker image for yet
  3. Karpenter pods can be scheduled to arm64 nodes which we do not publish an image for yet

This PR adds a default anti-affinity for the karpenter provisioner name label (provisioner.karpenter.sh/name) and affinity to linux and amd64 nodes.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

@bwagner5 bwagner5 requested a review from ellistarn June 22, 2021 15:28
@JacobGabrielson JacobGabrielson self-requested a review June 22, 2021 15:42
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't actually think we want this. Imagine if someone wants to run karpenter in a management cluster, who's nodes are themselves managed by a separate karpenter installation.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Interesting, I hadn't considered the case of a management cluster using karpenter... But a karpenter installation should never be hosted on a node provisioned by the installation, right? I can remove this one since it's not super important for people trying it out right now, only slightly annoying when developing.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I went ahead and removed this one.

- key: kubernetes.io/arch
operator: In
values:
- amd64
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't we currently build arm images w/ ko?

Copy link
Contributor Author

@bwagner5 bwagner5 Jun 22, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The makefile has the flag to generate for all platforms, but I only see the amd64 one in the public registry.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It might be that ecr public just doesn't show the other arch ones ... the manifest appears to have the hashes listed, let me do some digging real quick.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tested on an arm64 instance and it does appear to pull down an arm64 variant, so I removed the arch affinity.

- key: kubernetes.io/os
operator: In
values:
- linux
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1

@ellistarn ellistarn merged commit 72dfd56 into aws:main Jun 23, 2021
gfcroft pushed a commit to gfcroft/karpenter-provider-aws that referenced this pull request Nov 25, 2023
Signed-off-by: dependabot[bot] <[email protected]>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants