k8singress doesn't recognise named serviceport

[SmartassSkeleton]

Bug description

When deploying Istio with k8singress=true and using a name port for servicePort in an Ingress resource I get a 404 when trying to access the app. Changing the servicePort to an identical numeric port of the service works well.

Expected behavior

Being able to access my app using a name servicePort

Steps to reproduce the bug

Deployed a service and an ingress:

---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: istio
  labels:
    app: my-app
  name: app-ingress
  namespace: my-namespace
spec:
  rules:
  - host: app.example.com
    http:
      paths:
      - backend:
          serviceName: app-service
          servicePort: http
        path: /.*

apiVersion: v1
kind: Service
metadata:
  labels:
    app: my-app
  name: app-service
  namespace: my-namespace
spec:
  ports:
  - name: http
    port: 8080
    protocol: TCP
    targetPort: http
  selector:
    app: my-app
  sessionAffinity: None
  type: ClusterIP

Using 8080 instead of http in the ingress works.

Version (include the output of istioctl version --remote and kubectl version and helm version if you used Helm)

istioctl version --remote
client version: 1.5.1
control plane version: 1.5.1
data plane version: 1.5.1 (70 proxies)

 kubectl version
Client Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.1", GitCommit:"7879fc12a63337efff607952a323df90cdc7a335", GitTreeState:"clean", BuildDate:"2020-04-10T21:53:51Z", GoVersion:"go1.14.2", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"15+", GitVersion:"v1.15.11-eks-af3caf", GitCommit:"af3caf6136cd355f467083651cc1010a499f59b1", GitTreeState:"clean", BuildDate:"2020-03-27T21:51:36Z", GoVersion:"go1.12.17", Compiler:"gc", Platform:"linux/amd64"}

How was Istio installed?

 istioctl manifest apply --set profile=demo \
  --set values.gateways.istio-ingressgateway.sds.enabled=true \
  --set values.global.k8sIngress.enabled=true \
  --set values.global.k8sIngress.enableHttps=true \
  --set values.global.k8sIngress.gatewayName=ingressgateway \
  --set values.gateways.istio-ingressgateway.serviceAnnotations."service\.beta\.kubernetes\.io/aws-load-balancer-internal"=0.0.0.0/0 \
  --set values.gateways.istio-ingressgateway.serviceAnnotations."service\.beta\.kubernetes\.io/aws-load-balancer-type"=nlb

Environment where bug was observed (cloud vendor, OS, etc)

AWS EKS 1.15

[jronak]

@howardjohn I would like to work on this issue.

I figured out the k8s ingress to gateway conversion happens in pilot k8s config

istio/pilot/pkg/config/kube/ingress/conversion.go

Line 249 in 56120f8

if backend.ServicePort.Type == intstr.Int {

// Port names are not allowed in destination rules.

Looks like If backend route does not have port number, it skips creating route destination.
How can we resolve named-ports to it's port number?

[howardjohn]

We need to lookup the pod I think which we do not currently read in the ingress controller

…

On Thu, Jun 11, 2020 at 1:01 PM Ronak Jain ***@***.***> wrote: @howardjohn <https://github.com/howardjohn> I would like to work on this issue. I figured out the k8s ingress to gateway conversion happens in pilot k8s config https://github.com/istio/istio/blob/56120f8ccee49591245c95dd6f92025ab9bdc746/pilot/pkg/config/kube/ingress/conversion.go#L249 // Port names are not allowed in destination rules. Looks like If backend route does not have port number, it skips creating route destination. How can we resolve named-ports to it's port number? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#23052 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEYGXJ4CLSQI5TWEB7WIT3RWEZYBANCNFSM4MLNZO5Q> .

[jronak]

You are right, I looked up further and flow would look like this:
a) Find the service pointed by the backend.serviceName
b) Find the pods matching selector used by service (a)
c) Search pods (b) for named-port matching backend.servicePort

We would have to pass k8s client to this function.But we won't have k8s client when it's called from the istioctl to covert ingress into gateway & virtual service, how do we handle this case?