Support for eBPF based port forwarding

[balajiv113]

Improve port forwarding by using ebpf

Note: Test run. Locally it works. Wanted to confirm with all jobs

[AkihiroSuda]

Needs rebase

[AkihiroSuda]

What's the current status?

[balajiv113]

Am facing issues with kubernetes when I last worked. Not able to derive a common solution there as they are removing all entries and recreating iptables.

If we use kube api for kubernetes similarly we will have to do for others as well. Then this ebpf overall will be useful only for guest agent binds

[AkihiroSuda]

Duplicating the comments about the current state of the PR

---

@jandubois & @AkihiroSuda

On the eBPF PR this is the current state,

• guest direct ports are working perfectly without issues
• docker/ containers with nftables was able to get it working (need to see if it works for all cases)
• But with respect to kubernetes I got no luck. As I previously mentioned kubernetes are removing all entries in iptable and reconstructing back due to this we couldn't identify missing one's properly.

Originally posted by @balajiv113 in #4021 (comment)

---

• docker/ containers with nftables was able to get it working (need to see if it works for all cases)

Thanks, that sounds promising!

So what I remember about some distros not having the prerequisite kernel modules, or missing permissions, was not, or is no longer correct?

Originally posted by @jandubois in #4021 (comment)

---

So what I remember about some distros not having the prerequisite kernel modules, or missing permissions, was not, or is no longer correct?

I was able to solve it using kprobe. This is available in almost all distro I checked.

Even our FT were passing except docker that's when it hit the kubernetes issue

Originally posted by @balajiv113 in #4021 (comment)

---

The combination of @balajiv113 's eBPF PR (#3067) w/ the existing kubernetesservice watcher seems the most robust and compatible solution for now?

I wish we could remove the dependency on Kubernetes client libraries, but it can be discussed separately in future.

Originally posted by @AkihiroSuda in #4021 (comment)

[AkihiroSuda]

The binary blobs such as https://github.com/balajiv113/trackport/blob/main/pkg/internal/bpftracker/bpf_arm64_bpfel.o have to be removed

[balajiv113]

Those are actually needed it will be embedded in go logics

[jandubois]

Can we compile them from source in the Lima repo?

[balajiv113]

Yes yes that's the ultimate goal after it's all good.

[balajiv113]

I will clean up stuff and verify it again and see if all still holds good.

[AkihiroSuda]

It might be even fine to just execute the bpftrace command to stimulate the ticker, if the go build stuff is too complicated

lima/cmd/lima-guestagent/daemon_linux.go

Lines 57 to 63 in 7459f45

	newTicker := func() (<-chan time.Time, func()) {
	// TODO: use an equivalent of `bpftrace -e 'tracepoint:syscalls:sys_*_bind { printf("tick\n"); }')`,
	// without depending on `bpftrace` binary.
	// The agent binary will need CAP_BPF file cap.
	ticker := time.NewTicker(tick)
	return ticker.C, ticker.Stop
	}

[balajiv113]

We can do that as a temp solution.

If we use ebpf then i wanted to avoid parsing the proc file again. As this will add further delay only in forwarding. But identifying ip and ports just by using bpftrace its hard. we need multiple variations. That's where using celium helped to write down our logics

[jandubois]

But identifying ip and ports just by using bpftrace its hard. we need multiple variations.

This sounds like it is not really a generic solution and requires custom rules for each container runtime.

I wonder how much latency parsing the proc file is adding; maybe it is not noticeable?

As long as we manage to close the port forwarding before a new container can reopen the port, we should be fine. I guess we can do some stress-testing to see how it works.

[AkihiroSuda]

To simplify https://github.com/balajiv113/trackport/tree/main/pkg/internal/bpftracker , can we keep the existing collectEvent() for now, and use eBPF only for stimulating the ticker on kretprobe of bind(2) ?

[balajiv113]

Yes yes will do that.

I wanted to purely use eBPF because fentry and fexit will wait for the eBPF logic to complete.

So I wanted to verify if the UDP forwarding issue is resolved in that case

[AkihiroSuda]

Alternative PR

• guestagent: ticker: watch sys_exit_bind with eBPF #4066