deepflowio
[BUG] deepflow does not show namespaces and workloads
Search before asking
- [X] I had searched in the issues and found no similar feature requirement.
DeepFlow Component
Grafana Dashbaord
What you expected to happen
The namespaces and workloads are not showing on the dashboards, although there is data on the dashaboards.
How to reproduce
Just installed 6.4
DeepFlow version
Deepflow 6.4
DeepFlow agent list
No response
Kubernetes CNI
No response
Operation-System/Kernel version
GCP GKE
Anything else
No response
Are you willing to submit a PR?
- [ ] Yes I am willing to submit a PR!
Code of Conduct
- [X] I agree to follow this project's Code of Conduct
It seems this is an old issue. If the problem still exists, you can communicate with us here (or on Discord). @dundun9, please pay attention to this issue and see if you can provide some insights.
@dundun9 @sharang
I also have the same problem. After the first deployment, the namespace and workload appear very slowly, and only the relevant indicators of non host network workloads will appear. I found that the workload using host network will not be displayed. Is there a plan to support this in the new version
@dundun9 @sharang I also have the same problem. After the first deployment, the namespace and workload appear very slowly, and only the relevant indicators of non host network workloads will appear. I found that the workload using host network will not be displayed. Is there a plan to support this in the new version
@yhcloud123 In v6.4, we have supported the AutoTagging of Kubernetes Pod/Workload/Namespace/Cluster tags for HostNetwork Pod eBPF data, which are calculated using PID (rather than IP). However, for Packet data collected through cBPF, since we can only use IP to calculate tags, it's impossible to determine the data ownership of HostNetwork Pods (as they communicate using the Kubernetes Node's IP address).
Furthermore, even though we can automatically inject Kubernetes tags into eBPF data, the current solution is not perfect. When observing communication with a HostNetwork Pod on the server side from a client, the server-side Kubernetes labels cannot be marked because the client does not know the server's PID.
Fortunately, a perfect solution does exist, and we have already made some progress (reference: https://github.com/deepflowio/tcp-option-tracing). We have developed an eBPF program that can inject the PID information of both communication parties into the TCP Option. However, since this behavior is intrusive (it changes the TCP Option), we are cautiously looking for users who are willing to use this feature. If you are interested in this feature, you can submit a Feature Request to us, and we will integrate TOT into the main program of DeepFlow.