<p>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.</p>
<p>I also created once more service with ClusterIp and Ingress for it. No Load Balancer.</p>
<p>In the AWS Documentation : <a href="https://docs.aws.amazon.com/eks/latest/userguide/alb-ingress.html" rel="nofollow noreferrer">https://docs.aws.amazon.com/eks/latest/userguide/alb-ingress.html</a>
It says that the target-type: instance needs NodePort but for target-type: IP nothing is mentioned.</p>
<p>Q1. EKS ALB not attached to the Ingres with Service type ClusterIp and target-type = IP. Is NodePort Mandatory</p>
<p><a href="https://i.stack.imgur.com/lDIol.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/lDIol.png" alt="No ALB for Ingress with Service ClusterIP" /></a></p>
<p>This is the yaml for Ingress</p>
<pre><code>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: &quot;all-http-pods&quot;
spec:
  defaultBackend:
    service:
      name: kubernetes-dashboard
      port:
        number: 443
</code></pre>
<p>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.</p>
<p>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.</p>
<p>Need help in understanding the above mentioned questions.</p>
<p>Thank you</p>

Krishna
<p>An ALB has HTTP and/or HTTPS Listeners, which contain Rules, and the Rules define to which TargetGroups requests need to be forwarded.</p>
<p>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.</p>
<p>If you use the <code>alb.ingress.kubernetes.io/group.name</code> 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.</p>
<p>When you use <code>target-type: instance</code>, 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 <code>target-type: ip</code>, 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.</p>
<p>The difference between public (<code>internet-facing</code>) and private (<code>internal</code>) 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 <code>kubernetes.io/role/internal-elb: 1</code> 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 <code>kubernetes.io/role/elb: 1</code>.</p>
<p>See <a href="https://kubernetes-sigs.github.io/aws-load-balancer-controller/v2.4/deploy/subnet_discovery/" rel="nofollow noreferrer">https://kubernetes-sigs.github.io/aws-load-balancer-controller/v2.4/deploy/subnet_discovery/</a>.</p>
<p>When you mix private and public ingresses, be careful with the <code>alb.ingress.kubernetes.io/group.name</code> 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. <code>&quot;all-public-http-pods&quot;</code> and <code>&quot;all-private-http-pods&quot;</code>.</p>
<p>Take a look at the pod logs for the aws-load-balancer-controller in the kube-system namespace for debug information.</p>
