Skip to content

Core API: Support empty SectionName in HTTPRoute ParentRef #479

Closed
@kate-osborn

Description

@kate-osborn

Allow users to attach an HTTPRoute to an entire Gateway by leaving the section name of the parent ref empty.
If at least one section (listener) accepts the HTTPRoute, then the attachment is considered successful.

Acceptance Criteria:

  • Attempt to attach HTTPRoute's with empty section names to all the listeners of the specified Gateway. For now, only accept routes with hostnames that are exact match of the listener hostname if the hostname is specified. Do not attempt wildcard hostname matching. This will be covered by a separate issue.
  • Report a Route status of Accepted/True/Accepted (condition/value/reason) if at least one listener accepts the HTTPRoute.
  • Report a Route status of Accepted/False/<reason> if no listeners accept the HTTPRoute.
  • Update doc: https://github.com/nginxinc/nginx-kubernetes-gateway/blob/main/docs/gateway-api-compatibility.md#httproute

Helpful links:

Examples:

apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
  name: tea
spec:
  parentRefs:
  - name: gateway
  hostnames:
  - "cafe.example.com"
  - "cafe.example.org"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /tea
    backendRefs:
    - name: tea
      port: 80
---
apiVersion: gateway.networking.k8s.io/v1beta1
kind: Gateway
metadata:
  name: gateway
  labels:
    domain: k8s-gateway.nginx.org
spec:
  gatewayClassName: nginx
  listeners:
  - name: http // route binds for both hostnames
    port: 80
    protocol: HTTP
  - name: https
    port: 443
    protocol: HTTPS
    hostname: "cafe.example.com" // route binds but only for this hostname
    tls:
      mode: Terminate
      certificateRefs:
      - kind: Secret
        name: cafe-secret
        namespace: default
  - name: https-gov
    port: 443
    protocol: HTTPS
    hostname: "cafe.example.gov" // route does not bind
    tls:
      mode: Terminate
      certificateRefs:
      - kind: Secret
        name: cafe-secret
        namespace: default

In this example, the httproute attaches to the listeners in the following ways:

  • The route fully attaches to the listener http. Both cafe.example.com and cafe.example.org hostnames are allowed by the http listener because the listener does not specify a hostname.
  • The route partially attaches to the listener https. Only the cafe.example.com hostname is allowed by the https listener.
  • The route does not attach to the listener https-gov because its hostnames do not match the listener's hostname.
apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
  name: tea
spec:
  parentRefs:
  - name: gateway
  hostnames:
  - "cafe.example.com"
  - "cafe.example.org"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /tea
    backendRefs:
    - name: tea
      port: 80
---
apiVersion: gateway.networking.k8s.io/v1beta1
kind: Gateway
metadata:
  name: gateway
  labels:
    domain: k8s-gateway.nginx.org
spec:
  gatewayClassName: nginx
  listeners:
  - name: http // route binds for both hostnames
    port: 80
    protocol: HTTP
  - name: http-2 //  bind for cafe.example.com
    port: 80
    protocol: HTTP
    hostname: "cafe.example.com"
  - name: http-3 // bind for cafe.example.org
    port: 80
    protocol: HTTP
    hostname: "cafe.example.org"

In this example, the httproute attaches to the listeners in the following ways:

  • The route fully attaches to the listener http. Both cafe.example.com and cafe.example.org hostnames are allowed by the http listener because the listener does not specify a hostname.
  • The route partially attaches to the listener http-2. Only the cafe.example.com hostname is allowed by the http-2 listener.
  • The route partially attaches to the listener http-3. Only the cafe.example.org hostname is allowed by the http-3 listener.

However, if we allow and configure all of the attachments above, we will end up with duplicate server blocks for cafe.example.com and cafe.example.org. In this case we need to choose which listener to bind the route to following the guidelines of the spec.

Metadata

Metadata

Assignees

Labels

area/httproute/coreRelates to all Core features of HTTPRouteenhancementNew feature or requestrefinedRequirements are refined and the issue is ready to be implemented.

Type

No type

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions