--disable-helm-controller also disables Traefik

[comminutus]

Environmental Info:
K3s Version:
1.27.4+k3s1

Node(s) CPU architecture, OS, and Version:

Linux k3s-server-1 6.4.7-200.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Jul 27 20:01:18 UTC 2023 x86_64 GNU/Linux
Linux k3s-server-2 6.4.7-200.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Jul 27 20:01:18 UTC 2023 x86_64 GNU/Linux
Linux k3s-server-3 6.4.7-200.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Jul 27 20:01:18 UTC 2023 x86_64 GNU/Linux
Linux k3s-agent-1 6.4.7-200.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Jul 27 20:01:18 UTC 2023 x86_64 GNU/Linux
Linux k3s-agent-2 6.4.7-200.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Jul 27 20:01:18 UTC 2023 x86_64 GNU/Linux
Linux k3s-agent-3 6.4.7-200.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Jul 27 20:01:18 UTC 2023 x86_64 GNU/Linux

(all using Fedora CoreOS)

Cluster Configuration:
3 servers, 3 agents

Describe the bug:
Using --disable-helm-controller on k3s server deployments also disables Traefik. This doesn't seem to be documented anywhere.

Steps To Reproduce:

1. Bootstrap an initial k3s server using `curl -sfL https://get.k3s.io | K3S_TOKEN=yourtoken sh -s server --cluster-init --disable-helm-controller
2. After server comes online, observe no traefik-controller in the kube-system namespace with: kubectl get pods -n kube-system

Expected behavior:
Disabling the Helm controller shouldn't disable Traefik, or it should be well documented that using this flag also disables Traefik. It should be possible to still have Traefik installed via manifests instead of relying on the Helm chart.

Actual behavior:
Traefik is disabled along with the Helm controller.

The reason I disabled the Helm controller is that in some circumstances it can conflict with the Flux CD Helm controller which I rely upon.

[brandond]

Disabling the Helm controller shouldn't disable Traefik, or it should be well documented that using this flag also disables Traefik. It should be possible to still have Traefik installed via manifests.

We're not going to package it twice. It is expected that anyone disabling built-in controllers would understand the impact of doing so, but I suppose we could call out in the docs more explicitly that disabling the Helm controller will remove the built-in ability to install things packaged as helm charts.

in some circumstances it can conflict with the Flux CD Helm controller which I rely upon

In what circumstances specifically? They do not use the same CRDs or anything; I'm confused as to how they would conflict unless you specifically try to manage something via both our controller and flux at the same time.

[comminutus]

@brandond I understand that disabling the Helm controller would disable any Helm-deployed packages provided by k3s, but I didn't see anywhere in the documentation that mentions Traefik is deployed via Helm.

The conflict between fluxcd Helm controller and the k3s one is mentioned in there documentation here: https://fluxcd.io/flux/cheatsheets/troubleshooting/#getting-basic-information

HelmCharts and HelmReleases CRDs conflict with other Helm controllers

When a HelmRelease exhibits the issue HelmChart 'podinfo/podinfo-podinfo' is not ready, a common issue on k3s clusters or other environments that bundle a different Helm controller is caused by a conflict between these CRDs when they are used without fully qualifying.

For example: kubectl get helmcharts can access the wrong CRD and users may be fooled into thinking that a HelmChart resource was not created successfully. To avoid this issue, use the alternative flux get source chart or fully qualify when using kubectl get as shown above.