Add Retina CLI command to create ephemeral container with network debugging tools

[wedaly]

Is your feature request related to a problem? Please describe.

I want to be able to do adhoc, exploratory debugging of node and pod networking.
 
Describe the solution you'd like

kubectl retina sh pods/<pod>
kubectl retina sh nodes/<node>

• Start an ephemeral container in the specified node or pod.
• Use an image based on Azure Linux with built-in networking tools (ping, curl, nslookup, tcpdump, conntrack, iproute2, iptables, etc.). If the cluster is using Retina, then it should already have firewall configuration to download this new image from the same source as the other Retina images.
• Run an interactive shell (bash).
• Assign the appropriate permissions to ensure the tools work (NET_ADMIN and NET_RAW).
• (Optionally) mount host filesystem for inspecting CNI logs, which iptables executable is installed on the host, etc. Make this opt-in (--mount-host-filesystem flag) since most network troubleshooting doesn't need it.

Future work could expand this to support Windows (image with PowerShell, use host process containers for node access), but to start I care most about Linux support.

Describe alternatives you've considered

• Node-shell gives full access to the node using "nsenter" on PID 1.
  • Overprivileged: Starts privileged pods on customer nodes (CAP_SYS_ADMIN and access to /proc filesystem).
  • Alpine Image: Defaults to an alpine image from DockerHub that is often blocked by customer firewalls or subject to DockerHub rate limits. Can override this using an env var, but still requires an image with nsenter installed (and Azure Linux 2.0+ do not have it installed).
  • No pod debugging: Cannot easily debug connectivity from within a pod network namespace. Users can find the netns for a pod, then use ip netns exec, but this is painful and error-prone.
• Kubectl exec allows us to execute a process within a pod's namespace.
  • Pod image missing tools: Pod images may lack networking tools or even a shell (more common now with distroless images).
  • Host networking: If there's no host networking pod, we can't test connectivity from node IP.
  • Pod crashing: If the target pod is crashing, we cannot exec into it.
• Kubectl debug creates ephemeral containers to get access to either a node or a pod. It provides "profiles" with different levels of permission.
  • Missing tools: Requires an image with network debugging tools installed. A popular image is netshoot, but there isn't currently an equivalent image in MCR. People often fallback to running Azure Linux and manually installing whatever packages they need, which is slow and tedious.
  • Confusing permissions: the "general" profile provides access to the node filesystem, but not NET_ADMIN capability required for iptables/nftables, leading to misleading permissions errors like Permission denied (you must be root) even for the root user. kubectl with k8s 1.27 and later have "netadmin" profile that grants NET_ADMIN capability, but not access to host filesystem.

Additional context

Retina has a unique opportunity to overcome the limitations for the other tools listed above. If people are already using Retina for monitoring/observability, then it would be very convenient to also use it for adhoc network debugging.

This would also pair well with Retina's existing packet capture command. I often find myself starting a packet capture, then using kubectl exec / kubectl debug to reproduce an issue. It would be really nice to do this without needing a separate tool.

[wedaly]

Here's a feature branch with an initial implementation: main...wedaly:retina:retina-shell-feature-branch

I'll open separate PRs for each of the three commits in order (creating the image, publishing with GH workflows, and adding the CLI command).