Introducing Application Load Balancer (ALB)
Application Load Balancers (ALB) is a layer-7 software that is used to routing traffic to destinations such as containers, IP addresses, VMs or Lambda functions based on the header or message of the HTTP or HTTPS requests. ALBs are one of the important components of the modern microservices architecture and cloud-native applications.
Features of Application Load Balancers are:
- Distributes traffic requests to multiple instances of the same application.
- Requests can be evaluated and routed based on host, header, path etc.
- Serve external traffic and internal traffic in case of VPCs
- Supports HTTP, HTTPs, HTTP/2 and gRPC protocols.
- Redirecting to different target environments
Challenges of standard Application Load Balancers
If architects and DevOps are considering or using Kubernetes, then classic Application Load Balancers will have a lot of limitations while adopting and scaling their cloud-native applications. A few limitations are outline below:
- Since the ALB sits outside of the cluster, it cannot access applications in the cluster. Hence DevOps teams need to expose a certain service using NodePort, or direct POD access via specific Kubernetes CNI for ALB to access the applications it will load balance (refer the Fig A). In case some CNI does allow the access, then ALB can never access the application. In the case of the other strategy of opening Nodeport and sharing with the ALB, there is a risk of unnecessary exposure of all the applications in that node. So such strategies are a big NO for production.
- Architects would need to do some extra configurations to secure traffic from ALB to cluster.
- Configurations for implementing mTLS can be complex.
- Might end up using multiple Ingress controllers in certain scenarios, for e.g in multicluster or multicloud setup. There will be multiple network hops where ALB will connect with an Ingress controller which will severely deter the performance of the network with time.
Refer to the below image to get an idea about a real-life implementation of load balancers with Kubernetes workloads.
Fig A: Working architecture of load balancers in Kubernetes workloads
Introduction to Istio service mesh
Istio service mesh is the answer to all the problems in the modern architecture where microservices are deployed into Kubernetes. Istio is the open source service mesh which abstracts the communication out of the microservices architecture. You can achieve advanced networking and implement zero trust security using Istio very easily. Istio service mesh has 3 major components:
- Data plane: Istio injects a light-weight side-car proxy based on Envoy. The Envoy proxy supports L7 and L4 layers of request and all the networking and security can be achieved selectively by Istio.
- Control plane: Istio offers a central plane from which all the network (such as load balancing) and security policies (such mTLS)can be implemented at the edge and the data plane level.
- Ingress Gateway: Istio provides an Ingress Gateway by default to handle the traffic at the edge. You can implement all the advanced networking (retries, timeouts, failover, etc.) including load balancing using Istio Ingress Gateway.