DEV Community: Roy

Kubernetes 1.34 End of Life: What Actually Happens on EKS, GKE, and AKS

Roy — Tue, 06 Oct 2026 17:24:19 +0000

Kubernetes 1.34 reaches end of life upstream on October 27, 2026. If you run it on EKS, GKE, or AKS, that date by itself changes very little. Each provider keeps its own support clock, and each one does something different when that clock runs out. EKS upgrades your control plane without notice. GKE upgrades it on its own schedule, later if the cluster is on the Extended channel. AKS upgrades nothing on the day and stops shipping security patches.

For 1.34 itself, the provider dates are:

EKS: standard support ends December 2, 2026; extended support ends December 2, 2027.
GKE: standard support ends January 25, 2027; the Extended channel runs to November 25, 2027.
AKS: end of life November 30, 2026; LTS runs to November 2027.

Between now and the end of the year, these are the dates that change what a cluster does:

Kubernetes support deadlines, October to December 2026

Date	Platform	What happens	Affects you if
Oct 22	GKE	1.31 extended support ends	You still run GKE 1.31 on the Extended channel
Oct 27	Upstream	1.34 end of life: no more patch releases	You run 1.34 with nobody backporting fixes for you
Oct 31	AKS	Azure Linux 2.0 node images removed; those node pools can't scale	You have Azure Linux 2.0 node pools
November	AKS	Security patches end for the NGINX-based application routing add-on	You use the application routing add-on
November	GKE	Regular channel auto-upgrades clusters to 1.36 (Google's estimate, moved from October)	Your cluster is on the Regular channel
Nov 26	EKS	1.31 extended support ends; control planes can be upgraded to 1.32 at any time after, without notice	You still run EKS 1.31
Nov 30	AKS	1.34 end of life; clusters drop to platform support	You run AKS 1.34 without LTS
Dec 2	EKS	1.34 standard support ends; price goes from $0.10 to $0.60 per cluster-hour	You run EKS 1.34
Dec 16	Upstream	Kubernetes 1.38 released (proposed date); 1.35 enters maintenance Dec 28	You plan upgrades a quarter ahead

Where only a month is given, that's all the provider publishes. AKS end-of-life months end on the last day of the month. Every row links to its source in the section below.

What "end of support" does on each platform

"End of support" means something different on each platform:

	Upstream	EKS	GKE	AKS
When support ends	Patch releases stop	Extended support starts automatically; 12 months later the control plane is upgraded at any time, without notice	Control plane is upgraded to the next minor	Version drops to platform support; no upgrade until it's about to leave platform support
Ways to stay longer	Your distribution's backports, if any	Extended support, on by default	Extended channel, or an emergency 90-day exclusion with no support	LTS
Price of staying	-	$0.60 per cluster-hour instead of $0.10	$0.60 per cluster-hour on the Extended channel	LTS requires the Premium tier
Left behind	-	Managed node groups, self-managed nodes, and add-ons stay on the old version	Nodes can trail the control plane by up to two minors	Security patches and Kubernetes component support

I spent years at Google working with GKE customers, and forced upgrades look different from the provider's side. An unpatched control plane is a liability for the provider as much as for you, which is why every provider eventually moves it for you. They differ in what they move, when, and what they charge you to wait. AKS waits longest: on November 30, an AKS 1.34 cluster keeps serving traffic, keeps scaling, and stops getting security patches.

Kubernetes 1.34 end of life upstream: no more patches after October 27

Kubernetes 1.34 entered maintenance mode on August 27, 2026, and reaches end of life on October 27, 2026. After that, the Kubernetes project ships no more 1.34 patch releases. The next monthly patch release is targeted for October 13, before the cutoff.

The last round landed on September 23: 1.34.12, 1.35.9, 1.36.5, and 1.37.1 fix CVE-2026-2270, where a user who can write StatefulSets and ControllerRevisions in one namespace can get kube-controller-manager to create a Pod in another namespace. If you apply one more 1.34 patch before upgrading, apply that one.

Who a missing patch affects depends on who runs your control plane. On self-managed clusters (kubeadm, k3s, RKE2), a CVE found after October 27 has no 1.34 fix unless your distribution backports it. EKS says it backports security patches to every version it still supports, including extended support. AKS platform support explicitly does not apply security patches.

EKS 1.34 and 1.31: the forced upgrade moves only the control plane

EKS gives every version 14 months of standard support and 12 months of extended support. When extended support ends, EKS upgrades the control plane to the oldest version still supported. The docs are direct about the timing: automatic updates "can happen at any time after the end of extended support date," and "You won't receive any notification before the update."

For 1.31, that date is November 26, 2026. After that date the control plane can be upgraded at any time. The forced upgrade only moves the control plane. Self-managed nodes and managed node groups stay on 1.31 (EKS Auto Mode nodes may update on their own), add-ons stay on whatever versions you pinned for 1.31, and an automatically upgraded cluster can't be rolled back. Whenever it happens, you end up with a 1.32 control plane and 1.31 nodes. That's within the version skew policy, so it runs, but it's a state you never tested.

It also lands you on 1.32, which is itself in extended support until March 23, 2027. However late the forced upgrade comes, the next deadline doesn't move.

For 1.34, the date is December 2, 2026, and what changes is the bill. Extended support is enabled by default, so a 1.34 cluster keeps running and moves from $0.10 to $0.60 per cluster-hour. If you disabled extended support, the cluster is upgraded at the end of standard support instead.

EKS added 1.37 on October 1, 2026.

To see where each cluster stands:

# Version and support policy for every EKS cluster in the current region
for c in $(aws eks list-clusters --query 'clusters[]' --output text); do
  aws eks describe-cluster --name "$c" \
    --query 'cluster.[name, version, upgradePolicy.supportType]' --output text
done

# The dates EKS will enforce for those versions
aws eks describe-cluster-versions --cluster-versions 1.31 1.32 1.34 \
  --query 'clusterVersions[].[clusterVersion, status, endOfStandardSupportDate, endOfExtendedSupportDate]' \
  --output table

EKS also scans for upgrade problems on its own. Upgrade insights refresh every 24 hours and check for deprecated APIs, kubelet and kube-proxy version skew, cluster health, and add-on compatibility (aws eks list-insights --cluster-name "$c"). They're built around APIs, version skew, and add-ons; the 1.35 changes below live in node configuration, so check those separately.

GKE 1.34: standard support runs to January, the 1.36 rollout starts in November

GKE 1.34 stays in standard support until January 25, 2027, when GKE upgrades clusters outside the Extended channel to the next minor. Most channel-enrolled clusters won't wait that long. Per the release schedule, 1.35 became the auto-upgrade target from 1.34 in late April 2026 on Regular and mid-September on Stable. Rollouts are gradual and follow maintenance windows, so a cluster still on 1.34 may just not have been reached yet, but it may also be held back by a maintenance exclusion, a deprecation pause, or the Extended channel.

For most GKE clusters, what changes this quarter is 1.36. Google's best-effort schedule, revised in early October, has the Regular channel targeting 1.36 around November and Stable in early 2027. That's the 1.35 to 1.36 upgrade in the table below: gitRepo volumes, strict IP validation, renamed metrics. 1.37 is expected on Regular around October 14.

GKE's deprecation pause can keep exactly the wrong clusters behind. When GKE detects use of an API that the next minor removes, it pauses automatic minor upgrades until it sees 30 consecutive days without that usage, and it says it "cannot guarantee" the pause. It's a sensible safety valve. It also means the clusters with known upgrade blockers are the ones that stay behind, until end of support upgrades them with the blocker still in place. An emergency "No upgrades" maintenance exclusion can hold that off for up to 90 days past end of support, unsupported the whole time, and no longer.

Two GKE-specific changes on the way to 1.35: GKE now enforces timeoutSeconds on exec probes, so a probe command that takes 3 seconds against the default 1-second timeout, which used to pass, starts failing. Windows Server nodes also move to containerd 2.0.

gcloud container clusters list \
  --format="table(name, location, currentMasterVersion, currentNodeVersion, releaseChannel.channel)"

The Extended channel has its own deadline this quarter: GKE 1.31 reaches the end of extended support on October 22, 2026.

If you need more time, the Extended channel keeps 1.34 until November 25, 2027, at a total of $0.60 per cluster-hour once the version is in its extended period.

AKS 1.34 end of life: nothing happens on November 30, and that's the risk

AKS 1.34 reaches end of life at the end of November 2026. After that it moves to platform support until 1.38 reaches GA. In platform support, node pool scaling, upgrades to a supported version, and the infrastructure SLA all still work. "Applying security patches" and "Kubernetes components (including add-ons)" are listed as not supported, and you can't create new 1.34 clusters.

AKS doesn't upgrade the cluster on November 30. The forced upgrade comes later: when a non-LTS cluster is about to fall out of platform support, which for 1.34 means when 1.38 reaches GA on AKS, AKS upgrades it to the oldest fully supported minor. Clusters on an auto-upgrade channel move sooner. AKS Automatic is always on stable, which targets the second-newest minor, and Standard clusters on stable or rapid follow their channel. The default for Standard clusters is none. If you need patches without upgrading, AKS sells a second year as LTS, which requires the Premium tier and explicit LTS enrollment.

One AKS date this quarter isn't about a Kubernetes version at all. AKS stopped patching Azure Linux 2.0 on November 30, 2025 and froze its node image at 202512.06.0. On October 31, 2026, those images are removed and node pools on them can't scale. Nothing visible happens that day. It breaks the next time the cluster autoscaler, or anyone else, tries to add a node. Azure Linux 3.0 is the default from Kubernetes 1.32, so the pools at risk are AzureLinux pools on 1.31 or earlier: LTS clusters, and clusters already out of support. az aks nodepool update --os-sku AzureLinux3 migrates a pool in place on Kubernetes 1.28 and later.

AKS also stops patching the ingress-nginx-based application routing add-on in November 2026. Microsoft's documented migration target is the Gateway API. Upstream ingress-nginx has been archived since March 2026.

az aks list \
  --query "[].{name:name, resourceGroup:resourceGroup, version:currentKubernetesVersion, channel:autoUpgradeProfile.upgradeChannel, plan:supportPlan, tier:sku.tier}" -o table

az aks nodepool list -g "$RG" --cluster-name "$CLUSTER" \
  --query "[].{pool:name, osSku:osSku, version:currentOrchestratorVersion, image:nodeImageVersion}" -o table

When paying for extended support is the right call

EKS and GKE charge the same for extended support: $0.50 per cluster-hour on top of the $0.10 base, which comes to about $365 per cluster per month. For a single cluster with a known blocker and an upgrade scheduled for January, that's cheaper than the engineering time of rushing the upgrade through in December. Across a fleet, it adds up. Forty clusters left in extended support by default cost an extra $175,000 a year.

My rule of thumb: pay for extended support when you can name the blocker and the date you'll fix it. If you can't name the blocker, extended support mostly delays the day you find out what it is.

What breaks between Kubernetes 1.34 and 1.37

EKS, GKE, and AKS (outside LTS) upgrade the control plane one minor version at a time, so a 1.34 cluster reaches 1.37 through three separate upgrades, each with its own removals:

Upgrade	Change	What happens
1.34 → 1.35	`failCgroupV1` defaults to true	Kubelet won't start on cgroup v1 nodes
1.34 → 1.35	`--pod-infra-container-image` kubelet flag removed	Kubelet fails to start if the flag is still set
1.34 → 1.35	IPVS kube-proxy mode deprecated	Warnings now; removal planned for 1.40
1.34 → 1.35 (GKE)	Exec probe timeouts enforced	Probe commands slower than `timeoutSeconds` start failing
1.35 → 1.36	gitRepo volumes permanently disabled	Workloads that mount them stop working
1.35 → 1.36	`StrictIPCIDRValidation` on by default	The API server rejects values like `010.000.000.005` in new objects
1.35 → 1.36	Service `externalIPs` deprecated	Warnings now; kube-proxy support planned off by default in 1.40, removed in 1.43
1.35 → 1.36	`volume_operation_total_errors` → `volume_operation_errors_total`, `etcd_bookmark_counts` → `etcd_bookmark_total`	Alerts on the old names silently stop matching
1.36 → 1.37	25 feature gates, 18 kubelet flags, `eventRecordQPS: 0`	See Kubernetes 1.37 breaking changes

The 1.35 and 1.36 details are in the v1.35 and v1.36 release announcements. The cgroup v1 change is the one that stops nodes: on 1.35, a kubelet on a cgroup v1 host refuses to start unless you set failCgroupV1: false. To check a node, run stat -fc %T /sys/fs/cgroup/ on it. cgroup2fs means v2; tmpfs means v1.

containerd 1.7 has a similar caveat. The 1.35 release told users to move to containerd 2.x before the next Kubernetes version, but the kubelet change that would break 1.7 has since been deferred to 1.38. containerd 1.7 itself reached end of life in September 2026, and 2.2 follows on November 6.

To see every cluster's control plane, kubelet, and runtime versions from one kubeconfig:

for ctx in $(kubectl config get-contexts -o name); do
  echo "== $ctx: $(kubectl --context "$ctx" version -o json 2>/dev/null \
    | jq -r '.serverVersion.gitVersion // "unreachable"')"
  kubectl --context "$ctx" get nodes --no-headers \
    -o custom-columns=KUBELET:.status.nodeInfo.kubeletVersion,RUNTIME:.status.nodeInfo.containerRuntimeVersion \
    2>/dev/null | sort | uniq -c
done

Checking each upgrade with Radar

We build Radar, an open-source Kubernetes UI, so take this section with that in mind. Its Upgrade impact view (Checks, then the Upgrade impact tab) runs against one cluster at a time and targets the next minor by default. Each check belongs to the release that makes it relevant, so it only runs when your upgrade crosses that release. A 1.34 cluster targeting 1.35 gets node cgroup compatibility and, on GKE, exec probe timeout exposure. A 1.35 cluster targeting 1.36 gets container runtime support, gitRepo volumes, Service externalIPs, strict IP/CIDR validation, and renamed metrics. Every upgrade also gets the standing checks: removed API usage, kubelet and kube-proxy version skew, admission and CRD conversion webhooks, and node drain feasibility.

Here it is on our own GKE nonprod cluster, which runs 1.35 on the Regular channel and is next in line for 1.36. The 1.36 checks all pass there, but the scan still finds three blockers in webhooks and node drains:

If you pick a target more than one minor ahead, the verdict is Blocked and the report lists the upgrade sequence, the same one-minor-at-a-time path EKS, GKE, and non-LTS AKS require. When Radar can't read something, such as kubelet configuration without nodes/proxy access, the check is marked Incomplete rather than passed. Radar doesn't know your provider's dates or release channels; that's what the table at the top is for.

The same scan runs headless over HTTP and over MCP (get_cluster_upgrade_readiness), so you can script it per cluster or hand it to an agent. The 1.37 post has the commands.

Also on the calendar

Helm 3: bug fixes ended with the final feature release, v3.22.0, on September 9, 2026. Security fixes continue until February 10, 2027.
Kubernetes 1.38: proposed release on December 16, 2026, which starts the same cycle for 1.35.

Check each cluster before your provider's date arrives. After an automatic upgrade you'll be debugging on whatever version you were moved to.

Radar is open source (Apache-2.0). brew install skyhook-io/tap/radar, point it at a cluster, and open Checks. Or star it on GitHub.

Originally published on radarhq.io.

Karpenter Troubleshooting: Pending Pods, Failed Launches, and Nodes That Never Join

Roy — Mon, 28 Sep 2026 17:53:11 +0000

Karpenter changes how you debug a Pending pod.

A Karpenter NodePool can report Ready=True while the nodes it launches repeatedly fail to register. And that is only one reason these incidents can be confusing: the scheduler, NodePool, NodeClaim, NodeClass, and controller logs each hold a different part of the answer.

On a fixed set of nodes, Pending usually means the nodes you already have cannot take the pod. With Karpenter, there is another question: did Karpenter rule out every NodePool, or did it try to create capacity and fail?

This guide maps the failures we run into most often to the place I would look next. The screenshots come from Radar's Capacity view, the open-source tool we maintain, which assembles the same evidence from the cluster itself.

Karpenter pending pods: symptom, cause, where to look

Scheduler messages usually arrive as 0/N nodes are available: followed by a reason. That message is useful, but with Karpenter it is often only the first step.

Symptom or message	Usual cause	Where to look
`didn't match Pod's node affinity/selector`	Pod requires a label no NodePool declares	NodePool `requirements` and `spec.template.metadata.labels`
`had untolerated taint {key: value}`	NodePool template taints the node, pod has no toleration	NodePool `spec.template.spec.taints` vs pod tolerations
`Insufficient cpu` / `Insufficient memory`	Existing nodes are full. Says nothing about what Karpenter could provision	Node allocatable vs scheduled requests, then Karpenter's scheduling event
Pod pending, no NodeClaim created	Every pool ruled the pod out, or NodePool limits are reached	Karpenter `FailedScheduling` event; `status.resources` vs `spec.limits`
NodeClaim created, no node appears	Launch failed, or instance launched and never registered	NodeClaim conditions for launch failures; `NodeRegistrationHealthy` for repeated registration failures
Nodes launch then disappear	Registration timeout	NodePool `NodeRegistrationHealthy`
Pod stuck with no scheduler attempt	Scheduling gate still present	`spec.schedulingGates`
Nodes not consolidating	Disruption blocked or budgets exhausted	`DisruptionBlocked` / `Unconsolidatable` events

The important part is that these failures do not all live on the same object. A scheduling event can tell you why a pool was rejected, while a NodeClaim or NodePool condition tells you why capacity that should have appeared never did.

"didn't match Pod's node affinity/selector"

This is a common Karpenter misconfiguration and one of the easier ones to identify from configuration alone.

Karpenter only applies labels that come from a NodePool's requirements or its template labels. If a pod requires a custom label that no NodePool declares, no node Karpenter builds will ever carry it.

In production this is often a stale label: a workload-type renamed during a migration, or a nodeSelector copied from another cluster.

Start with:

kubectl describe pod <pod>

Then compare the pod's selectors and required affinity against each NodePool's:

spec.requirements
spec.template.metadata.labels

If the label the pod requires is never declared by any NodePool, Karpenter has nowhere to place it.

Radar's Demand view does this comparison across all NodePools and groups pods with the same scheduling constraints together, but the underlying check is the same one you can do manually.

"had untolerated taint" on a Karpenter cluster

Karpenter taints nodes from spec.template.spec.taints on the NodePool.

A pod without a matching toleration cannot land on anything that pool creates, so Karpenter can rule the pool out before provisioning even starts.

Compare:

NodePool.spec.template.spec.taints

against the pod's:

spec.tolerations

One thing to watch: startup taints are different from permanent taints.

Startup taints, along with the well-known unreachable/not-ready taints, are expected during parts of a node's lifecycle. They should not automatically be treated as evidence that the NodePool can never run the workload.

LaunchFailed, VCPULimitExceeded, and InsufficientInstanceCapacity

If Karpenter creates a NodeClaim and the cloud provider refuses it, the useful evidence moves away from the pod.

Look at the NodeClaim lifecycle conditions.

Common AWS examples include:

VCPULimitExceeded - the account's vCPU quota for that instance family is exhausted.
InsufficientInstanceCapacity - AWS does not currently have capacity for that instance type in the requested region or zone.
Unauthorized - the instance profile or IAM configuration is wrong.
LaunchFailed - Karpenter reached the launch stage but could not create the instance successfully.

A detail that makes these annoying to debug: failed NodeClaims do not necessarily stay around forever.

Timed-out NodeClaims are deleted, and the conditions attached to them disappear too. Karpenter can surface repeated launch or registration trouble at the NodePool level through NodeRegistrationHealthy, but the individual history - which claims failed, how many, and in what order - can be harder to reconstruct afterward.

That is why events and controller logs matter for intermittent failures.

Radar's Activity view keeps a longer provisioning history, but even without Radar, the practical rule is simple: if you see a NodeClaim, inspect it before assuming the pod event contains the answer.

Why aren't my Karpenter nodes joining the cluster?

This is one of the more confusing failure modes because the NodePool itself can still report Ready=True.

Karpenter tracks NodeRegistrationHealthy separately from the NodePool's top-level Ready condition.

That means the NodePool can be valid for provisioning, successfully launch instances, and still fail to produce usable nodes because those instances never register with the cluster.

The pattern looks roughly like this:

Karpenter decides the NodePool can satisfy the workload.
A NodeClaim is created.
The cloud instance launches.
The node never registers successfully.
The registration timeout is reached.
The instance is deleted.
Karpenter tries again.

From the workload side, the result is simple: the pod stays Pending and capacity never arrives.

From the NodePool side, Ready=True alone does not tell the whole story.

This is different from a broken NodeClass.

For example, if an EC2NodeClass looks like this:

ValidationSucceeded=False
SecurityGroupsReady=False
SubnetsReady=False
InstanceProfileReady=Unknown

then the NodeClass itself is not ready. That propagates through NodeClassReady, so this is not a case where the NodePool remains happily Ready while nodes fail to register.

Typical NodeClass problems include selectors that resolve to no subnets or security groups, a missing instance profile, or another prerequisite that cannot be resolved before launch.

A Ready=True plus NodeRegistrationHealthy=False problem happens later: the NodeClass was valid enough to provision, but the resulting node never successfully joined the cluster.

Those two failures can look nearly identical from the pod's point of view, but they require looking in different places.

Am I about to hit a NodePool limit?

Karpenter stops provisioning when a NodePool reaches spec.limits.

The pods that would have triggered more capacity stay Pending, and no NodeClaim is created for them.

Karpenter does tell you when this happens. Look for a FailedScheduling event containing messages such as:

node limits have been exhausted for nodepool
all available instance types exceed limits for nodepool

The number Karpenter checks is status.resources.

That matters because status.resources includes resources represented by in-flight NodeClaims. So:

headroom = limit - provisioned

not:

headroom = limit - allocatable

A NodePool can therefore be close to or at its limit even when relatively little capacity has successfully registered with Kubernetes.

The event tells you which pool hit its limit. To understand how much room is left elsewhere, compare spec.limits and status.resources across the other pools.

Provisioned, allocatable, requests, usage: which number means what

These numbers answer different questions:

Number	Source	What it tells you
Provisioned	`status.resources`	What counts against NodePool `spec.limits`, including in-flight claims
Node allocatable	Registered nodes	What Kubernetes can actually schedule onto now
Scheduled requests	Pod specs	What the scheduler has already committed
Actual usage	Metrics API	What workloads are consuming, not what can still be scheduled

Karpenter and Kubernetes schedule based on requests, not current CPU or memory usage.

A node can be using 20% CPU and still be completely full from the scheduler's point of view if all of its CPU has already been requested.

That is why Radar keeps eight capacity values separate instead of reducing them to a single utilization percentage.

There is another subtlety: unallocated is only an aggregate subtraction.

If a cluster has 4 CPUs and 8 GiB of memory unallocated in total, that does not prove a pod requesting 4 CPUs and 8 GiB can fit. Those resources still need to exist together on a single node that also satisfies the pod's other constraints.

What does DisruptionBlocked mean in Karpenter?

DisruptionBlocked and Unconsolidatable do not mean Karpenter disrupted a node.

They mean disruption was prevented.

Read either as disruption happening and the timeline reads backwards.

Common causes include:

a disruption budget that is exhausted
a PodDisruptionBudget that cannot be satisfied
a karpenter.sh/do-not-disrupt annotation
a NodeClaim with no associated node to disrupt

The raw event is usually the best place to start:

DisruptionBlocked: Nodeclaim does not have an associated node

Do not treat these events as evidence that Karpenter removed capacity. They are evidence that Karpenter considered a disruption and could not proceed.

Why a pod evaluates as "unknown" instead of incompatible

When we built this evaluation into Radar, we found it useful to separate three cases:

declared compatible
incompatible
unknown

The difference matters because configuration can prove some scheduling failures, but not all of them.

A required custom label that no NodePool declares is incompatible. Nothing the cloud provider does can fix that.

Provider-controlled labels such as zone, instance type, capacity type, and architecture are different. If the NodePool leaves them open, the provider's actual offerings may still satisfy the pod.

Requests are similar. Observed nodes can tell you whether a known machine shape is large enough, but they do not prove which instance types the provider could create next.

Radar therefore does not simulate provider offerings or claim that a compatible pod will schedule. It only says that the declared constraints do not rule it out.

If the available information cannot prove either outcome, the result is unknown instead of a guess.

Why some numbers show ≥ or ?

Capacity information is not always complete.

For example, RBAC may prevent access to one source, or metrics may only be available for part of the fleet.

Radar marks that distinction explicitly:

Glyph	Meaning
(none)	Exact - the source was fully observed
`≥`	Lower bound - only part of the source was observed
`≤`	Upper bound - derived from a lower-bound input
`?`	Unknown - the source was not observed

Missing data is never shown as zero, and partial data is never shown as exact.

This matters during an incident because "0" and "I could not read it" are very different answers.

What this doesn't cover

No full scheduling simulation. Provider inventory, spot availability, and exact bin-packing remain Karpenter's job.
DRA demand is outside the normal requests ledger. Dynamic Resource Allocation ResourceClaims can carry accelerator demand outside normal container requests.
No long-term trend analysis. This is about current state and recent failure evidence.
Single cluster. Same scope as the rest of Radar OSS.

Clusters without Karpenter can still be inspected through the normal node and node-group views. The Karpenter-specific Demand and Activity analysis depends on NodePools and NodeClaims being present.

Running it

Radar is Apache-2.0, runs as a single binary, and does not install anything in the cluster:

brew install skyhook-io/tap/radar
radar

Capacity requires Radar v1.9.0 or newer.

You can open it from the sidebar or jump there directly from a stuck pod using "Evaluate against Karpenter NodePools".

If Radar reaches a verdict you can prove wrong, that's worth an issue on GitHub.