bug: sectionname in parentrefs is ignored

[mulimoen]

Current Behavior

Creating two HTTPRoutes with a reference to different listeners in the gateway shows only one route is active at the same time, with incoming requests forwarded to the same pod. If deleting a route the requests are forwarded to the other pod.

It seems spec.listener[].port and 'parentRefs[].sectionName` is ignored completely.

In the documentation on spec.listeners[].port it mentions this parameter is required, but ignored as it can't change the data plane deployment. The ingress controller must still recognize .port and sectionName for traffic purposes.

Expected Behavior

Traffic is sent correctly to separate pods.

Error Logs

No response

Steps to Reproduce

1. Install APISIX Ingress controller with the Helm chart, opening port 79.
2. Create a gateway and these resources

---
apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: apisix-gc
  namespace: ingress-apisix
spec:
  controllerName: "apisix.apache.org/apisix-ingress-controller"
---
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: gatty
  namespace: apisix-ingress
spec:
  gatewayClassName: apisix-gc
  infrastructure:
    parametersRef:
      group: apisix.apache.org
      kind: GatewayProxy
      name: apisix-config
  listeners:
    - protocol: HTTP
      port: 80
      name: http2
      allowedRoutes:
        namespaces:
          from: All
    - protocol: HTTP
      port: 81
      name: http3
      allowedRoutes:
        namespaces:
          from: All
---
apiVersion: v1
kind: Pod
metadata:
  name: mypod2
  labels:
    app: myapp2
spec:
  containers:
    - name: mycontainer
      image: docker.io/hashicorp/http-echo:1.0@sha256:2c213d6c05a0f68adfe9c7fe1a78a314e5c4fee783e2ee8592d49f10d0c4513f
      ports:
        - name: myport
          containerPort: 5678
---
apiVersion: v1
kind: Service
metadata:
  name: myservice2
spec:
  type: ClusterIP
  selector:
    app: myapp2
  ports:
    - name: myserviceport
      port: 123
      targetPort: myport
---
apiVersion: v1
kind: Pod
metadata:
  name: mypod3
  labels:
    app: myapp3
spec:
  containers:
    - name: mycontainer
      image: docker.io/hashicorp/http-echo:1.0@sha256:2c213d6c05a0f68adfe9c7fe1a78a314e5c4fee783e2ee8592d49f10d0c4513f
      ports:
        - name: myport
          containerPort: 5678
---
apiVersion: v1
kind: Service
metadata:
  name: myservice3
spec:
  type: ClusterIP
  selector:
    app: myapp3
  ports:
    - name: myserviceport
      port: 123
      targetPort: myport
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: route2
spec:
  parentRefs:
    - name: gatty
      namespace: apisix-ingress
      sectionName: http2
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /
      backendRefs:
        - name: myservice2
          port: 123
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: route3
spec:
  parentRefs:
    - name: gatty
      namespace: apisix-ingress
      sectionName: http3
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /
      backendRefs:
        - name: myservice3
          port: 123

3. Open the logs in follow mode on each pod
4. curl apisix-gateway.apisix-ingress.svc:79 and curl apisix-gateway.apisix-ingress.svc:80, both of these go to the same pod
5. Delete the route to the pod which got the traffic
6. Repeat curl commands above and observe requests to both of the ports go to the opposite pod

Environment

• Helm chart apisix/2.12.2
• APISIX Ingress controller version (run apisix-ingress-controller version --long) apache/apisix-ingress-controller:2.0.0-rc5
• Kubernetes cluster version (run kubectl version)

kubectl version
Client Version: v1.34.1
Kustomize Version: v5.7.1
Server Version: v1.34.0

[bzp2010]

@mulimoen

I confirm that this functionality is not yet supported; this is a known issue.

We have already listed it as a task to be resolved and added it to the roadmap, and it will be implemented in the future.