-
Notifications
You must be signed in to change notification settings - Fork 53
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
Feature Request - Integrate Retina.sh
~> Capture
Feature in AKS VS Code Extension.
#569
Comments
I'm keen to aim towards (not immediately, but as a future ideal) an experience where the user flow goes something like:
Does that fit with your thoughts, @sprab? I have concerns about the entry point being the specific tool we're using, because that feels like the reverse flow, and can lead to user confusion around which tool they should be using. Obviously we need to find ways to work towards that end goal in manageable chunks of work, and it is not realistic at this stage to build a scenario-based diagnostics tool that abstracts away the tooling. But I think keeping the end goal in mind is important, because we need to track whether we're moving towards it or away from it, and I worry that putting the tools (like retina) as the entrypoints to the experience will create more work for us in the future. My preference at this stage would be to incorporate retina into the existing tcp dump experience. That way, we have at least part of the scenario->action->tool flow:
That would also minimize the risk of causing confusion for users: "why do I have two commands for running packet captures?" |
@peterbom - the network troubleshooting workflows is not a replacement of tcpdump. IMHO we should preserve the tcpdump tool as is to allow customers to capture traces and analyze them. The networking troubleshooting scenario would leverage the tcpdump and/or retina. The workflow that I am thinking of is (soon I will provide a pictorial workflow of this) to first create problem identifiers viz. missing udr, custom dns servers, nsg changes, route changes, firewall changes etc and then combine/order them in a workflow to narrow down. We can then list the scenarios and the order in which these tools can be run. |
I agree with @sprab here, Retina distributed captures is not trying to replace tcpdump, instead it is making it extremely intuitive to use kubernetes language for packet capturing interested traffic in multiple nodes at once. For example:
Retina will figure out on which nodes the pods with kube-dns (corens) label in namespace kube-system are running, what are their IPs and will simultaneously start a capture in all those nodes with those interested IPs, this was rest of the traffic is untouched and secure, admin gets all the relevant captures from all nodes at once with single click, and admin will not have to time it together by running different terminals at once. |
I agree - I was thinking it would include, but not be limited to, packet capture (using tcpdump and/or Retina). But the overall network troubleshooting project is more of a future thing, and we're hoping to incorporate Retina in the shorter term. Am I getting this right?
I'm actually not totally sure about this. You say:
That's exactly what we've been trying to achieve with the tcpdump functionality (although not very well with the multiple nodes part). I see a lot of overlap here, and Retina looks to me as if it provides almost a superset of what we've already built. |
more platforms for kubectl-retina published in the latest release https://github.com/microsoft/retina/releases/tag/v0.0.2 |
Nice and thanks @rbtr , pretty cool, now we can make download as part of initial vscode drop across different OS et. al.. ❤️🙏 |
💡☕️ Proposal for a feature to integration Retina.sh - Capture command for Network Packets. - https://retina.sh
Enable Network Observability, AKS Dev Experience, as part of this here is proposal enabling Retina.sh Capture feature vis VsCode Extension.
Retina capture command allows the user to capture network traffic and metadata for the capture target, and then send the capture file to the location by Output Configuration.
To conceptualise this aspects specifically for this proposal.
cc: @peterbom, @sprab, @gambtho fyi...
How/ What / Where:
Given we have now few network diagnostic / user experience / dev-ops / runoffs experience, we should bundle this into dedicated men-item with submenu options of:
Implementation level raw detail:
Capture Details:
Retina Capture allows users to capture network traffic/metadata for the specified Nodes/Pods.
Captures are on-demand and can be output to the host filesystem, a storage blob, etc.
More detail here: https://retina.sh/docs/captures/
Steps to install:
Vscode first will download latest release - we can leverage similar mechiains,m we do for Inspector Gadget tool from this: https://retina.sh/docs/installation/cli
Option 1 aka download binaries from there: https://github.com/microsoft/retina/releases/tag/v0.0.1
Open Question: Currently I only see the Linux node support only and kubectl-retina-linux-amd64 - so is this one for all operating system? or other OS will come as time will go? Reference update: 💡 Proposal to support other O/S arch binaries for release artefacts for Retina. ☕️🥷 microsoft/retina#100
https://retina.sh/docs/captures/cli - Once we have the gadget we can then run it like
kubectl retina .. command
Scenarios It will benefit:
//
To Do...Retina.sh
~>Capture
Feature in AKS VS Code Extension. #569 (comment)Thanks.
The text was updated successfully, but these errors were encountered: