面向Kubernetes高可用集群的AWS负载均衡器选型
Short Answer
Absolutely—NLB is not just a valid choice, it’s often the preferred option for building a highly available Kubernetes control plane on AWS. Your direction is spot-on.
Why NLB Fits Kubernetes HA Needs
Let’s break down why this works perfectly for your setup:
1. Matches Kubernetes Control Plane Traffic
The Kubernetes control plane (specifically the kube-apiserver) communicates over TCP (default port 6443). NLB is optimized for low-latency, high-throughput TCP/UDP traffic forwarding—this is exactly what you need for stable, reliable access to your cluster’s API server. Unlike Application Load Balancer (ALB), which operates at the HTTP/HTTPS layer (L7), NLB works at the transport layer (L4), making it a more efficient match for pure TCP traffic like the control plane’s.
2. Stable Entry Point for Cluster Components
NLB supports static Elastic IP addresses, which is a huge win for Kubernetes. Your cluster components (kubelet, kubectl, worker nodes) need a consistent entry point to reach the control plane. With NLB, you can assign fixed EIPs to the load balancer, avoiding the dynamic IP changes that come with ALB (unless you tie ALB to a domain via Route53, which adds unnecessary complexity here).
3. Inherent High Availability
NLB is built for HA out of the box—it deploys across multiple AWS Availability Zones (AZs) by default, with automatic failover. When paired with a multi-master Kubernetes control plane (minimum 3 master nodes spread across AZs), NLB will automatically route traffic only to healthy kube-apiserver instances, ensuring your cluster remains accessible even if a master node or entire AZ goes down.
When Would ALB Be Better?
Don’t get me wrong—ALB has its place! It’s ideal for application-layer traffic (your microservices exposed via Kubernetes Ingress). If you plan to use an Ingress Controller (like the AWS Load Balancer Controller), it will automatically provision ALBs to handle HTTP/HTTPS traffic to your apps. In this setup, NLB handles the control plane, and ALB handles application traffic—this is a common, well-architected pattern for AWS-based Kubernetes clusters.
Quick Configuration Tips for NLB + Kubernetes
- Ensure your NLB’s target group includes all your
kube-apiservernodes. - Set up a TCP health check on port 6443 (or an HTTPS check against the
/healthzendpoint) to ensure only healthy API servers receive traffic. - Enable cross-AZ load balancing to distribute traffic evenly across your master nodes in different AZs.
内容的提问来源于stack exchange，提问作者Mr.DevEng
