EKS ALB not attached to the Ingres with Service type ClusterIp and target-type = IP. Is NodePort Mandatory

Question

I created with NodePort and target-type=instance for my-nginx server Created Ingress with alb annotation of aws. It got an Application Load Balancer attached.

I also created once more service with ClusterIp and Ingress for it. No Load Balancer.

In the AWS Documentation : https://docs.aws.amazon.com/eks/latest/userguide/alb-ingress.html It says that the target-type: instance needs NodePort but for target-type: IP nothing is mentioned.

Q1. EKS ALB not attached to the Ingres with Service type ClusterIp and target-type = IP. Is NodePort Mandatory

This is the yaml for Ingress

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  namespace: kubernetes-dashboard
  name: kubernetes-dashboard
  annotations:
    kubernetes.io/ingress.class: alb
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/group.name: "all-http-pods"
spec:
  defaultBackend:
    service:
      name: kubernetes-dashboard
      port:
        number: 443

Q2. When I deploy the ALB Controller to private subnets, It doesn't create the ALB for NodePort as well. When I tried again, the controller deployed to public subnet and then it created ALB for NodePort Service type. Is it necessary that controllers are deployed to public subnet.

Q3. What is the difference between target-type: instance and target-type: IP? This one, I googled but I didn't get any clear idea.

Need help in understanding the above mentioned questions.

Thank you

GeertPt · Accepted Answer · 2022-07-06T08:19:14.893

An ALB has HTTP and/or HTTPS Listeners, which contain Rules, and the Rules define to which TargetGroups requests need to be forwarded.

The aws-load-balancer-controller pod in your EKS cluster automatically creates those Listeners, Rules, TargetGroups and ALB for each Ingress. Then when a pod is started for a service linked to that Ingress, it registers that pod in the TargetGroup.

If you use the alb.ingress.kubernetes.io/group.name tag, and you already have an ALB with that group name, the controller pod will not create a new ALB, but add a Rule and TargetGroup to the existing ALB.

When you use target-type: instance, the pod is registered using a port on the underlying EC2 instance of the kubernetes node, so it needs to be a NodePort. If you use target-type: ip, the pod is registered using its ClusterIP, which (in AWS) is an elastic ip address that connects directly to the pod, so no extra NodePort is needed.

The difference between public (internet-facing) and private (internal) ALB's is in which subnets they are created. Before you deploy a private ingress, you need to tag two or more private subnets with kubernetes.io/role/internal-elb: 1 for the ALB to be created in. If the controller can't find those, it will not create an ALB. For public ALB's, it will look for subnets tagged kubernetes.io/role/elb: 1.

See https://kubernetes-sigs.github.io/aws-load-balancer-controller/v2.4/deploy/subnet_discovery/.

When you mix private and public ingresses, be careful with the alb.ingress.kubernetes.io/group.name tag. You should use different group names for private and public ingresses, since these need to be different ALB's in different subnets, e.g. "all-public-http-pods" and "all-private-http-pods".

Take a look at the pod logs for the aws-load-balancer-controller in the kube-system namespace for debug information.

Oh thank you very much. Problem is that I actually have 2 Ingress with defaultBackend. Found it in the alb controller logs. You pointed me to the right direction. — Krishna, Jul 06 '22 at 20:34

EKS ALB not attached to the Ingres with Service type ClusterIp and target-type = IP. Is NodePort Mandatory

1 Answers1