-
Notifications
You must be signed in to change notification settings - Fork 984
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: Update Terraform getting started guide to default to multi-cluster tagging scheme #1668
Conversation
✅ Deploy Preview for karpenter-docs-prod ready!
To edit notification comments on pull requests, go to your Netlify site settings. |
@@ -361,11 +362,11 @@ resource "kubectl_manifest" "karpenter_provisioner" { | |||
cpu: 1000 | |||
provider: | |||
subnetSelector: | |||
karpenter.sh/discovery: ${local.cluster_name} | |||
karpenter.sh/discovery: ${module.eks.cluster_id} |
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.
local.cluster_name
and module.eks.cluster_id
are one in the same. Its better to use the module output though to ensure proper dependency ordering
Planning to test this procedure today. I'll let you know what I find. |
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 ran through these changes and am getting permissions denied errors. I'm fairly certain this is due to the tags which are set on the Subnets and Security groups when creating the EKS cluster.
Subnets and SecurityGroups have a label of karpenter.sh/discovery: <cluster_name>
, while the condition in the IRSA module is using karpenter.sh/discovery/cluster_name/<cluster_name>: <cluster_name
.
Let me take a closer look at this - I thought this would be a no-op change but looks like thats not the case |
…ter tagging scheme
private_subnet_tags = { | ||
"kubernetes.io/cluster/${local.cluster_name}" = "owned" | ||
# Tags subnets for Karpenter auto-discovery | ||
"karpenter.sh/discovery" = local.cluster_name |
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 karpenter unique tag requirement is lifted with terraform-aws-modules/terraform-aws-iam#247 - users just need to specify a subnetSelector
that will match the subnets they intend to use. VPCs and Subnets are shared resources and we shouldn't impose specific tagging on those
create_cluster_security_group = false | ||
create_node_security_group = false | ||
node_security_group_additional_rules = { | ||
ingress_nodes_karpenter_port = { |
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 has come up a bit so I thought it would be better to show the minimum additional security group rules required to run Karpenter. Hopefully this highlights to users that in addition to the minimum ports that Kubernetes/EKS requires, port 8443/TCP from the control plane to the node group is required
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.
securityGroupSelector: | ||
karpenter.sh/discovery: ${local.cluster_name} | ||
karpenter.sh/discovery/${module.eks.cluster_id}: ${module.eks.cluster_id} |
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 cluster unique key is directly related to #1488 - this allows users to have multiple clusters in a single account without tag conflicts and still maintain properly scoped permissions.
|
||
cluster_name = local.cluster_name | ||
cluster_version = "1.21" | ||
cluster_version = "1.22" |
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.
What's the ownership model of this file? How can we ensure this and L125 are up-to-date?
I can see the cluster_version being updated when the default cluster versions need to be updated, but for the TF version, do we need to specify a version if the terraform-aws-modules on L123 are referred to as latest?
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.
Same goes for L237
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.
If we can extract the HCL out of the README and put it into actual *.tf
files somewhat similar to what was done for CloudFormation where the CloudFormation is injected via the template tags, that will give us 2 things:
- Its easier to test and validate these changes because we can
cd
to the directory that holds the Terraform file and simplyterraform init && terraform apply
- Once the contents are back into Terraform files, we could enable Renovate which will track module updates and submit PRs to update Update Terraform terraform-aws-modules/iam/aws to v5 DrFaust92/terraform-kubernetes-ebs-csi-driver#78
In general though, the values are set statically to ensure that the guidance for users has been validated first. In theory, we can leave off line 128 and the underlying EKS module/service will pull the latest K8s version offered. However, this can be problematic if changes are required for supporting the latest version.
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.
Theres also this that I created re: ownership #1574 - from an outsider perspective, all I really need is one thing: the IAM policy required to run Karpenter (the most minimal, restrictive, and finely scoped IAM policy). With that I can host that policy in the IRSA role for Karpenter and then find the appropriate location to host the example usage instead of always trying to update the getting started guides here for the various ways one can provision an EKS cluster+Karpenter
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.
In general though, the values are set statically to ensure that the guidance for users has been validated first.
I agree this is definitely a good system. It's not easy to make sure it's always up to date and works, which gives value to hosting this in another repo like you've done. Was mostly curious if you had a good solution :)
node_security_group_tags = { | ||
# NOTE - if creating multiple security groups with this module, only tag the | ||
# security group that Karpenter should utilize with the following tag | ||
# (i.e. - at most, only one security group should have this tag in your account) | ||
"karpenter.sh/discovery/${local.cluster_name}" = local.cluster_name | ||
} |
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.
Can you include what the consequences of not following this note are?
node_security_group_tags = { | |
# NOTE - if creating multiple security groups with this module, only tag the | |
# security group that Karpenter should utilize with the following tag | |
# (i.e. - at most, only one security group should have this tag in your account) | |
"karpenter.sh/discovery/${local.cluster_name}" = local.cluster_name | |
} | |
node_security_group_tags = { | |
# NOTE - if creating multiple security groups with this module, only tag the | |
# security group that Karpenter should utilize with the following tag | |
# (i.e. at most, only one security group should have this tag in your account | |
# as <insert_reason_for_note>) | |
"karpenter.sh/discovery/${local.cluster_name}" = local.cluster_name | |
} |
website/content/en/preview/getting-started/getting-started-with-terraform/_index.md
Show resolved
Hide resolved
website/content/en/preview/getting-started/getting-started-with-terraform/_index.md
Outdated
Show resolved
Hide resolved
I've tested this procedure and it works as expected. @bryantbiggs I think there is one comment from @njtran which could be addressed, otherwise it looks good to me. |
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
1. Issue, if available:
#1488
2. Description of changes:
RunInstances
subnets by tag key terraform-aws-modules/terraform-aws-iam#247. Users no longer need to adhere to strict subnet tagging and instead just supply the Karpenter provision with asubnetSelector
that will match the subnets to use. Only launch template and security group are restricted by the Karpenter controller policy (and by extension, EC2 instances launched from the launch template)3. How was this change tested?
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.