Panic now occurs when using an ExternalName Service as a backend

[dfallert-rcd]

Describe the bug

As of AKO version 1.12.x, a panic occurs when using an ExternalName service as a backend for the ingresses used by AKO.

panic: runtime error: index out of range [0] with length 0

goroutine 101 [running]:
github.com/vmware/load-balancer-and-ingress-services-for-kubernetes/internal/nodes.PopulateServersForNodePort(0xc000004300, {0xc003d08758, 0xc}, {0xc000968078, 0x17}, 0xc?, {0xc003d08750, 0x24})
        /go/src/github.com/vmware/load-balancer-and-ingress-services-for-kubernetes/internal/nodes/avi_model_l4_translator.go:362 +0x112f
github.com/vmware/load-balancer-and-ingress-services-for-kubernetes/internal/nodes.(*AviObjectGraph).BuildPolicyPGPoolsForSNI(0x1?, {0xc00019c948, 0x1, 0x0?}, 0xc000594f00, {0xc003d08758, 0xc}, {0xc003d08765, _}, {0xc003d03110, ...}, ...)
        /go/src/github.com/vmware/load-balancer-and-ingress-services-for-kubernetes/internal/nodes/avi_model_l7_translator.go:480 +0x2116
github.com/vmware/load-balancer-and-ingress-services-for-kubernetes/internal/nodes.(*AviObjectGraph).BuildModelGraphForSNI(0xc003a2b620, {0x23394b0, 0xc0000d2b80}, {0xc003d038f0}, {0xc003d10880, 0x1, 0x1}, {0xc003d03110, {0xc003d088d0, 0x23}, ...}, ...)
        /go/src/github.com/vmware/load-balancer-and-ingress-services-for-kubernetes/internal/nodes/avi_model_l7_hostname_shard.go:718 +0xf91
github.com/vmware/load-balancer-and-ingress-services-for-kubernetes/internal/nodes.sniNodeHostName({0x23394b0, 0xc0000d2b80}, {0xc003d03110, {0xc003d088d0, 0x23}, {0x0, 0x0}, {0x0, 0x0}, {0x0, ...}, ...}, ...)
        /go/src/github.com/vmware/load-balancer-and-ingress-services-for-kubernetes/internal/nodes/avi_model_l7_hostname_shard.go:617 +0x61f
github.com/vmware/load-balancer-and-ingress-services-for-kubernetes/internal/nodes.ProcessSecureHosts({0x23394b0, 0xc0000d2b80}, {0xc003d08750, 0x24}, {0x0, {0xc0002d0310, 0x1, 0x1}, 0xc003d03050, 0x0}, ...)
        /go/src/github.com/vmware/load-balancer-and-ingress-services-for-kubernetes/internal/nodes/avi_model_routeingr_hostname_shard.go:220 +0x231
github.com/vmware/load-balancer-and-ingress-services-for-kubernetes/internal/nodes.HostNameShardAndPublish({0x2028419, 0x7}, {0xc003d08765, 0xf}, {0xc003d08758, 0xc}, {0xc003d08750, 0x24}, 0x1, 0xc00030c190)
        /go/src/github.com/vmware/load-balancer-and-ingress-services-for-kubernetes/internal/nodes/avi_model_routeingr_hostname_shard.go:127 +0xd8a
github.com/vmware/load-balancer-and-ingress-services-for-kubernetes/internal/nodes.handleIngress({0xc003d08750, 0x24}, 0x58?, {0xc003cffd50, 0x1, 0x24?})
        /go/src/github.com/vmware/load-balancer-and-ingress-services-for-kubernetes/internal/nodes/dequeue_ingestion.go:740 +0x205
github.com/vmware/load-balancer-and-ingress-services-for-kubernetes/internal/nodes.DequeueIngestion({0xc003d08750, 0x24}, 0x1)
        /go/src/github.com/vmware/load-balancer-and-ingress-services-for-kubernetes/internal/nodes/dequeue_ingestion.go:241 +0x1beb
github.com/vmware/load-balancer-and-ingress-services-for-kubernetes/internal/k8s.(*AviController).FullSyncK8s(0xc0000601c0, 0x0)
        /go/src/github.com/vmware/load-balancer-and-ingress-services-for-kubernetes/internal/k8s/ako_init.go:1078 +0x31f6
github.com/vmware/load-balancer-and-ingress-services-for-kubernetes/internal/k8s.(*AviController).InitController(0xc0000601c0, {{0x2348be0, 0xc0004809c0}, {0x0, 0x0}, {0x2315a50, 0xc0006033f0}}, {0xc0001a4be0, 0x8, 0xa}, ...)
        /go/src/github.com/vmware/load-balancer-and-ingress-services-for-kubernetes/internal/k8s/ako_init.go:533 +0x847
created by main.InitializeAKC in goroutine 1
        /go/src/github.com/vmware/load-balancer-and-ingress-services-for-kubernetes/cmd/ako-main/main.go:337 +0x2389
        

Reproduction steps

1. Deploy AKO 1.12.x
2. Deploy a service of type ExternalName and point it to another service on the cluster, but in a different namespace
3. Deploy an ingress that uses the above service as a backend
4. Watch the AKO logs for an immediate panic: runtime error: index out of range [0] with length 0

This does not occur with AKO 1.11.x

Expected behavior

AKO does not panic, and properly creates the node group and node pools which contain all the servers from the service. In my example case, it will be the local cluster node IPs, at the istio ingressgateway's https NodePort 31009.

Additional context

example yaml using istio's ingressgateway. I want to reiterate, that this all worked fine prior to AKO 1.12.x

apiVersion: v1
kind: Service
metadata:
  name: myapp-service
  namespace: myapp
spec:
  externalName: istio-ingressgateway.istio-system.svc.cluster.local #using istio https endpoint as an example
  ports:
    - name: https
      nodePort: 31009
      port: 443
      protocol: TCP
      targetPort: 443
  sessionAffinity: None
  type: ExternalName
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: myapp-ingress
  namespace: myapp
spec:
  ingressClassName: avi-lb
  rules:
    - host: myapp.fakename.com
      http:
        paths:
          - backend:
              service:
                name: myapp-service
                port:
                  name: https
            path: /
            pathType: Prefix

And here's a screenshot of a VS/PoolGroup/Pool in the controller view

[akshayhavile]

@dfallert-rcd: Thanks for reporting this. Currently, AKO doesn't support external-name service type. We will fix crash issue in upcoming release. @ashishnayak96 Can you please look into it? CC: @apalsule