chore(deps): bump karpenter to 1.14.1 and fix templates

[BetoFandino]

Description

The chart's Karpenter templates render APIs that Karpenter removed in v1.0, so
karpenter.enabled: true cannot work on main. This rewrites both templates onto the v1 API,
replaces the values contract with a pass-through one, and bumps the subchart 1.0.8 → 1.14.1.

The bug

The pinned subchart (1.0.8) ships CRDs that only serve v1, but the templates still render the
alpha APIs:

template	renders	status
provisioner.yaml	karpenter.sh/v1alpha5 · Provisioner	removed in v1.0
node-template.yaml	karpenter.k8s.aws/v1alpha1 · AWSNodeTemplate	removed in v1.0

Both fail with no matches for kind. The subchart was moved to 1.x at some point without migrating
the templates.

The values have the same problem, more quietly. values.yaml sets karpenter.settings.aws.*, but
Karpenter flattened those to settings.clusterName / settings.interruptionQueue in v0.32 and
removed defaultInstanceProfile outright. The Karpenter chart ships no values.schema.json, so
nothing errors — the keys are silently ignored and the controller comes up with no cluster name and
no interruption queue.

What changed

• templates/karpenter/provisioner.yaml → nodepool.yaml, rendering karpenter.sh/v1 NodePool.
• templates/karpenter/node-template.yaml → ec2nodeclass.yaml, rendering
  karpenter.k8s.aws/v1 EC2NodeClass.
• values.yaml: new contract, described below.
• Chart.yaml: karpenter 1.0.8 → 1.14.1; chart version bumped.
• README.md: the Karpenter section documented keys that no longer exist and stated that multiple
  node pools were unsupported. Both corrected, plus the scope note on node-based scaling, which the
  chart now does support.

The values contract

Both resources are passed through verbatim. spec is rendered with toYaml; the templates do
not name a single field of the Karpenter API. Any field the API accepts — including ones added in
future releases — works without a chart change, and the upstream Karpenter docs apply directly with
no translation layer.

ec2NodeClasses and nodePools are maps keyed by resource name, so any number of each is
supported and Helm's map merge lets an override carry only the keys that differ:

karpenter:
  enabled: true
  settings:
    clusterName: my-cluster
    interruptionQueue: Karpenter-my-cluster
  defaultEC2NodeClass: default
  ec2NodeClasses:
    default:
      spec:                       # verbatim EC2NodeClass spec
        role: my-node-role
        amiSelectorTerms:
          - alias: al2023@latest
  nodePools:
    default:
      spec: {}                    # verbatim NodePool spec

Beyond rendering, the chart does three things, each with an escape hatch:

key	effect	skipped when
discovery	fills subnetSelectorTerms / securityGroupSelectorTerms with the karpenter.sh/discovery tag; defaults
to settings.clusterName	the node class set
zones	appends a topology.kubernetes.io/zone requirement to each NodePool	the pool declares that key, or zones
is empty
defaultEC2NodeClass	fills nodeClassRef	the pool declares its own

Four render-time fails cover what the API requires and what the apiserver would otherwise report
badly or late: a node class with neither role nor instanceProfile, a node class without
amiSelectorTerms, a pool with no nodeClassRef and no defaultEC2NodeClass, and a pool
referencing a node class that was never declar

Both maps are empty by default. A capacity strategy depends on the workload and the account it
runs in, so the chart does not presume one; values.yaml carries a commented single-pool example.
karpenter.enabled: true with nothing declared renders the controller and no custom resources.

🔴 Breaking changes

The old keys are silently ignored today, so an getting a controller with
no configuration. They now have to be migrated:

old	new
karpenter.settings.aws.clusterName	karpenter.settings.clusterName
karpenter.settings.aws.interruptionQueueName	karpenter.settings.interruptionQueue
karpenter.settings.aws.defaultInstanceProfises.<name>.spec.role or .instanceProfile
karpenter.nodeTemplate.*	karpenter.ec2NodeClasses.<name>.spec.*
karpenter.provisioner.*	karpenter.nodePools.<name>.spec.*
karpenter.provisioner.spec.requirements	karpenter.nodePools.<name>.spec.template.spec.requirements
karpenter.provisioner.spec.limits.resources	karpenter.nodePools.<name>.spec.limits
karpenter.provisioner.spec.ttlSecondsUntilExpired	…spec.template.spec.expireAfter
karpenter.provisioner.spec.ttlSecondsAfterEmpty	…spec.disruption.consolidateAfter

Two things to be deliberate about when migrating:

• role or instanceProfile is now required — the render fails without it instead of
  provisioning nothing.
• ttlSecondsAfterEmpty only reclaimed **emptdationPolicy: WhenEmpty. The commented example uses WhenEmptyOrUnderutilized`, the API default, which also consolidates
  nodes that are running workloads. Copying the example changes that behaviour.

Testing

Rendered against the live Karpenter configuration of four production EKS clusters in different
accounts, regions, AMIs and disk sizes.
Also verified: all four fail guards fire with an actionable message; karpenter.enabled: false
renders nothing; enabled: true with no declasources; and the commented
example renders when uncommented.

Notes for operators upgrading

• Helm never updates CRDs. The subchart ships them in crds/, which is install-only. Going from
  1.0.8 to 1.14.1 adds two CRDs (nodeoverlays, capacitybuffers) and changes the existing
  three. They have to be applied through the st, which this chart does
  not include.
• ec2:DescribeInstanceStatus is required since Karpenter 1.12. Without it the controller logs a
  403 every minute and carries on. With it, instances failing EC2 status checks get
  ForcefulTermination, which bypasses PDB-respecting eviction and disruption budgets. Worth
  granting deliberately, separately from this