microsoft / retina

eBPF distributed networking observability tool for Kubernetes
https://retina.sh
MIT License
2.7k stars 205 forks source link

Helm installation does not reflect helm's --namespace argument, but hardcodes kube-system (or rather hides it in the values.yaml) #731

Open kastl-ars opened 1 month ago

kastl-ars commented 1 month ago

Describe the bug Normally one can install a helm release into a discrete namespace by using helm install --namespace foo ....

This does not work with the retina chart, as it puts the helm release into that namespace, but the resources into the kube-system namespace.

e.g. https://github.com/microsoft/retina/blob/main/deploy/legacy/manifests/controller/helm/retina/values.yaml#L47

If there is a technical reason for doing so, this should be documented. If not, this should be fixed to get the usual behaviour.

To Reproduce Steps to reproduce the behavior:

  1. Install using the following command:
helm upgrade --install retina oci://ghcr.io/microsoft/retina/charts/retina \
    --namespace retina \
    --create-namespace \
    --version $VERSION \
    --namespace kube-system \
    --set image.tag=$VERSION \
    --set operator.tag=$VERSION \
    --set logLevel=info \
    --set enabledPlugin_linux="\[dropreason\,packetforward\,linuxutil\,dns\]"
  1. Issue helm ls -n retina and find the release there, but no pods or daemonsets (as kubectl get pod,ds -n retina shows)
  2. Check for daemonsets in the kube-system namespace using kubectl get pod,ds -n kube-system
  3. Voilá!

Expected behavior The chart should respect helm's --namespace argument

Platform (please complete the following information):

kastl-ars commented 1 month ago

In addition, the operator daemonset always gets deploy to kube-system, even if its configMap is created in e.g. the retina namespace.

https://github.com/microsoft/retina/blob/main/deploy/legacy/manifests/controller/helm/retina/templates/operator.yaml#L6