Like ring hash, maglev is a consistent hashing algorithm. In addition, the computation cost of the hash adds some latency to requests, particularly at scale. The tradeoff with ring hash is that it can be more challenging to evenly distribute load between different backend servers, since client workloads may not be equal. Moreover, if you’re caching client data on a given pod, the probability of cache hits also increases. By routing the same client to the same pod, the state for a given client does not need to be synchronized across pods. The hashing approach is useful for services that maintain per-client state (e.g., a shopping cart). The ring hash approach is used for both “sticky sessions” (where a cookie is set to ensure that all requests from a client arrive at the same pod) and for “session affinity” (which relies on client IP or some other piece of client state). Instead of rotating requests between different pods, the ring hash load balancing strategy uses a hashing algorithm to send all requests from a given client to the same pod. When a request for a particular Kubernetes service is sent to your load balancer, the load balancer round robins the request between pods that map to the given service. In this approach, your load balancer uses the Kubernetes Endpoints API to track the availability of pods. Ambassador is built on Envoy Proxy, a L7 proxy, so each gRPC request is load balanced between available pods. What if you’re using a multiplexed keep-alive protocol like gRPC or HTTP/2, and you need a more fair round robin algorithm? You can use an API Gateway for Kubernetes such as Ambassador which can bypass kube-proxy altogether, routing traffic directly to Kubernetes pods. Thus, whether you’re sending a request via Ambassador or via another service, you’re going through the same load balancing mechanism. The entire process of load balancing is delegated to Kubernetes and it’s the default strategy. So why use kube-proxy at all? In one word: simplicity. This is true even if one client is sending 1 request per minute, while the other client is sending 100 requests per second. In L4 load balancing, each client would be sent to a different backend pod (round-robin). For example, imagine two gRPC clients that are connecting to your backend pods. Moreover, kube-proxy routes at L4 (TCP), which doesn’t necessarily fit well with today’s application-centric protocols. A small amount of latency is introduced for each request which increases as the number of services grow. This architecture adds additional complexity to routing. Somewhat confusingly, kube-proxy isn’t a proxy in the classic sense, but a process that implements a virtual IP for a service via iptables rules. In a typical Kubernetes cluster, requests that are sent to a Kubernetes Service are routed by a component named kube-proxy. L4 Round Robin Load Balancing with kube-proxy In Kubernetes, there are a variety of choices for load balancing external traffic to pods, each with different tradeoffs. Load balancing is the process of efficiently distributing network traffic among multiple backend services, and is a critical strategy for maximizing scalability and availability. L4 round robin, L7 round robin, ring hash, and more
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |