Packaged components list is out of date

[jandubois]

On https://docs.k3s.io/installation/packaged-components it says:

K3s comes with a number of packaged components that are deployed as AddOns via the manifests directory: coredns, traefik, local-storage, and metrics-server.

And later:

Care should also be taken not to conflict with names in use by the default K3s packaged components, even if those components are disabled.

This requires that the list of packaged components is complete, but it is missing several names, like ccm, rolebindings, runtimes.

[brandond]

Yeah, some of those things can technically be disabled, but will break other things if they are, so we don't document them. For example:

• disabling rolebindings will break most of the k3s built-in controllers.
• disabling ccm will break the built-in cloud controller.
• disabling runtimes will remove the runtimeclasses for all autodetected runtimes.
• disabling individual metrics-server addons (aggregated-metrics-reader, and so on) will break metrics-server, which is split across 7 different add-ons for historical reasons.

[jandubois]

but will break other things if they are, so we don't document them.

I understand, but maybe there should still be a list of reserved names. Or the advise should recommend prefixing additional manifests with some custom prefix?

I noticed this because I was creating a runtimes.yaml and then found that k3s was just overwriting it (which doesn't make any sense if you specify the --container-runtime-endpoint or --docker options, but whatever).

It's not a big deal, as I wouldn't have checked the documentation until after I ran into problems anyways. 😄

Feel free to close if you think this is not worth the trouble.

[brandond]

No I think you are correct that we should document this. There are also some nuances of how disable works - note that --disable=metrics-server works because the addon manifests are in a directory named metrics-server, which is not exactly how we document things working.

A lot of this is stuff that was thrown together early on and we have avoided changing to try to prevent breakage on upgrades; it's certainly not ideal.

[jandubois]

There are also some nuances of how disable works

That's why I like the SERVICE.yaml.skip mechanism. You just touch the file, and either the k3s versions knows about SERVICE and skips it, or it simply ignores the file.

No need to worry if --disable=SERVICE will fail in older k3s versions because maybe --disable wasn't supported yet, or maybe it validated that SERVICE was a known service, to catch typos etc. Worst case is that it will kubectl apply the file as a manifest, which should be a no-op because the file is empty.