hubble: --namespace is incompatible with --pod
Currently, it is not possible to give --namespace along with --pod to hubble.
% hubble observe --from-namespace cilium --from-pod hubble-relay
invalid argument "hubble-relay" for "--pod" flag: filters --from-namespace and --pod cannot be combined
An alternative way to express this is the following:
% hubble observe --from-label io.kubernetes.pod.namespace=cilium --from-pod hubble-relay
The issue with this is that --from-pod hubble-relay is implicitly referring to the hubble-relay pod in the default namespace. Here I would expect to see the the Flows from the cilium/hubble-relay pod.
About this issue
- Original URL
- State: open
- Created 4 years ago
- Reactions: 1
- Comments: 18 (16 by maintainers)
I’d be happy to work on this
Propositions
At a high level, make hubble cli more “intuitive” by behaving like
kubectlwith respect to namespace and pod selector flags.1. cli: --namespace along with --pod
Doesn’t work at the moment, we get:
proposition
Translate this into a
[source_pod:"cilium/hubble-relay"]FlowFilter. This is analog toFail with an error when we get an inconsistency between the namespace arg and pod arg, e.g.
--from-namespace cilium --from-pod default/hubble-relay.Also apply for destinations and services.
2. cli: handle the namespace label specifically
This is translated as
[source_pod:"hubble-relay" source_label:"io.kubernetes.pod.namespace=cilium"]which won’t ever yield any flow as thesource_podpart is equivalent todefault/hubble-relay.proposition
translate this into either:
[source_pod:"cilium/hubble-relay"][source_pod:"cilium/hubble-relay", source_label:"io.kubernetes.pod.namespace=cilium"]Additionally, lookout for inconsistencies between
--from-label io.kubernetes.pod.namespace=cilium,--from-namespace, and--from-pod.Also apply for destinations and services.
3. cli: namespace consistency between --from-pod and --from-service
currently translate into
[source_pod:"kube-system/hubble-relay" source_service:"default/hubble-relay"]which won’t ever yield any flow.proposition
Fail with an error when we get an inconsistency between the service arg and pod arg
Also apply for destinations.
4. FlowFilter
unlike the other proposition, this one will require some changes on the Hubble server side.
Force clients to always use the form
namespace/podforsource_pod,destination_pod. This mean that we’ll add thedefault/part on some queries, likehubble observe --from-pod hubble-relay. The form without slash (implicitdefault/) can be deprecated and kept for a while for backward compatibility’s sake.An empty name will act as wildcard. We already use this:
Is currently translated into
[source_pod:"cilium/"]which mean “every pod under the cilium namespace”.With that scheme it is easy to design a
--all-namespaceflag akin to kubectl as @glibsm suggested:Will be translated into
[source_pod:"/hubble-relay"]To query all pods in all namespaces, we would have
[source_pod:"/"]. As for the implicitdefault/we can keep the current FlowFilter[]compatible for a while.Also apply for destinations and services.
I started looking into this and started an MVP for option 4. So far I think everything seems to mostly work as expected. At the moment I believe the behavior is completely backwards compatible, because the new behavior is only in effect when using the pod and namespace filters together, which was previously not allowed via CLI.
Branches:
The main thing I think is worth noting is that if you only specify the pod filters, then it uses the existing behavior, and if you specify namespace filters it will ignore the namespace portion of the pod filters. Additionally, when you use the namespace flags with the Hubble CLI, it sets both pod filters, and namespace filters. Combined, this means that the server uses the new behavior only when both pod and namespace filters are specified together. The server never supported namespace flow filters prior to this change, so the new filters will be ignored on old versions of Cilium, meaning the old behavior will be retained. If you try using both
--podand--namespacetogether on an older version of Hubble, then it will basically ignore the--namespaceand act as--pod default/<pod_name>.As a future step, the client and server could negotiate to determine which behavior to use, or the server could simply deprecate the use of namespace in pod filters, and eventually remove it, leaving only the new behavior.
Some example raw filter output:
And agent logs for each with some extra printlns indicating “how” it’s filtering, using the some commands as above:
@kAworu All of this makes a lot of sense to me. I especially like that you came up with a backward-compatible solution for
--all-namespacesin 4!Minor comment: I strongly believe that
hubble observe --from-label io.kubernetes.pod.namespace=cilium --from-pod hubble-relayshould be translated to[source_pod:"cilium/hubble-relay", source_label:"io.kubernetes.pod.namespace=cilium"], i.e. the label filter should be preserved it the user specified it to avoid any surprises.