From da2e7ca4093b0de8d1dcb3003f3731ebae467ab4 Mon Sep 17 00:00:00 2001 From: UltraInstinct14 Date: Thu, 25 Jul 2024 00:12:49 +0900 Subject: [PATCH] chore: Update README --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index e55ca322..86e13fb1 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 need 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, 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 which is enhanced with eBPF sockmap helpers. 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)