Cannot enable Hubble if Cilium is originally deployed with Hubble disabled #959
Comments
|
the error looks similar, we have a few fixes below, but it's might not fix for hubble enable CLI. Can you give it a crack with latest master branch and confirm if the issue is resolved ? Thanks. |
|
Hi @sayboras I am not the issue author, but I had the same error when installing cilium with helm. Latest main doesn't seem to solve it: |
|
Confirmed that it's still happening, just curious if any of you both is planning to contribute. Thanks. |
sayboras
added
help wanted
|
@sayboras I would love to! I already tried this earlier and have This is my current state: |
|
Thanks for your help on this, feel free to reach out in Cilium OSS #development channel if you have any questions. |
when cilium initially was not installed wih cilium-cli. In these cases `cilium-cli-helm-values` secret does not exist and all `cilium hubble` commands fail. Since hubble components are cherry-picked from the generated helm manifests, it should be safe to proceed without the full helm values state if we can retrieve the cilium version running in the cluster. We should not write the new helm state to the cluster so that if in the future other components need to use it, we don't inadvertently override real installation parameters. Fixes: cilium#959 Signed-off-by: Olga Mirensky <[email protected]>
… not exist This commit fixes hubble enable and disable commands which are broken when cilium initially was not installed with cilium-cli. In these cases `cilium-cli-helm-values` secret does not exist and all `cilium hubble` commands fail. Since hubble components are cherry-picked from the generated helm manifests, it should be safe to proceed without the full helm values state. We should not write the new helm state to the cluster so that if in the future other components need to use it, we don't inadvertently over shadow real installation parameters. Fixes: cilium#959 Signed-off-by: Olga Mirensky <[email protected]>
|
@olga-mir, I have problem too, But I think if you use helm upgrade cilium cilium/cilium --version 1.12.1 \
--namespace kube-system \
--reuse-values \
--set hubble.relay.enabled=true \
--set hubble.ui.enabled=truehope to help you |
I follow the official guide to install cilium on kind and met a similar problem |
|
@misstick86, I agree with you, with some remarks.
It's up to the implementation. The draft PR that I have opened does not store the values back to the secret (which did not exist in this scenario) so it doesn't introduce any new default values that may have been set to something different at installation time. It did create inconsistency with I am not a maintainer, but I think that even if the issue is fixed without adding non-hubble values to the secret or the configmap, it still creates a drift in hubble related values which is not ideal. Running Also note, the longer term vision for cilium cli to be a smart wrapper on helm install/upgrade as per this comment, so it'll eventually be fixed anyway: #1020 (comment) |
… not exist This commit fixes hubble enable and disable commands which are broken when cilium initially was not installed with cilium-cli. In these cases `cilium-cli-helm-values` secret does not exist and all `cilium hubble` commands fail. Since hubble components are cherry-picked from the generated helm manifests, it should be safe to proceed without the full helm values state. We should not write the new helm state to the cluster so that if in the future other components need to use it, we don't inadvertently over shadow real installation parameters. Fixes: cilium#959 Signed-off-by: Olga Mirensky <[email protected]>
… not exist This commit fixes hubble enable and disable commands which are broken when cilium initially was not installed with cilium-cli. In these cases `cilium-cli-helm-values` secret does not exist and all `cilium hubble` commands fail. Since hubble components are cherry-picked from the generated helm manifests, it should be safe to proceed without the full helm values state. We should not write the new helm state to the cluster so that if in the future other components need to use it, we don't inadvertently over shadow real installation parameters. Fixes: #959 Signed-off-by: Olga Mirensky <[email protected]>
|
Not fixed :/ |
|
Not fixed in cilium install --version=1.13.0 --helm-auto-gen-values cilium-helm-values-install.yaml \
--helm-set ipam.mode=cluster-pool \
--helm-set ipam.operator.clusterPoolIPv4PodCIDRList="10.252.0.0/15" \
--helm-set tunnel="geneve" \
--helm-set ipv4NativeRoutingCIDR="10.252.0.0/15" \
--helm-set bgpControlPlane.enabled=true \
--helm-set k8s.requireIPv4PodCIDR=true \
--helm-set device="snyderedge-p" \
--helm-set cluster.name="snyderedge" \
--helm-set cluster.id=1 \
--helm-set tag="v1.13.0" \
--helm-set kubeProxyReplacement="strict" \
--helm-set bgpControlPlane.enabled=true \
--helm-set k8s.requireIPv4PodCIDR=true \
--helm-set hubble.ui.enabled=true \
--helm-set hubble.relay.enable=true \
--helm-set clustermesh.useAPIServer=true \
--helm-set clustermesh.apiserver.enabled=true \
--helm-set clustermesh.apiserver.tls.auto.method=certmanager
cilium install --version=1.13.0 --helm-values cilium-helm-values-install.yamlResult: ~/: cilium install --version=1.13.0 --helm-values cilium-helm-values-install.yaml
🔮 Auto-detected Kubernetes kind: K3s
ℹ️ Using Cilium version 1.13.0
🔮 Auto-detected cluster name: default
🔮 Auto-detected datapath mode: tunnel
⚠️ Unable to list kubernetes api resources, try --api-versions if needed: %!w(*fmt.wrapError=&{failed to list api resources: unable to retrieve the complete list of server APIs: metrics.k8s.io/v1beta1: the server is currently unable to handle the request 0x14000da8140})
ℹ️ helm template --namespace kube-system cilium cilium/cilium --version 1.13.0 --set bgpControlPlane.enabled=true,bpf.masquerade=true,cluster.id=1,cluster.name=snyderedge,clustermesh.apiserver.enabled=true,clustermesh.apiserver.tls.auto.method=certmanager,clustermesh.useAPIServer=true,device=snyderedge-p,encryption.nodeEncryption=false,hubble.relay.enable=true,hubble.ui.enabled=true,ipam.mode=cluster-pool,ipam.operator.clusterPoolIPv4PodCIDRList=10.252.0.0/15,ipv4NativeRoutingCIDR=10.252.0.0/15,k8s.requireIPv4PodCIDR=true,kubeProxyReplacement=strict,operator.replicas=1,serviceAccounts.cilium.name=cilium,serviceAccounts.operator.name=cilium-operator,tag=v1.13.0,tunnel=geneve
↩️ Rolling back installation...
Error: Unable to install Cilium: execution error at (cilium/templates/validate.yaml:4:7): Hubble UI requires .Values.hubble.relay.enabled=true |
|
Hi @ensonic the output you posted shows that the feature actually worked But thanks for bringing this up to my attention, I can see how it might be confusing for the end user. |
|
@benpsnyder I don't think this error is related to cilium-cli. The output shows Also please note that for the purpose of this bug what important is version of the cilium-cli, not necessarily the cilium installation itself. If you have further queries can you please post output of |
… not exist This commit fixes hubble enable and disable commands which are broken when cilium initially was not installed with cilium-cli. In these cases `cilium-cli-helm-values` secret does not exist and all `cilium hubble` commands fail. Since hubble components are cherry-picked from the generated helm manifests, it should be safe to proceed without the full helm values state. We should not write the new helm state to the cluster so that if in the future other components need to use it, we don't inadvertently over shadow real installation parameters. Fixes: cilium#959 Signed-off-by: Olga Mirensky <[email protected]>
Bug report
General Information
cilium version)kubectl version, ...)How to reproduce the issue
--set operator.replicas=1 --set hubble.enabled=false. Here's the full command.kubectl apply -f cilium-resources.yamlOnce Cilium is up and running, run
cilium hubble enable. The following error will occur:I would expect to be able to enable hubble even if the initial installation setting was
hubble.enabled=false.The text was updated successfully, but these errors were encountered: