-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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: Add karpenter on fargate example #1187
Conversation
examples/karpenter-fargate/README.md
Outdated
- AWS EKS Fargate Profiles for the `kube-system` namespace with Pod Labels used by the `coredns`, `karpenter`, and `aws-load-balancer-controller` addons, while additional profiles can be added as needed. | ||
- AWS EKS managed addons `vpc-cni` and `kube-proxy`. | ||
- Karpenter Helm Chart. | ||
- AWS Node Termination Handler Helm Chart. Karpenter does not handle the Spot Interruption Termination Notice (ITN) two-minute warning. In lieu of this, you can install AWS Node Termination Handler to gracefully cordon and drain your spot nodes when they are interrupted. Pods that require checkpointing or other forms of graceful draining, requiring the 2-mins before shutdown, will need NTH. |
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.
it does now in v0.19
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.
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 expect to have the PR ready in a couple of days, so feel free to go ahead
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 see two options while we wait for the blueprint changes for Karpenter 0.19.0.
- We specify that prior to v0.19.0, Karpenter requires NTH to handle the Spot ITN
- We remove NTH from this example since it's not using Spot for the sample app
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.
Since Karpenter 0.20.0 is now available in the blueprints I removed NTH and configured Karpenter to use a SQS Interruption Queue.
examples/karpenter-fargate/README.md
Outdated
@@ -0,0 +1,210 @@ | |||
# EKS Cluster with Karpenter Cluster Autoscaler running on Fargate |
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 should start with https://github.com/aws-ia/terraform-aws-eks-blueprints/blob/main/examples/fargate-serverless as the baseline for this example and update to show the relevant aspects that we are trying to highlight that are different
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.
"Cluster Autoscaler" is not something the official docs mention.
plus is not about the cluster, but about the worker nodes
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 reused what's in https://github.com/aws-ia/terraform-aws-eks-blueprints/blob/main/examples/karpenter/README.md?plain=1#L1.
I will update the README.md
file following @bryantbiggs recommendation.
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've updated the readme, but I don't think I can reuse much of what's in https://github.com/aws-ia/terraform-aws-eks-blueprints/blob/main/examples/fargate-serverless after all. It is not the same use case since we have EC2 compute that can be provided by Karpenter in this example. In this example, addons are placed on Fargate for another reason. I explained the reasons why I'm putting the addons on Fargate in #1187 (comment).
examples/karpenter-fargate/main.tf
Outdated
# We filter the kube-system pods with labels since not all add-ons can run on Fargate (e.g. aws-node-termination-handler) | ||
fargate_profiles = { | ||
# Providing compute for the kube-system namespace where addons that can run on Fargate reside | ||
coredns = { |
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.
since karpenter does not depend on coredns, it seems best to have it running on karpenter nodes than the lead time to create and maintain more fargate profiles, roles, etc
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 this example, I decided to put the coredns and also the aws-load-balancer-controller add-ons on Fargate. Not because Karpenter depends on them, but because I think Fargate might be a better choice to run these add-ons since they don't need specific hardware support or a particular instance type. For these reasons, my guiding principle was to put addons on Fargate unless they were not compatible with it, like NTH.
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 just found that creating and destroying multiple fargate profiles to take far too long, since they are done in serial rather than parallel, and karpenter nodes are faster than that.
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 created this example while thinking about how AWS customers could use it in the real world. I don't think the time it takes to create and destroy the resources provided by this example should be taken into consideration.
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.
@FernandoMiguel have you tried profile wildcards to work the problem?
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 remove NTH or deploy in another namespace we could use only one Fargate profile for kube-system pods and wildcards would not be required. I created multiple profiles for kube-system since the NTH namespace is hardcoded to kube-system
in https://github.com/aws-ia/terraform-aws-eks-blueprints/blob/main/modules/kubernetes-addons/aws-node-termination-handler/locals.tf#L2 and I didn't want to change that in this PR. Since NTH cannot run on Fargate (it needs to access IMDS) and since it will not be required with Karpenter v.0.19.0, we could just remove it from that PR as I proposed in #1187 (comment).
I also think the question we need to answer for this example is do we want to run the add-ons other than Karpenter on Fargate or not. Because other add-ons that run inside the kube-system might not be compatible with Fargate and we would still need a solution to not schedule them on Fargate nodes. Another thing to consider is that Fargate profile wildcards do not offer much flexibility when selecting which pods can be placed on a Fargate profile for one namespace and when they have different labels. I tried it and did not find any good pattern that could allow filtering out NTH pods from the kube-system Fargate profile.
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.
@askulkarni2 those were not a thing when i tried. havent tried since
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.
Since Karpenter 0.20.0 is now available in the blueprints I removed NTH and this example now uses only two Fargate profiles.
…blueprints into karpenter-fargate
@@ -0,0 +1,71 @@ | |||
apiVersion: apps/v1 |
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 we use the existing app instead?
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 thought about using it at first, but finally decided to use a deployment with nodeSelector
, topologySpreadConstraints
, and podAntiAffinity
to demonstrate how Karpenter handles these types of constraints. I explain it in the README. I understand that this may look like code duplication, so I can replace it with a simpler deployment using pause pods like this inflate example with the same constraints if you prefer.
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.
@askulkarni2 I just realized that I may not have been clear in what I'm trying to achieve with this sample deployment. I want to deploy one application to demonstrate two things:
- Deploy workloads with contraints to see how Karpenter will manage them
- Deploy a web application accessible through an ALB provisioned by the AWS Load Balancer Controller running on Fargate
I thought that using the same application to demonstrate these two points was a good idea so that's why I didn't use the app-2048 addon.
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 are we trying to highlight or demonstrate?
- Why is this beneficial to customers?
- Is this specific to Karpenter on Fargate?
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 are trying to demonstrate how to create a cluster using Fargate profiles in which to run Karpenter and other add-ons. More specifically how to implement the Run the Karpenter controller on EKS Fargate best practice and provide a demo application so customers can test this use case using the EKS blueprints.
This example also uses spot instances, SQS for the interruption queue and an ALB deployed by the AWS Load Balancer Controller (running on Fargate) to access the demo app (running on worker nodes deployed by Karpenter).
The demo app deployment is also using nodeSelector
, topologySpreadConstraints
, and podAntiAffinity
to demonstrate how Karpenter handles these types of constraints.
examples/karpenter-fargate/main.tf
Outdated
# # Allow ingress from the worker nodes security group (Karpenter nodes) | ||
# # to the cluster primary security group (Fargate nodes) | ||
# resource "aws_security_group_rule" "cluster_primary_ingress_all" { | ||
# description = "Allow All ingress from the worker nodes security group" | ||
# type = "ingress" | ||
# to_port = 0 | ||
# protocol = "-1" | ||
# from_port = 0 | ||
# security_group_id = module.eks_blueprints.cluster_primary_security_group_id | ||
# source_security_group_id = module.eks_blueprints.worker_node_security_group_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.
Are thoses still needed ?
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.
No. I removed them.
} | ||
} | ||
|
||
resource "kubectl_manifest" "karpenter_provisioner" { |
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.
Warning here, if you update a provisioner in futur terraform apply, it will first delete, then recreate it.
But when it delete it, it will delete all karpenter nodes associated to it..
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.
Yes you're right. The provisioner that was deployed in https://github.com/aws-ia/terraform-aws-eks-blueprints/tree/main/examples/karpenter was also using this method but it was removed in 8915911.
please see the updated https://github.com/aws-ia/terraform-aws-eks-blueprints/tree/main/examples/karpenter |
What do you want to with this PR then? My goal was to provide a more complete example to customers who wants to deploy workloads on EKS cluster that are using Karpenter and Fargate. If you think this repo is not the right place to provide that kind of example I can close this PR. |
the current example for Karpenter is already configured for running on Fargate. If there are additional features/questions related to this pattern, please feel free to open a new issue describing the solution you would like to see or have answered Ref: https://github.com/aws-ia/terraform-aws-eks-blueprints/tree/main/examples/karpenter |
I'm not sure why you are closing this PR since https://github.com/aws-ia/terraform-aws-eks-blueprints/tree/main/examples/karpenter does not provide the following items:
Should I assume that you are not interested in providing this type of example to customers within this repo? |
I would recommend checking out this draft PR that lays out some upcoming changes to EKS Blueprints and specifically this section |
What does this PR do?
Add an example that demonstrates how to create a cluster using Fargate profiles in which to run Karpenter and other add-ons. More specifically how to implement the Run the Karpenter controller on EKS Fargate best practice and provide a demo application so customers can test this use case using the EKS blueprints.
This example also uses spot instances, SQS for the interruption queue and an ALB deployed by the AWS Load Balancer Controller (running on Fargate) to access the demo app (running on worker nodes deployed by Karpenter).
The demo app deployment is also using
nodeSelector
,topologySpreadConstraints
, andpodAntiAffinity
to demonstrate how Karpenter handles these types of constraints.Motivation
More
pre-commit run -a
with this PRNote: Not all the PRs require a new example and/or doc page. In general:
docs/add-ons/*
is required for new a new addonFor Moderators
Additional Notes