Using LoxiLB in a reverse proxy manner? #970
Replies: 5 comments 3 replies
-
|
Similar stuff: https://github.com/FyraLabs/chisel-operator |
Beta Was this translation helpful? Give feedback.
-
|
Here’s an idea for leveraging eBPF, which should integrate well with LoxiLB. The process begins with the LoxiLB master probing the Kubernetes nodes' IP addresses by performing a basic connectivity test, such as a port ping. For example, if we have a public-facing LoxiLB server at IP 2.2.2.2 and a Kubernetes node behind NAT at IP 192.168.2.1, LoxiLB will try to connect to 192.168.2.1:8888 if the service is listening on port 8888. If the ping test succeeds, LoxiLB operates in its normal mode. However, if the test fails or the node is labeled as "reverse proxy needed," the node is marked to run in "passive mode" (reverse proxy mode). In this mode, LoxiLB does not attempt to connect directly to the node’s endpoints, as it assumes they are unreachable. Instead, a "virtual circuit" is established between the LoxiLB server and the node. For instance, if the Kubernetes cluster exposes a load balancer service named "foo" on port 8081, the LoxiLB master will listen on port 8081. Normally, traffic to 2.2.2.2:8081 would be routed to 192.168.2.1:8081. However, since direct connectivity is unavailable, LoxiLB creates a proxy on another port, such as 2.2.2.2:9999, and instructs the Kubernetes node at 192.168.2.1 to connect to this proxy port. On the eBPF side, the LoxiLB master intercepts all incoming requests and redirects them to 2.2.2.2:9999. This redirection happens in-kernel, potentially using zero-copy techniques to make it efficient and transparent to the application. Meanwhile, on the Kubernetes node, eBPF handles the connection to 2.2.2.2:9999 and pipes the data back and forth between 192.168.2.1:8081 and 2.2.2.2:9999. The eBPF implementation ensures that the socket address pairs are transparently overwritten, making the process non-invasive, i.e. a reverse proxy using the butterfly network pipe scheme. The flow works as follows:
This approach is inspired by how Cilium handles eBPF proxying, and it seems feasible for LoxiLB to implement something similar. While this is a starting point, there may be ways to simplify the scheme further. |
Beta Was this translation helpful? Give feedback.
-
|
Hello, I found your suggestion very insightful. Indeed, in an environment like yours, LoxiLB currently has some limitations unless tunneling or similar configurations are set up. Currently, LoxiLB does support reverse proxy mode but this use-case would require some tweaks. Although it was not originally planned in our roadmap, I believe it is possible to implement this solution by leveraging LoxiLB’s existing functionalities, as you suggested. I will discuss this with loxilb maintainers and review whether we can add this to our roadmap. Thank you for your suggestion. |
Beta Was this translation helpful? Give feedback.
-
|
This will be a super useful addition to loxilb. Loxilb implements eBPF.sockmap which could make it even more interesting. Nonetheless I would like to analyze the security aspects of it.These are the points that I would like to ponder about:
Overall, I think it is doable, will add value and might be a good use-case of sockmap constructs. |
Beta Was this translation helpful? Give feedback.
-
Integrating this feature into LoxiLB would be highly beneficial. I have achieved something similar with Cilium, leveraging its Load Balancer IPAM, which is based on eBPF and socket rewrites (and possibly eBPF sockmap, though I haven’t explored that in depth). My primary use case for using Cilium as a load balancer is for game servers, which demand high performance and minimal overhead. The setup I implemented with Cilium delivers satisfactory results, offering low jitter and overhead. While the initial connection takes slightly longer, the overall performance is significantly better compared to a userspace proxy, which typically introduces much higher overhead, because it involves a lot of kernel context switches and memory consumption. Although my focus has been on game servers, I believe this approach can be generalized to other applications. For instance, as someone who also runs a couple of homelabs and controls virtual servers all around the world, I recently experimented with similar setups for database solutions like PostgreSQL and MySQL, and the results have been pretty promising, in the sense that I tried to build a PaaS off of this idea. |
Beta Was this translation helpful? Give feedback.
-
I believe this functionality could be considered as an optional feature for future development. However, at the current stage, it would be more practical to focus on keeping the proxy as a straightforward, "dumb pipe" to ensure simplicity and efficiency. From what I understand, similar capabilities can be achieved using Envoy in L7 by using mTLS or similar plugins, but its implementation is primarily tailored to HTTP-based protocols. This limitation raises questions about its applicability to TCP/L4 constructs, as its support for these layers is less clear. Furthermore, Envoy does not currently support UDP transparent proxy, which makes the inclusion of such a feature in the future particularly valuable. Expanding support to include UDP transparent proxy would address this gap and enhance the versatility of the proxy for a wider range of use cases.
I believe this feature could also be incorporated as that optional feature, as mentioned earlier, by leveraging TLS support to address the security concerns related to confidentiality and integrity, though it would not mitigate availability issues due to port blocking and DPI, where we currently do not have effective solutions for in a broad sense either. Prioritizing efforts to demonstrate the feasibility and effectiveness of having a raw reverse proxy socket rewrite would be highly beneficial for LoxiLB in the long term. This is particularly significant given that LoxiLB is one of only five public and open-source load balancer solutions currently available that I know of, and notably, one of just two that utilize eBPF technology heavily out in the public. Establishing its reliability and showcasing its unique capabilities would further solidify its position as a leading solution in the load balancing space. |
Beta Was this translation helpful? Give feedback.
-
|
I am prioritizing this as an enhancement request in our roadmap due to its value. |
Beta Was this translation helpful? Give feedback.
-
|
Feature request has been updated here |
Beta Was this translation helpful? Give feedback.
-
I currently have a couple of homelab servers that are located behind a NAT (Network Address Translation) setup, which means they don’t have public IP addresses for handling incoming connections. This makes it challenging to expose services running on these servers to the internet directly.
To address this, I’m considering using LoxiLB, an external load balancer, as part of my solution. My plan is to purchase a few VPS (Virtual Private Server) instances from providers like Vultr or DigitalOcean, which come with public IP addresses. These VPS servers would act as the public-facing nodes for my homelab servers. The idea is that my homelab servers would connect to the LoxiLB master instance running on one of these VPS servers, enabling load balancing across my homelab servers.
However, I ran into an issue when testing this setup. It seems that LoxiLB is attempting to connect directly to the internal IP addresses of my homelab servers using the service port. At this point, I haven’t yet established any private network links between my VPS servers and my homelab servers, so this connection attempt fails.
I’m thinking that setting up a WireGuard VPN might solve the problem by creating a secure private network between my homelab servers and the VPS servers. But I’m also wondering if LoxiLB can operate in a reverse proxy mode instead. If LoxiLB could work as a reverse proxy, I wouldn’t need to set up WireGuard, which would simplify the setup significantly. It would also make it easier to share the load balancer across other Kubernetes clusters I manage.
My goal is to keep the network topology as simple and maintainable as possible. I don’t want to introduce unnecessary complexity, as that would make the system harder to manage in the long run. This approach could also benefit other small business users like me by enabling them to operate private clusters for their clients without the hassle of dealing with complex IP allocation or requiring public IPs for every node.
Beta Was this translation helpful? Give feedback.
All reactions