Skip to content

Commit

Permalink
Update index.md
Browse files Browse the repository at this point in the history
  • Loading branch information
@UltraInstinct14
UltraInstinct14 authored Jan 18, 2024
1 parent e384284 commit 045bee8
Showing 1 changed file with 59 additions and 50 deletions.
109 changes: 59 additions & 50 deletions docs/index.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -8,62 +8,71 @@
[stars-url]: https://github.com/loxilb-io/loxilb/stargazers

## Background
loxilb started as a project to ease deployments of cloud-native/kubernetes workloads for the edge. When we deploy services in public clouds like AWS/GCP, the services becomes easily accessible or exported to the outside world. The public cloud providers, usually by default, associate load-balancer instances for incoming requests to these services to ensure everything is quite smooth.
loxilb started as a project to ease deployments of cloud-native/kubernetes workloads for the edge. When we deploy services in public clouds like AWS/GCP, the services becomes easily accessible or exported to the outside world. The public cloud providers, usually by default, associate load-balancer instances for incoming requests to these services to ensure everything is quite smooth.

However, for on-prem and edge deployments, there is no *service type - external load balancer* provider by default. For a long time, **MetalLB** originating from Google was the only choice for the needy. But edge services are a different ball game altogether due to the fact that there are so many exotic protocols in play like GTP, SCTP, SRv6 etc and integrating everything into a seamlessly working solution has been quite difficult.
However, for on-prem and edge deployments, there is no *service type - external load balancer* provider by default. For a long time, **MetalLB** originating from Google was the only choice for the needy. But edge services are a different ball game altogether due to the fact that there are so many exotic protocols in play like GTP, SCTP, SRv6 etc and integrating everything into a seamlessly working solution has been quite difficult.

loxilb dev team was approached by many people who wanted to solve this problem. As a first step to solve the problem, it became apparent that networking stack provided by Linux kernel, although very solid, really lacked the development process agility to quickly provide support for a wide variety of permutations and combinations of protocols and stateful load-balancing on them. Our search led us to the awesome tech developed by the Linux community - eBPF. The flexibility to introduce new functionality into the OS Kernel as a safe sandbox program was a complete fit to our design philosophy. It also does not need any dedicated CPU cores which makes it perfect for designing energy-efficient edge architectures.
loxilb dev team was approached by many people who wanted to solve this problem. As a first step to solve the problem, it became apparent that networking stack provided by Linux kernel, although very solid, really lacked the development process agility to quickly provide support for a wide variety of permutations and combinations of protocols and stateful load-balancing on them. Our search led us to the awesome tech developed by the Linux community - eBPF. The flexibility to introduce new functionality into the OS Kernel as a safe sandbox program was a complete fit to our design philosophy. It also does not need any dedicated CPU cores which makes it perfect for designing energy-efficient edge architectures.

## What is loxilb

loxilb is an open source hyper-scale software load-balancer for cloud-native workloads. It uses eBPF as its core-engine and is based on Golang. It is designed to power on-premise, edge and public-cloud Kubernetes cluster deployments.

### 🚀 loxilb aims to provide the following :
- Service type load-balancer for kubernetes
* L4/NAT stateful loadbalancer
* NAT44, NAT66, NAT64 with One-ARM, FullNAT, DSR etc
* Support for TCP, UDP, SCTP (w/ multi-homing), QUIC, FTP, TFTP etc
* High-availability support with hitless/maglev clustering
* Full compliance for K8s loadbalancer Spec
* Multi-cluster support
- Extensive and scalable liveness probes for cloud-native environments
- High-perf replacement for the *aging* iptables/ipvs
- L7 parser support - HTTP1.0, 1.1, 2.0 etc
- Telco/5G/6G friendly features
* GTP tunnels as first class citizens
* LB support on various interfaces - N2, N4, E2 etc
* Optimized SRv6 implementation
* Support for UL-CL with LB, QFI and other utility extensions

