Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Core API: Support empty SectionName in HTTPRoute ParentRef #479

Closed
kate-osborn opened this issue Mar 17, 2023 · 0 comments · Fixed by #626
Closed

Core API: Support empty SectionName in HTTPRoute ParentRef #479

kate-osborn opened this issue Mar 17, 2023 · 0 comments · Fixed by #626
Assignees
Labels
area/httproute/core Relates to all Core features of HTTPRoute enhancement New feature or request refined Requirements are refined and the issue is ready to be implemented.
Milestone

Comments

@kate-osborn
Copy link
Contributor

kate-osborn commented Mar 17, 2023

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.

@kate-osborn kate-osborn changed the title Core API: Support empty sectionName Core API: Support empty SectionName in HTTPRoute ParentRef Mar 17, 2023
@kate-osborn kate-osborn added enhancement New feature or request area/httproute/core Relates to all Core features of HTTPRoute and removed proposal labels Mar 21, 2023
@kate-osborn kate-osborn added this to the v1.0.0 milestone Mar 21, 2023
@kate-osborn kate-osborn self-assigned this Mar 21, 2023
@kate-osborn kate-osborn added the refined Requirements are refined and the issue is ready to be implemented. label Mar 24, 2023
@kate-osborn kate-osborn modified the milestones: v1.0.0, v0.4.0 Mar 24, 2023
@kate-osborn kate-osborn removed their assignment Mar 24, 2023
@kate-osborn kate-osborn modified the milestones: v0.4.0, v1.0.0 Mar 24, 2023
@sjberman sjberman self-assigned this May 1, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/httproute/core Relates to all Core features of HTTPRoute enhancement New feature or request refined Requirements are refined and the issue is ready to be implemented.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants