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

feat: Refactor Helm chart #1145

Merged
merged 4 commits into from
Feb 9, 2022
Merged

Conversation

stevehipwell
Copy link
Contributor

1. Issue, if available:
This PR addresses part of #781.

2. Description of changes:

This is a breaking change.

  • Improve chart metadata
  • Make chart follow idiomatic Helm patterns
  • Use K8s recommended labelling to distinguish between components and improve selector logic
  • Use a different ServiceAccount for controller and webhook, this is more secure
  • Recommend creating service accounts rather than using the namespace default, this is more secure

3. How was this change tested?

The template output was compared to the pervious version.

4. Does this change impact docs?

  • Yes, PR includes docs updates
  • Yes, issue opened: link to issue
  • No

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

@netlify
Copy link

netlify bot commented Jan 14, 2022

✔️ 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

@stevehipwell
Copy link
Contributor Author

@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.

charts/karpenter/Chart.yaml Outdated Show resolved Hide resolved
@stevehipwell
Copy link
Contributor Author

@ellistarn have you had a chance to review this yet?

@bwagner5 bwagner5 self-requested a review January 20, 2022 19:12
@bwagner5
Copy link
Contributor

I'll take a look at this today @stevehipwell ! Looks familiar ;)

Copy link
Contributor

@bwagner5 bwagner5 left a 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 \
Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Contributor Author

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.

Copy link
Contributor

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):

Copy link
Contributor Author

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.

Copy link
Contributor Author

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?

Copy link
Contributor

@bwagner5 bwagner5 Feb 4, 2022

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.

Copy link
Contributor Author

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.

@ellistarn
Copy link
Contributor

@stevehipwell stevehipwell force-pushed the refactor-helmp-chart branch 3 times, most recently from f30e5f6 to c46f599 Compare February 1, 2022 12:13
@@ -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 \
Copy link
Contributor

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 \
Copy link
Contributor

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.

charts/karpenter/templates/controller/serviceaccount.yaml Outdated Show resolved Hide resolved
@stevehipwell stevehipwell force-pushed the refactor-helmp-chart branch 2 times, most recently from af2aa1a to 0e12bb4 Compare February 4, 2022 12:41
@stevehipwell stevehipwell force-pushed the refactor-helmp-chart branch 4 times, most recently from 30103c0 to 7ef9e4b Compare February 7, 2022 16:57
Copy link
Contributor

@bwagner5 bwagner5 left a 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

website/content/en/preview/getting-started/_index.md Outdated Show resolved Hide resolved
@stevehipwell stevehipwell force-pushed the refactor-helmp-chart branch 2 times, most recently from 2f5990b to d68e66a Compare February 8, 2022 09:07
Signed-off-by: Steve Hipwell <[email protected]>
@stevehipwell
Copy link
Contributor Author

@bwagner5 thanks for the review, I've fixed the typo you found. Hopefully this can be merged soon.

@stevehipwell
Copy link
Contributor Author

@bwagner5 the CI is failing but I don't think it's related to any changes I made?

@bwagner5
Copy link
Contributor

bwagner5 commented Feb 8, 2022

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!

@stevehipwell
Copy link
Contributor Author

@bwagner5 thanks for the review and the PR.

@mbevc1
Copy link
Contributor

mbevc1 commented Feb 9, 2022

Nice work and also glad to see consolidating Pod too 👍

@stevehipwell
Copy link
Contributor Author

@bwagner5 all merged and in this PR.

Copy link
Contributor

@bwagner5 bwagner5 left a comment

Choose a reason for hiding this comment

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

LGTM! Thanks!!

@bwagner5 bwagner5 merged commit 7e95b62 into aws:main Feb 9, 2022
@stevehipwell stevehipwell deleted the refactor-helmp-chart branch February 9, 2022 17:32
@spring1843 spring1843 mentioned this pull request Feb 9, 2022
3 tasks
bwagner5 pushed a commit that referenced this pull request Feb 9, 2022
bwagner5 pushed a commit that referenced this pull request Feb 9, 2022
@Skarlso
Copy link

Skarlso commented Feb 16, 2022

In the future please note that refactors like these break eksctl's Karpenter installation flow. A heads up would have been nice.

@stevehipwell
Copy link
Contributor Author

@Skarlso I'm not a maintainer just a contributor. That said I was expecting this to go out as v0.7.0 to clearly show that it was a breaking change, but as per SemVer 2.0 all pre v1 versions are considered breaking.

@metanerd
Copy link

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

@stevehipwell
Copy link
Contributor Author

@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.

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.

6 participants