diff --git a/README.md b/README.md index ce63c0242..cba50316d 100644 --- a/README.md +++ b/README.md @@ -17,7 +17,7 @@ All these services are provided by load-balancers/proxies operating at Layer4/La Service type load-balancer is usually provided by public cloud-provider(s) as a managed entity. But for on-prem and self-managed clusters, there are only a few good options available. Even for provider-managed K8s like EKS, there are many who would want to bring their own LB to clusters running anywhere. loxilb provides service type load-balancer as its main use-case. loxilb can be run in-cluster or ext-to-cluster as per user need. -loxilb works as a L4 load-balancer/service-proxy by default. Although L4 load-balancing provides great performance and functionality, at times, an equally performant L7 load-balancer is also necessary in K8s for various use-cases. loxilb also supports L7 load-balancing in the form of Kubernetes Ingress implementation. This also benefit users who wants L4 and L7 load-balancing under the same hood. +loxilb works as a L4 load-balancer/service-proxy by default. Although L4 load-balancing provides great performance and functionality, at times, an equally performant L7 load-balancer is also necessary in K8s for various use-cases. loxilb also supports L7 load-balancing in the form of Kubernetes Ingress implementation. This also benefit users who need L4 and L7 load-balancing under the same hood. Additionally, loxilb also supports: - [x] kube-proxy replacement with eBPF(full cluster-mesh implementation for Kubernetes). diff --git a/loxilb-ebpf b/loxilb-ebpf index a89b92b2e..ffbed7aa6 160000 --- a/loxilb-ebpf +++ b/loxilb-ebpf @@ -1 +1 @@ -Subproject commit a89b92b2e05ac623161b1e18cb7e6153d95c2dd2 +Subproject commit ffbed7aa6aa0e976f793d0a2ab3b0a7075b1a2bd