-
Notifications
You must be signed in to change notification settings - Fork 983
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
feat: Refactor Helm chart #1145
Conversation
✔️ Deploy Preview for karpenter-docs-prod ready! 🔨 Explore the source changes: 24f2876 🔍 Inspect the deploy log: https://app.netlify.com/sites/karpenter-docs-prod/deploys/6203f7d61e7bed00079be390 😎 Browse the preview: https://deploy-preview-1145--karpenter-docs-prod.netlify.app |
@ellistarn sorry it took me so long to come through on this one, but with the holidays and the chart refactor I did for NTH taking longer than expected I've got quite a backlog of pending OSS commitments. I'm about to go through the issues and comment on the ones that this PR is related to. |
a5f2e17
to
0258fd4
Compare
@ellistarn have you had a chance to review this yet? |
I'll take a look at this today @stevehipwell ! Looks familiar ;) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I haven't quite finished reviewing all the files, but had a question on the serviceAccount
@@ -71,7 +71,6 @@ apply: ## Deploy the controller into your ~/.kube/config cluster | |||
delete: ## Delete the controller from your ~/.kube/config cluster | |||
helm template karpenter charts/karpenter --namespace karpenter \ | |||
$(HELM_OPTS) \ | |||
--set serviceAccount.create=false \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this was set to prevent the service account annotated for IRSA to be deleted in the dev workflow.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't the annotation be passed in with --set
flag? Otherwise you're using the namespace default Service Account and giving it all the access. I guess for development it doesn't really matter, but this pattern was also copied everywhere as is often the case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We thought users would be using the getting started guide eksctl command to create the IAM Role for Service Accounts, which creates the service account and annotates with the role arn (https://karpenter.sh/v0.5.5/getting-started/#create-the-karpentercontroller-iam-role). That might be a bad assumption for production installs, I'm not sure. But for dev installs, it's probably accurate and so leaving the --set serviceAccount.controller.create=false
seems like the best dev workflow experience to me. Otherwise, we'd need some way of persisting the role arn in an env var or something and then using a set to annotate every time we make apply
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That guide really needs re-writing to promote better practice, although from memory one of the other tabs has a better way of creating the roles and getting the ARN back? It's idiomatic for a Helm chart to create it's own service account(s), so I'd suggest documenting the externally created one, but with a name specified so it's not the default namespace one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For the dev workflow, once the role has been created it persists outside of the K8s resources. It'd be simplest to set it in the env.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The docs that need updating are here (I think that's all of the places):
- https://karpenter.sh/v0.6.0/getting-started/#install-karpenter-helm-chart (may want to move the helm install docs above the spot service linked role docs since we need to pass thru the annotation now. Probably want to add
--role-only
to the eksctl cmd to prevent creating the service account too) - https://karpenter.sh/v0.6.0/getting-started-with-terraform/#install-karpenter-helm-chart
- https://karpenter.sh/v0.6.0/development-guide/#environment-specific-setup
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bwagner5 shouldn't we be waiting until there is a release to make the changes to the docs for that release? The v0.6.0
chart has already been released so I don't think the docs shouldn't change for that version? This is one of the problems of directly linking your chart releases to your package releases.
While I wait for a response I'll update the non-docs references and undo the change to docs I accidentally made previously.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bwagner5 @ellistarn how do the docs get updated for a release?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All docs before a release go in the preview directory https://github.com/aws/karpenter/tree/main/website/content/en/preview
When we cut a release, the preview directory is copied to the version we are releasing, so it's fine to make the doc updates to preview in this PR. We shouldn't ever modify a specific version docs outside of a release or a bug fix in the docs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These should be updated now.
f30e5f6
to
c46f599
Compare
@@ -142,7 +142,7 @@ eksctl. Thus, we don't need the helm chart to do that. | |||
helm repo add karpenter https://charts.karpenter.sh | |||
helm repo update | |||
helm upgrade --install karpenter karpenter/karpenter --namespace karpenter \ | |||
--create-namespace --set serviceAccount.create=false --version v0.5.5 \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IIUC this should include the IRSA annotations if we remove this, or else it will override the service account created above with eksctl?
@@ -71,7 +71,6 @@ apply: ## Deploy the controller into your ~/.kube/config cluster | |||
delete: ## Delete the controller from your ~/.kube/config cluster | |||
helm template karpenter charts/karpenter --namespace karpenter \ | |||
$(HELM_OPTS) \ | |||
--set serviceAccount.create=false \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The instance profile shouldn't make a difference since it's for the nodes that karpenter provisions and not the karpenter controller instance role.
af2aa1a
to
0e12bb4
Compare
30103c0
to
7ef9e4b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice! Just one comment on a mistyped command in the docs
2f5990b
to
d68e66a
Compare
Signed-off-by: Steve Hipwell <[email protected]>
d68e66a
to
2d5656d
Compare
@bwagner5 thanks for the review, I've fixed the typo you found. Hopefully this can be merged soon. |
@bwagner5 the CI is failing but I don't think it's related to any changes I made? |
I pulled this down and did some manual testing. I posted a PR to your fork with a few changes: stevehipwell#1 We're very near a merge! I love the single karpenter pod! |
@bwagner5 thanks for the review and the PR. |
Nice work and also glad to see consolidating Pod too 👍 |
@bwagner5 all merged and in this PR. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! Thanks!!
In the future please note that refactors like these break |
@Skarlso I'm not a maintainer just a contributor. That said I was expecting this to go out as |
Hi! I just want to mention that this refactor also broke the values for this aws sample: https://github.com/aws-samples/karpenter-terraform/blob/main/karpenter/templates/values.yaml.tpl |
@metanerd I'm just a contributor so just my opinion, but all samples SHOULD use fixed versions and all samples MUST fix the version of any pre v1.0.0 components. |
1. Issue, if available:
This PR addresses part of #781.
2. Description of changes:
This is a breaking change.
3. How was this change tested?
The template output was compared to the pervious version.
4. Does this change impact docs?
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.