Conversation
Karpenter's Helm chart includes a default node affinity (karpenter.sh/nodepool: DoesNotExist) that prevents the controller from running on nodes it manages. This creates a migration problem: users must keep pre-existing nodes just for the Karpenter controller. Create an AWS Fargate profile for the Karpenter namespace so the controller runs on dedicated serverless compute, separate from both pre-existing and Karpenter-managed EC2 nodes. This allows users to fully migrate workloads to Karpenter-managed nodes. Changes: - Add private subnet discovery from cluster VPC route tables - Add FargatePodExecutionRole and FargateProfile to CloudFormation - Add --no-fargate flag for opt-out - Set controller resource requests when running on Fargate - Preserve existing Fargate profile on re-run if subnet discovery fails - Display Fargate profile in uninstall resource summary Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Fix govet shadow error: use = instead of := for err in createCloudFormationStacks to avoid shadowing named return value - Fix gci import ordering in uninstall.go: ec2/types before eks - Remove trailing blank line in privatesubnets.go Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
@codex review |
Codecov Report❌ Patch coverage is ❌ Your patch status has failed because the patch coverage (23.38%) is below the target coverage (80.00%). You can increase the patch coverage or adjust the target coverage. Additional details and impacted files@@ Coverage Diff @@
## main #2891 +/- ##
==========================================
- Coverage 40.06% 40.00% -0.06%
==========================================
Files 319 320 +1
Lines 28039 28153 +114
==========================================
+ Hits 11233 11262 +29
- Misses 15983 16068 +85
Partials 823 823
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report in Codecov by Sentry.
🚀 New features to boost your workflow:
|
|
🎯 Code Coverage (details) 🔗 Commit SHA: 5b9a129 | Docs | Datadog PR Page | Was this helpful? React with 👍/👎 or give us feedback! |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 5b9a12952d
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| "DeployPodIdentityAddon": strconv.FormatBool(!isUnmanagedEKSPIAInstalled), | ||
| "DeployNodeAccessEntry": strconv.FormatBool(supportsAPIAuth), | ||
| "DeployFargateProfile": strconv.FormatBool(deployFargate), | ||
| "FargateSubnets": fargateSubnets, |
There was a problem hiding this comment.
This always sends a freshly discovered FargateSubnets value during stack updates, which can break idempotency: in AWS::EKS::FargateProfile, Subnets is a replacement-only property, while the template fixes FargateProfileName to ${ClusterName}-karpenter. If the discovered subnet set/order changes after first install (for example after VPC/subnet changes), CloudFormation needs to replace a custom-named profile and the update fails, so kubectl datadog autoscaling cluster install can fail on re-run. To avoid this, keep using the existing profile subnets whenever the profile already exists (not only on discovery errors), or stop pinning the profile name.
Useful? React with 👍 / 👎.
2 participants
What does this PR do?
Adds AWS Fargate support to the
kubectl datadog autoscaling cluster installcommand so the Karpenter controller runs on dedicated Fargate nodes instead of regular EC2 nodes.Motivation
Karpenter's Helm chart includes a default node affinity (
karpenter.sh/nodepool: DoesNotExist) that prevents the controller from running on nodes it manages. This creates a migration problem: when migrating all workloads from pre-existing nodes to Karpenter-managed nodes, the controller itself cannot be migrated, forcing users to keep some pre-existing nodes.Running Karpenter on Fargate solves this by providing dedicated serverless compute, separate from both pre-existing and Karpenter-managed EC2 nodes. Users can then fully decommission their pre-existing node groups.
Additional Notes
Changes:
FargatePodExecutionRoleandFargateProfileadded to CloudFormation template (conditional)--no-fargateflag for opt-outFargate compatibility:
karpenter.sh/nodepoollabel, so default affinity is satisfiedMinimum Agent Versions
N/A — this change affects the kubectl plugin only, not the operator or agent.
Describe your test plan
go test ./cmd/kubectl-datadog/autoscaling/cluster/install/guess/...(12 test cases for subnet filtering)go build ./cmd/kubectl-datadog/...kubectl datadog autoscaling cluster install --cluster-name <name>on a test EKS cluster and verify:kubectl get pods -n dd-karpenter -o wideshowsfargate-*node names)kubectl datadog autoscaling cluster uninstallcleans up the Fargate profile via CloudFormationChecklist
bug,enhancement,refactoring,documentation,tooling, and/ordependenciesqa/skip-qalabel🤖 Generated with Claude Code