-
Notifications
You must be signed in to change notification settings - Fork 244
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for SockLB events #816
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So these are displayed by default right? I wonder: should they be?
I would argue they should. The service IP is not visible anywhere otherwise. Before SockLB was a thing, Hubble would show the clusterIP in |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🚀
Somehow GitHub seems to be stuck on the status checks. Closing an re-opening. |
1a5b658
to
fb779fc
Compare
This pulls in the new Hubble API definitions for SockLB events. Signed-off-by: Sebastian Wicki <sebastian@isovalent.com>
This adds support for Trace SockLB events. These events are similar to L3/L4 trace events, but are traced on the socket level. This means they have a few differences to regular trace events: - There are events for pre- and post-translation. This means that we now get visibility into the service load balancing, meaning that source/destination service is populated before NAT/after rev-NAT. - These events do not contain the source port or packet related details (such as TCP flags, Ethernet headers etc). - Because the events are emitted on a socket level, there is no meaningful traffic direction or reply status. The reply status and traffic direction of the trace sock events is unknown. - These events have two verdicts: TRACED and TRANSLATED. The former is used when ever the SockLB BPF hook is executed, the latter is additionally emitted if NAT or reverse NAT has been applied. Signed-off-by: Sebastian Wicki <sebastian@isovalent.com>
fb779fc
to
9dfd1d5
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @gandro!
This adds support for Trace SockLB events. These events are similar to L3/L4 trace events, but are traced on the socket level. This means they have a few differences to regular trace events:
Here is an example of
![image](https://user-images.githubusercontent.com/50564/202198457-43ace6ed-f8b7-4683-8140-4654c310ea6e.png)
pod-to-a
pod doing a service lookup for theecho-a
service (first the DNS lookup against kubedns, then a TCP connection to theecho-a
service):