HTTPRoute conflicts when specifying a fallback https listener
What steps did you take and what happened:
Given the following gateway:
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
name: contour
namespace: projectcontour
spec:
gatewayClassName: contour
listeners:
- name: http
protocol: HTTP
port: 80
allowedRoutes:
namespaces:
from: All
- name: https-example.com
protocol: HTTPS
port: 443
hostname: "*.example.com"
allowedRoutes:
namespaces:
from: All
tls:
certificateRefs:
- name: "wildcard-example.com-tls"
kind: Secret
- name: https
protocol: HTTPS
port: 443
allowedRoutes:
namespaces:
from: All
tls:
certificateRefs:
- name: "default-tls"
kind: Secret
HTTPRoute:
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: example.com
spec:
hostnames:
- "*.example.com"
rules:
- backendRefs:
- name: example
port: 8080
kind: Service
parentRefs:
- name: contour
group: gateway.networking.k8s.io
namespace: projectcontour
kind: Gateway
Applying the HTTPRoute above will always result in HTTPRoute's Match has conflict with other HTTPRoute's Match error. If I remove either https-example.com or https listener, it will work again. The above HTTPRoute is the only route in the system (there is no other route to cause conflict)
What did you expect to happen:
The HTTPRoute should be accepted.
Anything else you would like to add: It seems like the HTTPRoute is attached to both https-example.com and https listener. Each attachment is treated by contour as a separated HTTPRoute, which will lead to conflict.
Environment:
- Contour version: 1.29.1
- Kubernetes version: (use
kubectl version): v1.27.13 - Kubernetes installer & version:
- Cloud provider or hardware configuration: GKE. Node version: v1.26.14
- OS (e.g. from
/etc/os-release):
Hey @hatsuyuki15! Thanks for opening your first issue. We appreciate your contribution and welcome you to our community! We are glad to have you here and to have your input on Contour. You can also join us on our mailing list and in our channel in the Kubernetes Slack Workspace
The Contour project currently lacks enough contributors to adequately respond to all Issues.
This bot triages Issues according to the following rules:
- After 60d of inactivity, lifecycle/stale is applied
- After 30d of inactivity since lifecycle/stale was applied, the Issue is closed
You can:
- Mark this Issue as fresh by commenting
- Close this Issue
- Offer to help out with triage
Please send feedback to the #contour channel in the Kubernetes Slack
remove lifecycle/stale
The Contour project currently lacks enough contributors to adequately respond to all Issues.
This bot triages Issues according to the following rules:
- After 60d of inactivity, lifecycle/stale is applied
- After 30d of inactivity since lifecycle/stale was applied, the Issue is closed
You can:
- Mark this Issue as fresh by commenting
- Close this Issue
- Offer to help out with triage
Please send feedback to the #contour channel in the Kubernetes Slack
remove lifecycle/stale
I have the same with an http and https+wildcard. Additionally, some certificates are selected incorrectly, but I can't say if it's related or not 🤷
The Contour project currently lacks enough contributors to adequately respond to all Issues.
This bot triages Issues according to the following rules:
- After 60d of inactivity, lifecycle/stale is applied
- After 30d of inactivity since lifecycle/stale was applied, the Issue is closed
You can:
- Mark this Issue as fresh by commenting
- Close this Issue
- Offer to help out with triage
Please send feedback to the #contour channel in the Kubernetes Slack
The Contour project currently lacks enough contributors to adequately respond to all Issues.
This bot triages Issues according to the following rules:
- After 60d of inactivity, lifecycle/stale is applied
- After 30d of inactivity since lifecycle/stale was applied, the Issue is closed
You can:
- Mark this Issue as fresh by commenting
- Close this Issue
- Offer to help out with triage
Please send feedback to the #contour channel in the Kubernetes Slack