changelogs/CHANGELOG-v1.24.0.md
We are delighted to present version v1.24.0 of Contour, our layer 7 HTTP reverse proxy for Kubernetes clusters.
A big thank you to everyone who contributed to the release.
Duplicate include conditions are now correctly identified and HTTPProxies are marked with the condition IncludeError and reason DuplicateMatchConditions.
Previously the HTTPProxy processor was only comparing adjacent includes and comparing conditions element by element rather than as a whole, ANDed together.
In addition, the previous behavior when duplicate Include Conditions were identified was to throw out all routes, including valid ones, on the offending HTTPProxy.
Any referenced child HTTPProxies were marked as Orphaned as a result, even if they were included correctly.
With this change, all valid Includes and Route rules are processed and programmed in the data plane, which is a difference in behavior from previous releases.
An Include is deemed to be a duplicate if it has the exact same match Conditions as an Include that precedes it in the list.
Only child HTTPProxies that are referenced by a duplicate Include and not in any other valid Include are marked as Orphaned
/A caveat to the above, is that an empty list of include conditions or a set of conditions that only consist of the prefix match on / are not treated as duplicates.
This special case has been added because many users rely on the behavior this enables and many Contour examples demonstrating inclusion actually use it. For example:
---
apiVersion: projectcontour.io/v1
kind: HTTPProxy
metadata:
name: example
spec:
virtualhost:
fqdn: foo-example.bar.com
includes:
- name: example-child1
- name: example-child2
---
apiVersion: projectcontour.io/v1
kind: HTTPProxy
metadata:
name: example-child1
spec:
routes:
- conditions:
- prefix: /
services:
- name: s1
port: 80
---
apiVersion: projectcontour.io/v1
kind: HTTPProxy
metadata:
name: example-child2
spec:
routes:
- conditions:
- prefix: /foo
services:
- name: s2
port: 80
While the include conditions are equivalent, the resulting routing rules when the child routes are taken into account are distinct.
This special casing is a stop-gap for this release, to ensure we do not break user's configuration that is currently valid and working.
Currently duplicate route conditions are not checked in an HTTPProxy include tree or within an individual HTTPProxy. This means that you can have routes listed later in the list of routes on an HTTPProxy silently override others. The same can happen if you have an include tree that generates duplicate routes based on the include conditions and route conditions.
If you are relying on this behavior, changes will be coming in the next Contour release.
We will be submitting a design document to address this as it will be a significant behavior change and encourage the community to weigh in. The current plan is to fully validate duplicate route match conditions as they are generated from the tree of includes and routes. There will likely be changes to status conditions set on HTTPRoutes to improve reporting such invalid configuration.
(#4931, #5017, @sunjayBhatia)
See the Gateway API release notes for more detail on the API changes. This version of the API includes a few changes relevant to Contour users:
(#4944, @sunjayBhatia)
The liveness probe has been removed from the Envoy pods' shutdown-manager sidecar container. This change is to mitigate a problem where when the liveness probe fails, the shutdown-manager container is restarted by itself. This ultimately has the unintended effect of causing the envoy container to be stuck indefinitely in a "DRAINING" state and not serving traffic.
Overall, not having the liveness probe on the shutdown-manager container is less bad because envoy pods are less likely to get stuck in "DRAINING" indefinitely. In the worst case, during termination of an Envoy pod (due to upgrade, scaling, etc.), shutdown-manager is truly unresponsive, in which case the envoy container will simply terminate without first draining active connections. If appropriate (i.e. during an upgrade), a new Envoy pod will then be created and re-added to the set of ready Envoys to load balance traffic to.
(#4967, @skriss)
HTTPProxy.Route.Service and HTTPProxy.TCPProxy.Service now has an optional HealthPort field which specifies a health check port that is different from the routing port. If not specified, the service Port field is used for healthchecking.
(#4761, @yangyy93)
Contour no longer validates Secrets that are not used by an Ingress, HTTPProxy, Gateway, or Contour global config. Validation is now performed as needed when a Secret is referenced. This change also replaces misleading "Secret not found" error conditions with more specific errors when a Secret referenced by one of the above objects does exist, but is not valid.
(#4788, @skriss)
By default, when client certificate validation is configured, client certificates are required.
However, some applications might support different authentication schemes.
You can now set the httpproxy.spec.virtualhost.tls.clientValidation.optionalClientCertificate field to true. A client certificate will be requested, but the connection is allowed to continue if the client does not provide one.
If a client certificate is sent, it will be verified according to the other properties, which includes disabling validations if httpproxy.spec.virtualhost.tls.clientValidation.skipClientCertValidation is set.
(#4796, @gautierdelorme)
HTTPProxy now supports passing certificate data through the x-forwarded-client-cert header to let applications use details from client certificates (e.g. Subject, SAN...).
Since the certificate (or the certificate chain) could exceed the web server header size limit, you have the ability to select what specific part of the certificate to expose in the header through the httpproxy.spec.virtualhost.tls.clientValidation.forwardClientCertificate field.
Read more about the supported values in the Envoy documentation.
(#4797, @gautierdelorme)
Envoy's treatment of the Server header on responses can now be configured in the Contour config file or ContourConfiguration CRD.
When configured as overwrite, Envoy overwrites any Server header with "envoy".
When configured as append_if_absent, if a Server header is present, Envoy will pass it through, otherwise, it will set it to "envoy".
When configured as pass_through, Envoy passes through the value of the Server header and does not append a header if none is present.
(#4906, @Vishal-Chdhry)
ALL DNS lookup family.If ALL is specified, the DNS resolver will perform a lookup for both IPv4 and IPv6 families, and return all resolved addresses. When this is used, Happy Eyeballs will be enabled for upstream connections.
(#4909, @Vishal-Chdhry)
Bumps Envoy to version 1.25.0. See Envoy release notes here.
(#4988, @skriss)
Contour's Kubernetes API client defaults to allowing 5 requests per second, with a maximum of 10 over a short period.
These settings can now be configured, either by flag or by config file.
The contour serve flags are --kubernetes-client-qps and --kubernetes-client-burst.
The config file fields are kubernetesClientQPS and kubernetesClientBurst.
(#5003, @skriss)
Opaque as long as they have valid tls.crt and tls.key entries. (#4799, @skriss)grpc_status_number to the default JSON access log fields (#4880, @rajatvig)NodePortService, use the Listeners' port numbers to populate the Service's node port values. (#4973, @izturn)contour_dagrebuild_seconds, to measure the duration of DAG rebuilds by quantile. (#5009, @skriss)projectcontour.io/projectcontour/contour to projectcontour.io/gateway-controller for static provisioning. (#4966, @izturn)ContourDeployment.Spec.Contour.Replicas is deprecated and has been replaced by ContourDeployment.Spec.Contour.Deployment.Replicas. Users should switch to using the new field. The deprecated field will be removed in a future release. See #4713 for additional details.
ContourDeployment.Spec.Envoy.Replicas is deprecated and has been replaced by ContourDeployment.Spec.Envoy.Deployment.Replicas. Users should switch to using the new field. The deprecated field will be removed in a future release. See #4713 for additional details.
(#4713, @izturn)
In Gateway API, ReferencePolicy's rename to ReferenceGrant has been fully completed. Contour now only supports ReferenceGrant, and does not support ReferencePolicy resources in any way.
(#4830, @skriss)
For a fresh install of Contour, consult the getting started documentation.
To upgrade an existing Contour installation, please consult the upgrade documentation.
Contour v1.24.0 is tested against Kubernetes 1.24 through 1.26.
We’re immensely grateful for all the community contributions that help make Contour even better! For this release, special thanks go out to the following contributors:
If you're using Contour and want to add your organization to our adopters list, please visit this page. If you prefer to keep your organization name anonymous but still give us feedback into your usage and scenarios for Contour, please post on this GitHub thread.