AWS Kubernetes多负载均衡器成本过高，寻求优化方案

Ah, I’ve run into this exact scenario with clients before—unintentionally spinning up extra Load Balancers (LBs) on AWS EKS is super easy to do when you’re starting out, and those costs can add up fast. Let’s break down the best ways to cut down your LB count while keeping your services accessible.

First, quick diagnosis: You’ve got 6 LBs for 5 services, which likely means either one is a leftover from a deleted/untracked Service/Ingress, or each service is using a LoadBalancer type Service directly (which creates one LB per service). Here are the most effective fixes:

1. Use an Ingress Controller with AWS ALB/NLB (Best for HTTP/HTTPS Services) #

This is the gold standard for exposing multiple HTTP/HTTPS services through a single LB. Instead of creating a LoadBalancer Service for each app, you deploy an Ingress Controller (like the official AWS Load Balancer Controller) and define an Ingress resource that routes traffic to your services based on domain names or paths.

How to implement: #

• Deploy the AWS Load Balancer Controller to your EKS cluster (it replaces the older ALB Ingress Controller).
• Create a single Ingress manifest that maps your 5 domains to their respective ClusterIP Services. Example:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: multi-service-ingress
  annotations:
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
spec:
  ingressClassName: alb
  tls:
    - hosts:
        - service1.yourdomain.com
        - service2.yourdomain.com
        # Add your other 3 domains here
      secretName: your-tls-secret # Or use ACM with alb.ingress.kubernetes.io/certificate-arn
  rules:
    - host: service1.yourdomain.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: service1-clusterip
                port:
                  number: 80
    - host: service2.yourdomain.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: service2-clusterip
                port:
                  number: 80
    # Repeat for your other 3 services

• This will create one AWS ALB that handles all 5 domains, routing traffic to the correct service behind the scenes.

2. Use a Single Multi-Port NLB for TCP/UDP Services #

If some of your services use non-HTTP protocols (like TCP for databases, UDP for messaging), you can’t use Ingress. Instead, use the AWS Load Balancer Controller to create a single NLB with multiple target groups, each pointing to a different service. This way, one NLB handles multiple protocols/ports for your non-HTTP workloads.

Quick workflow: #

• Deploy the AWS Load Balancer Controller if you haven’t already.
• Create TargetGroupBinding resources for each TCP/UDP service, linking them to the same NLB.
• The controller will provision a single NLB that routes traffic from different ports to your respective services.

3. Clean Up Unused Load Balancers #

First, audit your cluster to find the extra LB:

• Run kubectl get svc -o wide to list all Services of type LoadBalancer—check if any are unused or belong to deprecated services.
• Run kubectl get ingress to see which Ingress resources are creating LBs (you can consolidate multiple Ingresses into one to avoid extra ALBs).
• Delete any orphaned Services/Ingress resources that are no longer needed—AWS will automatically terminate the associated LB.

Key Notes to Avoid Future Cost Bloat: #

• Never use LoadBalancer Services for HTTP/HTTPS apps unless absolutely necessary—Ingress is far more cost-effective and flexible.
• Use AWS Cost Explorer to monitor LB costs post-optimization, so you can verify savings.
• For mixed protocol workloads (HTTP + TCP), use one ALB for HTTP services and one multi-port NLB for TCP services—total 2 LBs instead of 6.

内容的提问来源于stack exchange，提问作者Schroedinger