* feat(karpenter): Upgrade to version 0.27.0
Upgrade Karpenter to current last stable version `0.27.0`.
Template have been updated to use the same templates than the Helm chart.
* feat(karpenter): Use AWSNodeTemplate for launchTemplate
To set Launch Templates is deprecated into the provisioner, it is recommends using the `AWSNodeTemplate` to set it.
Ref:
- https://karpenter.sh/v0.27.0/concepts/node-templates/
* feat(karpenter): Enable pruning addon
* Use extra flags in upgrade-ab scenario test
* feat(karpenter): Drop `karpenter` feature flag
* feat(karpenter): Add release note for `1.27`
* feat(karpenter): Upgrade to version 0.27.3
* feat(karpenter): fix template
* feat(karpenter): Upgrade to version 0.27.5
* Update Karpenter documentation with depending kops version
* Delete KOPS_FEATURE_FLAGS from e2e test `run-test`
* Run hack/update-expected.sh
We want to be able to use "dns=none" (without peer-to-peer gossip)
even for clusters that have the k8s.local extension. These were
previously called "gossip clusters", but really that is an
implementation; what actually matters to users is that they don't rely
on writing records into a DNS zone (such as Route53).
We identify the external manifests by checking for our labels.
Currently that label is kOps specific, and we'll likely have to evolve
that to something ecosystem-netural.
We only support the GCE CCM addon and the kopeio-networking addon at
first.
For the GCE CCM addon, we need to replace the arguments, in particular
we likely need the Pod CIDR. Here we need to work with the GCE CCM to
find a mechanism that can allow some of these flags to be communicated
via a more extensible mechanism (env vars or config maps, likely,
though possibly CRDs).
This is all behind the ClusterAddons feature flag at the moment, so we
can figure this out with other projects safely.
Co-authored-by: John Gardiner Myers <jgmyers@proofpoint.com>
Previously this was done in the manifests leading to empty files. kubectl doesn't like this, so protokube will always fail updating the addon when StorageClass management is disabled
In the case IRSA is optional for an addon, we shouldn't unconditinally add the IRSA bits to the manifest.
This is also a clean up. We no longer need to expand the list of well-known SAs as we already know which roles are being built
Not all additional objects are meant to be applied to the cluster; a
few are configured through a file path. We explicitly handle those
and don't write them to the file where they should be applied.