Ingress annotations provisions unnecessary AWS classic load balancer - amazon-web-services

Question

Within my AWS EKS cluster provisioning an AWS application load balancer using annotations on the Ingress object. Additionally an unnecessary classic load balancer is being provisioned. Any ideas or best practice on how to prevent this?
resource "kubernetes_service" "api" {
metadata {
name = "${var.project_prefix}-api-service"
}
spec {
selector = {
app = "${var.project_prefix}-api"
}
port {
name = "http"
port = 80
target_port = 1337
}
port {
name = "https"
port = 443
target_port = 1337
}
type = "LoadBalancer"
}
}
resource "kubernetes_ingress" "api" {
wait_for_load_balancer = true
metadata {
name = "${var.project_prefix}-api"
annotations = {
"kubernetes.io/ingress.class" = "alb"
"alb.ingress.kubernetes.io/scheme" = "internet-facing"
"alb.ingress.kubernetes.io/target-type" = "instance"
"alb.ingress.kubernetes.io/certificate-arn" = local.api-certificate_arn
"alb.ingress.kubernetes.io/load-balancer-name" = "${var.project_prefix}-api"
"alb.ingress.kubernetes.io/listen-ports" = "[{\"HTTP\": 80}, {\"HTTPS\":443}]"
"alb.ingress.kubernetes.io/actions.ssl-redirect" = "{\"Type\": \"redirect\", \"RedirectConfig\": { \"Protocol\": \"HTTPS\", \"Port\": \"443\", \"StatusCode\": \"HTTP_301\"}}"
}
}
spec {
backend {
service_name = kubernetes_service.api.metadata.0.name
service_port = 80
}
rule {
http {
path {
path = "/*"
backend {
service_name = "ssl-redirect"
service_port = "use-annotation"
}
}
}
}
}
}

Answer 1

Your LoadBalancer service is responsible for deploying the classic load balancer, and if you just need an application load balancer, is unnecessary.
resource "kubernetes_service" "api" {
metadata {
name = "${var.project_prefix}-api-service"
}
spec {
selector = {
app = "${var.project_prefix}-api"
}
port {
name = "http"
port = 80
target_port = 1337
}
port {
name = "https"
port = 443
target_port = 1337
}
type = "ClusterIP" # See comments below
}
}
resource "kubernetes_ingress" "api" {
wait_for_load_balancer = true
metadata {
name = "${var.project_prefix}-api"
annotations = {
"kubernetes.io/ingress.class" = "alb"
"alb.ingress.kubernetes.io/target-type" = "ip" # See comments below
"alb.ingress.kubernetes.io/scheme" = "internet-facing"
"alb.ingress.kubernetes.io/target-type" = "instance"
"alb.ingress.kubernetes.io/certificate-arn" = local.api-certificate_arn
"alb.ingress.kubernetes.io/load-balancer-name" = "${var.project_prefix}-api"
"alb.ingress.kubernetes.io/listen-ports" = "[{\"HTTP\": 80}, {\"HTTPS\":443}]"
"alb.ingress.kubernetes.io/actions.ssl-redirect" = "{\"Type\": \"redirect\", \"RedirectConfig\": { \"Protocol\": \"HTTPS\", \"Port\": \"443\", \"StatusCode\": \"HTTP_301\"}}"
}
}
spec {
backend {
service_name = kubernetes_service.api.metadata.0.name
service_port = 80
}
rule {
http {
path {
path = "/*"
backend {
service_name = "ssl-redirect"
service_port = "use-annotation"
}
}
}
}
}
}
Traffic Modes
Depending on your cluster and networking setup, you might be able to use ip target type, where the load balancer can communicate directly with Kubernetes pods via their IP (so ClusterIP service types are fine) if you have a CNI configuration, or use instance in conjunction with NodePort service types as the load balancer cannot directly access the pod IPs. Some relevant links below:
ALB Target Types
VPC CNI EKS Plugin
Load Balancer Types
Some relevant links regarding Kubernetes load balancing and EKS load balancers. Note that Ingress resources are layer 7 and load balance service resources are layer 4, hence ALBs deployed for EKS ingress resources and NLBs for load balanced service resources:
Rancher Kubernetes Load Balancers
AWS Load Balancer Comparison