### 🧿 loxilb is composed of:
- Bespoke GoLang based control plane components
- [eBPF](https://ebpf.io/) based data-path forwarding
* Home-grown stack with advanced features like [Conntrack](https://thermalcircle.de/doku.php?id=blog:linux:connection_tracking_1_modules_and_hooks), QoS etc
* Complete kernel networking bypass
* Highly scalable with low-latency & high-throughput
- GoLang powered easy to use APIs/Interfaces/CLI infra
- Seamless integration with goBGP based routing stack

### 📦 Why choose loxilb?

- ```Performs``` much better compared to its competitors across various architectures
* [Single-Node Performance](https://loxilb-io.github.io/loxilbdocs/perf-single/)
* [Multi-Node Performance](https://loxilb-io.github.io/loxilbdocs/perf-multi/)
* [Performance on ARM](https://www.loxilb.io/post/running-loxilb-on-aws-graviton2-based-ec2-instance)
* [Short Demo on Performance](https://www.youtube.com/watch?v=MJXcM0x6IeQ)
- ebpf makes it ```flexible``` and ```future-proof``` (kernel version agnostic and in future OS agnostic 🚧)
- Advanced quality of service for workloads (per LB, per end-point or per client)
- Includes powerful NG ```stateful firewalling``` and ```IPSEC/Wireguard``` support
- Optimized/Custom end-point ```liveness checks at scale```
- Support for ```5G/Edge``` cloud-native workloads
- Works with ```any``` Kubernetes distribution/CNI - k8s/k3s/k0s/kind/OpenShift + Calico/Flannel/Cilium/Weave/Multus etc
- Extensive support for ```SCTP workloads``` (with multi-homing) on k8s
- Dual stack with ```NAT66, NAT64``` support for k8s
- k8s ```multi-cluster``` support 🚧
- Runs in ```any``` cloud : public cloud (EKS), on-prem or multi-cloud environments

(*🚧: *Work in progress*)
loxilb is an open source cloud-native load-balancer based on GoLang/eBPF with the goal of achieving cross-compatibity across a wide range of on-prem, public-cloud or hybrid K8s environments.

## Kubernetes with loxilb

Kubernetes defines many service constructs like cluster-ip, node-port, load-balancer etc for pod to pod, pod to service and service from outside communication.

<img src="photos/K8sLoxiLB.jpg" width=50% height=50%>

All these services are provided by load-balancers/proxies operating at Layer4/Layer7. Due to Kubernetes's highly modular architecture, these services can be provided by different software modules. For example, kube-proxy is used to provide cluster-ip and node-port services by default.

Service type load-balancer is usually provided by public cloud-provider as a managed service. But for on-prem and self-managed clusers, there are only a few good options. <b>loxilb provides service type load-balancer as its main use-case</b>.

Additionally, loxilb can also support cluster-ip and node-port services and thereby providing end-to-end connectivity for Kubernetes.

## Why choose loxilb?

- ```Performs``` much better compared to its competitors across various architectures
* [Single-Node Performance](https://loxilb-io.github.io/loxilbdocs/perf-single/)
* [Multi-Node Performance](https://loxilb-io.github.io/loxilbdocs/perf-multi/)
* [Performance on ARM](https://www.loxilb.io/post/running-loxilb-on-aws-graviton2-based-ec2-instance)
* [Short Demo on Performance](https://www.youtube.com/watch?v=MJXcM0x6IeQ)
- Utitlizes ebpf which makes it ```flexible``` as well as ```customizable```
- Advanced ```quality of service``` for workloads (per LB, per end-point or per client)
- Works with ```any``` Kubernetes distribution/CNI - k8s/k3s/k0s/kind/OpenShift + Calico/Flannel/Cilium/Weave/Multus etc
- Extensive support for ```SCTP workloads``` (with multi-homing) on k8s
- Dual stack with ```NAT66, NAT64``` support for k8s
- k8s ```multi-cluster``` support (planned 🚧)
- Runs in ```any``` cloud (public cloud/on-prem) or ```standalone``` environments

## Overall features of loxilb
- L4/NAT stateful loadbalancer
* NAT44, NAT66, NAT64 with One-ARM, FullNAT, DSR etc
* Support for TCP, UDP, SCTP (w/ multi-homing), QUIC, FTP, TFTP etc
- High-availability support with hitless/maglev/cgnat clustering
- Extensive and scalable end-point liveness probes for cloud-native environments
- Stateful firewalling and IPSEC/Wireguard support
- Optimized implementation for features like [Conntrack](https://thermalcircle.de/doku.php?id=blog:linux:connection_tracking_1_modules_and_hooks), QoS etc
- Full compatibility for ipvs (ipvs policies can be auto inherited)
- Policy oriented L7 proxy support - HTTP1.0, 1.1, 2.0 etc (planned 🚧)

## Components of loxilb
- GoLang based control plane components
- A scalable/efficient [eBPF](https://ebpf.io/) based data-path implementation
- Integrated goBGP based routing stack
- A kubernetes agent [kube-loxilb](https://github.com/loxilb-io/kube-loxilb) written in Go

## Layer4 vs Layer7
loxilb works as a L4 load-balancer/service-mesh by default. Although it provides great performance, at times, L7 load-balancing/proxy might be necessary in K8s. There are many good L7 proxies already available for k8s. Still, we are working on providing a great L7 solution natively in eBPF. It is a tough endeavor one which should reap great benefits once completed. Please keep an eye for updates on this.

## Telco-Cloud with loxilb
For deploying telco-cloud with cloud-native functions, loxilb can be used as a SCP(service communication proxy). SCP is nothing but a glorified term for Kubernetes load-balancing. But telco-cloud requires load-balancing across various interfaces/standards like N2, N4, E2(ORAN), S6x, 5GLAN, GTP etc. Each of these interfaces present its own unique challenges(and DPI) for load-balancing which loxilb aims to solve e.g.
- N4 requires PFCP level session-intelligence
- N2 requires NGAP parsing capability
- S6x requires Diameter/SCTP multi-homing LB support
- MEC use-cases might require UL-CL understanding
- Hitless failover support might be essential for mission-critical applications
- E2 might require SCTP-LB with OpenVPN bundled together
## How-To Guides

- [How-To : build/run](run.md)
Expand Down

0 comments on commit 045bee8

Please sign in to comment.