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.
Adding support for the kopeio-networking addon.
We load the operator manifest (which changes rarely) from the channels
directory for now. We follow the same structure as operators
themselves use so that we can support other backends in future.
The channels file includes the current versions of the operators.
During cluster creation, we create these additional objects.