Add external Karpenter guard and upgrade command to kubectl-datadog#2890
Add external Karpenter guard and upgrade command to kubectl-datadog#2890
Conversation
Add a guard in `kubectl datadog autoscaling cluster install` to detect and block installation when an external Karpenter is already active on the cluster, using webhook-based detection with Helm release ownership validation. This prevents accidentally deploying a second Karpenter controller while still allowing idempotent re-installs of our own. Add `kubectl datadog autoscaling cluster upgrade` to update a Karpenter that was previously installed by the plugin. The command auto-detects the installation namespace and previous parameters (cluster name) from the existing Helm release, avoiding the need to re-specify them. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Avoid variable shadowing of `err` in the upgrade run() method by using plain assignments instead of if-init statements. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Use explicit var declaration and assignment instead of short variable declaration to avoid shadowing the outer err variable. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
@codex review |
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #2890 +/- ##
==========================================
- Coverage 40.06% 39.90% -0.17%
==========================================
Files 319 321 +2
Lines 28039 28265 +226
==========================================
+ Hits 11233 11278 +45
- Misses 15983 16161 +178
- Partials 823 826 +3
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: 8f871c2 | 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: f15baa9e41
ℹ️ 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".
| } | ||
|
|
||
| // Check for existing Karpenter installation | ||
| if found, webhookNamespace, err := commonk8s.DetectActiveKarpenter(ctx, o.Clientset); err != nil { |
There was a problem hiding this comment.
The new install guard only checks DetectActiveKarpenter webhooks, so when Karpenter is installed but webhook configs are absent (for example a crashed/disabled controller or manually removed webhook objects), this branch falls through and installation proceeds in the default namespace, creating a second Karpenter deployment instead of blocking or reusing the existing one. This is a production-impacting regression in the external-installation guard, especially since the commit already introduced FindKarpenterHelmRelease for exactly this fallback path.
Useful? React with 👍 / 👎.
When DetectActiveKarpenter finds no webhooks, fall back to FindKarpenterHelmRelease to detect orphaned Helm releases (e.g. when Karpenter pods have crashed but the release still exists). This prevents creating a duplicate installation. The upgrade command already used this fallback; this aligns the install command's detection logic. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
Addressed @chatgpt-codex-connector P1 feedback in commit 8f871c2: added FindKarpenterHelmRelease as a fallback in the install path when DetectActiveKarpenter finds no webhooks. This mirrors the approach already used in the upgrade command. |
2 participants
What does this PR do?
Two additions to
kubectl datadog autoscaling cluster:External Karpenter guard in
install: Detects an active Karpenter on the cluster via webhook configurations and validates Helm release ownership. Blocks installation when an external (non-plugin) Karpenter is found, while still allowing idempotent re-installs of our own.upgradesubcommand: Updates a Karpenter previously installed by the plugin. Auto-detects the installation namespace and previous parameters (cluster name) from the existing Helm release.Motivation
installfrom deploying a second Karpenter controller on top of an externally-installed one.Additional Notes
Detection strategy:
ValidatingWebhookConfiguration/MutatingWebhookConfiguration) identifies active Karpenter installations and their namespaceadditionalLabels["app.kubernetes.io/managed-by"] == "kubectl-datadog") distinguishes our installation from external onesUpgrade command:
--karpenter-namespaceflag — namespace is auto-detectedinstallpackage to avoid duplicationMinimum Agent Versions
N/A — this is a kubectl plugin change only.
Describe your test plan
DetectActiveKarpenter) with various webhook configurationsFindKarpenterHelmRelease) with various secret statesupgradecommand validation and config extractiongo build,go test, andgo vetall passChecklist
bug,enhancement,refactoring,documentation,tooling, and/ordependenciesqa/skip-qalabel🤖 Generated with Claude Code