Lack of ExternalName Service support

[maciejmaz]

I'm creating this feature request to reopen the issue described here: https://github.com/kubernetes-sigs/aws-load-balancer-controller/issues/1223

Is your feature request related to a problem? When you set up ALB Ingress and the service linked with this ingress is ExternalName type, the Target Group in AWS doesn't have any targets registered and the ingress returns HTTP 503 error.

Describe the solution you'd like Adding an ingress with an ExternalName service type should properly route traffic to the service. This would allow creating cross-namespace relations between Ingress and the services.

Example:

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
  namespace: namespace1
  labels:
    app: nginx
spec:
  containers:
  - name: nginx-container
    image: nginx:latest
    ports:
    - containerPort: 80
      protocol: TCP

---

kind: Service
apiVersion: v1
metadata:
  name: nginx-service
  namespace: namespace1
spec:
  selector:
    app: nginx
  type: ClusterIP
  ports:
  - port: 80

---

kind: Service
apiVersion: v1
metadata:
  name: nginx-service-external
  namespace: namespace2
spec:
  type: ExternalName
  externalName: nginx-service.namespace1.svc.cluster.local

---

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: test-ingress
  namespace: namespace2
  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: ingress
    alb.ingress.kubernetes.io/certificate-arn: <placeholder>
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS":443}]'
spec:
  rules:
    - host: example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: nginx-service-external
                port:
                  number: 80

Should result hosting nginx from namespace1 on ingress deployed in namespace2

Describe alternatives you've considered

1. Switching to Nginx ingress controller
2. Adding some nginx pod doing the proxy_pass as suggested here: https://github.com/kubernetes-sigs/aws-load-balancer-controller/issues/1223#issuecomment-652510197

[yalattas]

I am facing same issue here. My setup worked fine with nginx controller in OCI. Yet, when I switched to AWS ALB. It didn't work

[holooloo]

Same issue, no ip addresses in target groups

[eahangari-8x8]

yes, same here. I don't think AWS ALB controller supports this feature.

[msvticket]

Another use case for ExternalName would be to put a load balancer in front of an S3 interface endpoint: https://docs.aws.amazon.com/AmazonS3/latest/userguide/privatelink-interface-endpoints.html#private-dns

This would be useful to make it easier to implement a solution like this: Hosting Internal HTTPS Static Websites with ALB, S3, and PrivateLink

For this use case the ALB controller could only support target type ip, since there wouldn't be any instance to route to. I think it should be hard coded for any extrernalname pointing outside the k8s cluster that target type is ip and just a warning event should be emitted if alb.ingress.kubernetes.io/target-type: instance is specified.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[msvticket]

I created a PR back in February to fix this (#3571). Unfortunately nobody has reviewed it...

/remove-lifecycle stale

[lalit4osttra]

Is there any progress on the issue

[lalit4osttra]

I found an alternate, instead of creating a single in ingress in separate namespace, we can create separate separate ingress in service namespaces and use ingress group (a simple annotation) in all ingress ... behind the scenes all the ingress (that are part of same ingress group) will get combined.

https://aws.amazon.com/blogs/containers/a-deeper-look-at-ingress-sharing-and-target-group-binding-in-aws-load-balancer-controller/

https://aws.amazon.com/blogs/containers/a-deeper-look-at-ingress-sharing-and-target-group-binding-in-aws-load-balancer-controller/

I have tested it with fargate in my env ... it works perfectly fine