如何将Kubernetes与现有AWS ALB集成？复用已有ALB技术问询

Got it, let's break down how to reuse your existing AWS ALB with Kubernetes without letting the AWS Load Balancer Controller (the successor to the old ALB Ingress Controller) create or modify any AWS resources. Here are two reliable approaches to make this work:

This approach skips relying on the Ingress Controller to manage AWS resources entirely, and manually wires your existing ALB to your Kubernetes services:

• Step 1: Create a NodePort Service in Kubernetes
  Convert your existing ClusterIP service to a NodePort type (or create a new one directly). This opens a static port on every cluster node to receive external traffic. Example config:

  apiVersion: v1
  kind: Service
  metadata:
    name: my-app-service
  spec:
    type: NodePort
    selector:
      app: my-app
    ports:
      - port: 80
        targetPort: 8080
        nodePort: 30080 # Optional: Specify a fixed port to simplify ALB setup later
  

  Run kubectl apply -f service.yaml to create the service, then note down the nodePort value (Kubernetes auto-assigns one between 30000-32767 if you don't specify).

• Step 2: Configure your existing ALB's target group manually

  1. Head to the AWS Console → EC2 → Target Groups, and open the target group you want to reuse (since you don't want new resources, skip creating a new one).
  2. Edit the registered targets, add the private IP addresses of all your Kubernetes cluster nodes, and set the port to the NodePort you noted earlier.
  3. Make sure the target group's health check settings match your app (e.g., path /healthz, port matching your app's listening port or the NodePort).

• Step 3: Link the target group to your ALB's listener rules
  Go to your existing ALB's listener configuration (for port 80/443), add or update rules to route traffic for your desired paths to the configured target group.

• Step 4: Validate security group settings

  • Your existing ALB's security group must allow incoming traffic from your frontend (e.g., ports 80/443).
  • Your cluster nodes' security group must allow incoming traffic from the ALB's security group, targeting the NodePort you're using.

If you prefer using Ingress resources to manage routing rules while preventing the Controller from creating/modifying AWS resources, follow these steps:

• Step 1: Restrict the Controller's IAM permissions
  Modify the IAM role attached to the AWS Load Balancer Controller to remove all create/modify/delete permissions, leaving only read access to existing resources:

  {
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Allow",
        "Action": [
          "elasticloadbalancing:DescribeLoadBalancers",
          "elasticloadbalancing:DescribeTargetGroups",
          "elasticloadbalancing:DescribeListeners",
          "elasticloadbalancing:DescribeRules",
          "ec2:DescribeInstances",
          "ec2:DescribeSecurityGroups",
          "ec2:DescribeSubnets"
        ],
        "Resource": "*"
      }
    ]
  }
  

  This ensures the Controller can only read existing AWS resources, not create or alter them.

• Step 2: Create an Ingress resource pointing to your existing ALB/Target Group
  Add annotations to your Ingress config to explicitly tell the Controller to reuse your existing ALB and target group, instead of creating new ones:

  apiVersion: networking.k8s.io/v1
  kind: Ingress
  metadata:
    name: my-app-ingress
    annotations:
      alb.ingress.kubernetes.io/load-balancer-arn: arn:aws:elasticloadbalancing:us-west-2:123456789012:loadbalancer/app/my-existing-alb/abc123
      alb.ingress.kubernetes.io/target-group-arn: arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/my-existing-tg/def456
      alb.ingress.kubernetes.io/scheme: internet-facing # Must match your existing ALB's scheme (internal/internet-facing)
      alb.ingress.kubernetes.io/target-type: ip # Use "ip" for EKS with VPC CNI (recommended), or "instance" if targeting nodes
  spec:
    ingressClassName: alb # Ensure your Controller uses this ingress class name
    rules:
      - host: my-app.example.com
        http:
          paths:
            - path: /
              pathType: Prefix
              backend:
                service:
                  name: my-app-service
                  port:
                    number: 80
  

  The load-balancer-arn and target-group-arn annotations are critical here—they force the Controller to work with your existing resources.

• Step 3: Manually sync targets to your target group
  Since the Controller can't modify the target group, you'll need to manually register Pod IPs (for IP-type target groups) or node IPs (for instance-type) to it. If your app auto-scales, consider writing a simple script or using AWS Lambda to automate this sync.

• Ensure your existing ALB is in the same VPC as your Kubernetes cluster (or connected via VPC peering, but same VPC is simplest).
• If using IP-type target groups, confirm your Pods have IPs accessible by the ALB (e.g., using AWS VPC CNI, which assigns VPC IPs directly to Pods).
• Test by accessing your ALB's DNS name to verify traffic flows to your Kubernetes service and returns a valid response.

内容的提问来源于stack exchange，提问作者raman.pndy