Contour is a Kubernetes ingress controller using Envoy proxy.
APACHE-2.0 License
Bot releases are hidden (Show)
Published by skriss 12 months ago
We are delighted to present version v1.27.0 of Contour, our layer 7 HTTP reverse proxy for Kubernetes clusters.
A big thank you to everyone who contributed to the release.
Envoy greedy matches routes and as a result the order route matches are presented to Envoy is important. Contour attempts to produce consistent routing tables so that the most specific route matches are given preference. This is done to facilitate consistency when using HTTPProxy inclusion and provide a uniform user experience for route matching to be inline with Ingress and Gateway API Conformance.
This changes fixes the sorting algorithm used for Prefix
and Regex
based path matching. Previously the algorithm lexicographically sorted based on the path match string instead of sorting them based on the length of the Prefix
|Regex
. i.e. Longer prefix/regexes will be sorted first in order to give preference to more specific routes, then lexicographic sorting for things of the same length.
Note that for prefix matching, this change is not expected to change the relative ordering of more specific prefixes vs. less specific ones when the more specific prefix match string has the less specific one as a prefix, e.g. /foo/bar
will continue to sort before /foo
. However, relative ordering of other combinations of prefix matches may change per the above description.
Caution is advised if you update Contour and you are operating large routing tables. We advise you to:
http://127.0.0.1:9001/config_dump
and compare the configuration of Envoy. In particular the routes and their order. The prefix routes might be changing in order, so if they are you need to verify that the route matches as expected.(#5752, @davinci26)
Setting rateLimitPolicy.global.disabled
flag to true on a specific route now disables the global rate limit policy inherited from the virtual host for that route.
In the example below, /foo
route is opted out from the global rate limit policy defined by the virtualhost.
apiVersion: projectcontour.io/v1
kind: HTTPProxy
metadata:
name: echo
spec:
virtualhost:
fqdn: local.projectcontour.io
rateLimitPolicy:
global:
descriptors:
- entries:
- remoteAddress: {}
- genericKey:
key: vhost
value: local.projectcontour.io
routes:
- conditions:
- prefix: /
services:
- name: ingress-conformance-echo
port: 80
- conditions:
- prefix: /foo
rateLimitPolicy:
global:
disabled: true
services:
- name: ingress-conformance-echo
port: 80
(#5657, @shadialtarsha)
Before this, we only waited for informer caches to sync but didn't wait for delivering the events to subscribed handlers.
Now contour waits for the initial list of Kubernetes objects to be cached and processed by handlers (using the returned HasSynced
methods)
and then starts building its DAG and serving XDS.
(#5672, @therealak12)
This Change allows the host header to be rewritten on requests using dynamic headers on the only route level.
apiVersion: projectcontour.io/v1
kind: HTTPProxy
metadata:
name: dynamic-host-header-rewrite
spec:
fqdn: local.projectcontour.io
routes:
- conditions:
- prefix: /
services:
- name: s1
port: 80
- requestHeaderPolicy:
set:
- name: host
value: "%REQ(x-rewrite-header)%"
(#5678, @clayton-gonsalves)
This change optionally enables Contour to consume the kubernetes endpointslice API to determine the endpoints to configure Envoy with.
Note: This change is off by default and is gated by the feature flag useEndpointSlices
.
This feature will be enabled by default in a future version on Contour once it has had sufficient bake time in production environments.
(#5745, @clayton-gonsalves)
Envoy v1.27.1 mitigates CVE-2023-44487 with some default runtime settings, however the http.max_requests_per_io_cycle
does not have a default value.
This change allows configuring this runtime setting via Contour configuration to allow administrators of Contour to prevent abusive connections from starving resources from other valid connections.
The default is left as the existing behavior (no limit) so as not to impact existing valid traffic.
The Contour ConfigMap can be modified similar to the following (and Contour restarted) to set this value:
listener:
max-requests-per-io-cycle: 10
(Note this can be used in addition to the existing Listener configuration field listener.max-requests-per-connection
which is used primarily for HTTP/1.1 connections and is an approximate limit for HTTP/2)
See the Envoy release notes for more details.
(#5827, @sunjayBhatia)
This field can be used to limit the number of concurrent streams Envoy will allow on a single connection from a downstream peer.
It can be used to tune resource usage and as a mitigation for DOS attacks arising from vulnerabilities like CVE-2023-44487.
The Contour ConfigMap can be modified similar to the following (and Contour restarted) to set this value:
listener:
http2-max-concurrent-streams: 50
(#5850, @sunjayBhatia)
--incluster
, --kubeconfig
for enable run the gateway-provisioner
in or out of the cluster. (#5686, @izturn)overloadMaxHeapSize
configuration option to contourDeployment to allow adding overloadManager configuration when generating envoy's initial configuration file. (#5699, @yangyy93)ResolvedRefs
condition to true
by default. (#5804, @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.27.0 is tested against Kubernetes 1.26 through 1.28.
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.
Published by skriss 12 months ago
We are delighted to present version v1.27.0-rc.1 of Contour, our layer 7 HTTP reverse proxy for Kubernetes clusters.
A big thank you to everyone who contributed to the release.
Please note that this is pre-release software, and as such we do not recommend installing it in production environments.
Feedback and bug reports are welcome!
Envoy greedy matches routes and as a result the order route matches are presented to Envoy is important. Contour attempts to produce consistent routing tables so that the most specific route matches are given preference. This is done to facilitate consistency when using HTTPProxy inclusion and provide a uniform user experience for route matching to be inline with Ingress and Gateway API Conformance.
This changes fixes the sorting algorithm used for Prefix
and Regex
based path matching. Previously the algorithm lexicographically sorted based on the path match string instead of sorting them based on the length of the Prefix
|Regex
. i.e. Longer prefix/regexes will be sorted first in order to give preference to more specific routes, then lexicographic sorting for things of the same length.
Note that for prefix matching, this change is not expected to change the relative ordering of more specific prefixes vs. less specific ones when the more specific prefix match string has the less specific one as a prefix, e.g. /foo/bar
will continue to sort before /foo
. However, relative ordering of other combinations of prefix matches may change per the above description.
Caution is advised if you update Contour and you are operating large routing tables. We advise you to:
http://127.0.0.1:9001/config_dump
and compare the configuration of Envoy. In particular the routes and their order. The prefix routes might be changing in order, so if they are you need to verify that the route matches as expected.(#5752, @davinci26)
Setting rateLimitPolicy.global.disabled
flag to true on a specific route now disables the global rate limit policy inherited from the virtual host for that route.
In the example below, /foo
route is opted out from the global rate limit policy defined by the virtualhost.
apiVersion: projectcontour.io/v1
kind: HTTPProxy
metadata:
name: echo
spec:
virtualhost:
fqdn: local.projectcontour.io
rateLimitPolicy:
global:
descriptors:
- entries:
- remoteAddress: {}
- genericKey:
key: vhost
value: local.projectcontour.io
routes:
- conditions:
- prefix: /
services:
- name: ingress-conformance-echo
port: 80
- conditions:
- prefix: /foo
rateLimitPolicy:
global:
disabled: true
services:
- name: ingress-conformance-echo
port: 80
(#5657, @shadialtarsha)
Before this, we only waited for informer caches to sync but didn't wait for delivering the events to subscribed handlers.
Now contour waits for the initial list of Kubernetes objects to be cached and processed by handlers (using the returned HasSynced
methods)
and then starts building its DAG and serving XDS.
(#5672, @therealak12)
This Change allows the host header to be rewritten on requests using dynamic headers on the only route level.
apiVersion: projectcontour.io/v1
kind: HTTPProxy
metadata:
name: dynamic-host-header-rewrite
spec:
fqdn: local.projectcontour.io
routes:
- conditions:
- prefix: /
services:
- name: s1
port: 80
- requestHeaderPolicy:
set:
- name: host
value: "%REQ(x-rewrite-header)%"
(#5678, @clayton-gonsalves)
This change optionally enables Contour to consume the kubernetes endpointslice API to determine the endpoints to configure Envoy with.
Note: This change is off by default and is gated by the feature flag useEndpointSlices
.
This feature will be enabled by default in a future version on Contour once it has had sufficient bake time in production environments.
(#5745, @clayton-gonsalves)
Envoy v1.27.1 mitigates CVE-2023-44487 with some default runtime settings, however the http.max_requests_per_io_cycle
does not have a default value.
This change allows configuring this runtime setting via Contour configuration to allow administrators of Contour to prevent abusive connections from starving resources from other valid connections.
The default is left as the existing behavior (no limit) so as not to impact existing valid traffic.
The Contour ConfigMap can be modified similar to the following (and Contour restarted) to set this value:
listener:
max-requests-per-io-cycle: 10
(Note this can be used in addition to the existing Listener configuration field listener.max-requests-per-connection
which is used primarily for HTTP/1.1 connections and is an approximate limit for HTTP/2)
See the Envoy release notes for more details.
(#5827, @sunjayBhatia)
This field can be used to limit the number of concurrent streams Envoy will allow on a single connection from a downstream peer.
It can be used to tune resource usage and as a mitigation for DOS attacks arising from vulnerabilities like CVE-2023-44487.
The Contour ConfigMap can be modified similar to the following (and Contour restarted) to set this value:
listener:
http2-max-concurrent-streams: 50
(#5850, @sunjayBhatia)
--incluster
, --kubeconfig
for enable run the gateway-provisioner
in or out of the cluster. (#5686, @izturn)overloadMaxHeapSize
configuration option to contourDeployment to allow adding overloadManager configuration when generating envoy's initial configuration file. (#5699, @yangyy93)ResolvedRefs
condition to true
by default. (#5804, @skriss)The simplest way to install v1.27.0-rc.1 is to apply one of the example configurations:
With Gateway API:
kubectl apply -f https://raw.githubusercontent.com/projectcontour/contour/v1.27.0-rc.1/examples/render/contour-gateway.yaml
Without Gateway API:
kubectl apply -f https://raw.githubusercontent.com/projectcontour/contour/v1.27.0-rc.1/examples/render/contour.yaml
Contour v1.27.0-rc.1 is tested against Kubernetes 1.26 through 1.28.
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.
Published by sunjayBhatia about 1 year ago
We are delighted to present version v1.26.1 of Contour, our layer 7 HTTP reverse proxy for Kubernetes clusters.
This release includes various dependency bumps and fixes for CVE-2023-44487, including:
Additional mitigations have been added for CVE-2023-44487 in the form of new configuration fields:
Envoy mitigates CVE-2023-44487 with some default runtime settings, however the http.max_requests_per_io_cycle
does not have a default value.
This change allows configuring this runtime setting via Contour configuration to allow administrators of Contour to prevent abusive connections from starving resources from other valid connections.
The default is left as the existing behavior (no limit) so as not to impact existing valid traffic.
The Contour ConfigMap can be modified similar to the following (and Contour restarted) to set this value:
listener:
max-requests-per-io-cycle: 10
(Note this can be used in addition to the existing Listener configuration field listener.max-requests-per-connection
which is used primarily for HTTP/1.1 connections and is an approximate limit for HTTP/2)
This field can be used to limit the number of concurrent streams Envoy will allow on a single connection from a downstream peer.
It can be used to tune resource usage and as a mitigation for DOS attacks arising from vulnerabilities like CVE-2023-44487.
The Contour ConfigMap can be modified similar to the following (and Contour restarted) to set this value:
listener:
http2-max-concurrent-streams: 50
For a fresh install of Contour, consult the getting started documentation.
To upgrade an existing Contour installation, please consult the upgrade documentation.
Contour v1.26.1 is tested against Kubernetes 1.26 through 1.28.
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.
Published by sunjayBhatia about 1 year ago
We are delighted to present version v1.25.3 of Contour, our layer 7 HTTP reverse proxy for Kubernetes clusters.
This release includes various dependency bumps and fixes for CVE-2023-44487, including:
Additional mitigations have been added for CVE-2023-44487 in the form of new configuration fields:
Envoy mitigates CVE-2023-44487 with some default runtime settings, however the http.max_requests_per_io_cycle
does not have a default value.
This change allows configuring this runtime setting via Contour configuration to allow administrators of Contour to prevent abusive connections from starving resources from other valid connections.
The default is left as the existing behavior (no limit) so as not to impact existing valid traffic.
The Contour ConfigMap can be modified similar to the following (and Contour restarted) to set this value:
listener:
max-requests-per-io-cycle: 10
(Note this can be used in addition to the existing Listener configuration field listener.max-requests-per-connection
which is used primarily for HTTP/1.1 connections and is an approximate limit for HTTP/2)
This field can be used to limit the number of concurrent streams Envoy will allow on a single connection from a downstream peer.
It can be used to tune resource usage and as a mitigation for DOS attacks arising from vulnerabilities like CVE-2023-44487.
The Contour ConfigMap can be modified similar to the following (and Contour restarted) to set this value:
listener:
http2-max-concurrent-streams: 50
For a fresh install of Contour, consult the getting started documentation.
To upgrade an existing Contour installation, please consult the upgrade documentation.
Contour v1.25.3 is tested against Kubernetes 1.25 through 1.27.
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.
Published by sunjayBhatia about 1 year ago
We are delighted to present version v1.24.6 of Contour, our layer 7 HTTP reverse proxy for Kubernetes clusters.
This release includes various dependency bumps and fixes for CVE-2023-44487, including:
Additional mitigations have been added for CVE-2023-44487 in the form of new configuration fields:
Envoy mitigates CVE-2023-44487 with some default runtime settings, however the http.max_requests_per_io_cycle
does not have a default value.
This change allows configuring this runtime setting via Contour configuration to allow administrators of Contour to prevent abusive connections from starving resources from other valid connections.
The default is left as the existing behavior (no limit) so as not to impact existing valid traffic.
The Contour ConfigMap can be modified similar to the following (and Contour restarted) to set this value:
listener:
max-requests-per-io-cycle: 10
(Note this can be used in addition to the existing Listener configuration field listener.max-requests-per-connection
which is used primarily for HTTP/1.1 connections and is an approximate limit for HTTP/2)
This field can be used to limit the number of concurrent streams Envoy will allow on a single connection from a downstream peer.
It can be used to tune resource usage and as a mitigation for DOS attacks arising from vulnerabilities like CVE-2023-44487.
The Contour ConfigMap can be modified similar to the following (and Contour restarted) to set this value:
listener:
http2-max-concurrent-streams: 50
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.6 is tested against Kubernetes 1.24 through 1.26.
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.
Published by sunjayBhatia about 1 year ago
We are delighted to present version v1.26.0 of Contour, our layer 7 HTTP reverse proxy for Kubernetes clusters.
A big thank you to everyone who contributed to the release.
Contour now supports Gateway Listeners with many different ports.
Previously, Contour only allowed a single port for HTTP, and a single port for HTTPS/TLS.
As an example, the following Gateway, with two HTTP ports and two HTTPS ports, is now fully supported:
kind: Gateway
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
name: contour
spec:
gatewayClassName: contour
listeners:
- name: http-1
protocol: HTTP
port: 80
allowedRoutes:
namespaces:
from: Same
- name: http-2
protocol: HTTP
port: 81
allowedRoutes:
namespaces:
from: Same
- name: https-1
protocol: HTTPS
port: 443
allowedRoutes:
namespaces:
from: Same
tls:
mode: Terminate
certificateRefs:
- name: tls-cert-1
- name: https-2
protocol: HTTPS
port: 444
allowedRoutes:
namespaces:
from: Same
tls:
mode: Terminate
certificateRefs:
- name: tls-cert-2
If you are using the Contour Gateway Provisioner, ports for all valid Listeners will automatically be exposed via the Envoy service, and will update when any Listener changes are made.
If you are using static provisioning, you must keep the Service definition in sync with the Gateway spec manually.
Note that if you are using the Contour Gateway Provisioner along with HTTPProxy or Ingress for routing, then your Gateway must have exactly one HTTP Listener and one HTTPS Listener.
For this case, Contour supports a custom HTTPS Listener protocol value, to avoid having to specify TLS details in the Listener (since they're specified in the HTTPProxy or Ingress instead):
kind: Gateway
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
name: contour-with-httpproxy
spec:
gatewayClassName: contour
listeners:
- name: http
protocol: HTTP
port: 80
allowedRoutes:
namespaces:
from: All
- name: https
protocol: projectcontour.io/https
port: 443
allowedRoutes:
namespaces:
from: All
(#5160, @skriss)
Metrics on status update counts and duration are now output by the xDS server.
This should enable deployments at scale to diagnose delays in status updates and possibly tune the --kubernetes-client-qps
and --kubernetes-client-burst
flags.
(#5037, @sunjayBhatia)
The contour serve
command takes a new optional flag, --watch-namespaces
, that can
be used to restrict the namespaces where the Contour instance watches for resources.
Consequently, resources in other namespaces will not be known to Contour and will not
be acted upon.
You can watch a single or multiple namespaces, and you can further restrict the root
namespaces with --root-namespaces
just like before. Root namespaces must be a subset
of the namespaces being watched, for example:
--watch-namespaces=my-admin-namespace,my-app-namespace --root-namespaces=my-admin-namespace
If the --watch-namespaces
flag is not used, then all namespaces will be watched by default.
(#5214, @nsimons)
This Change Adds 2 features to HTTPProxy
In addition to prefix
and exact
, HTTPProxy now also support regex
.
apiVersion: projectcontour.io/v1
kind: HTTPProxy
metadata:
name: root-regex-match
spec:
fqdn: local.projectcontour.io
routes:
- conditions:
# matches
# - /list/1234
# - /list/
# - /list/foobar
# and so on and so forth
- regex: /list/.*
services:
- name: s1
port: 80
- conditions:
# matches
# - /admin/dev
# - /admin/prod
- regex: /admin/(prod|dev)
services:
- name: s2
port: 80
apiVersion: projectcontour.io/v1
kind: HTTPProxy
metadata:
name: root-regex-match
spec:
fqdn: local.projectcontour.io
includes:
- name: child-regex-match
conditions:
- prefix: /child
routes:
- conditions:
- prefix: /
services:
- name: s1
port: 80
apiVersion: projectcontour.io/v1
kind: HTTPProxy
metadata:
name: child-regex-match
spec:
fqdn: local.projectcontour.io
routes:
- conditions:
# matches
# - /child/list/1234
# - /child/list/
# - /child/list/foobar
# and so on and so forth
- regex: /list/.*
services:
- name: s1
port: 80
- conditions:
# matches
# - /child/admin/dev
# - /child/admin/prod
- regex: /admin/(prod|dev)
services:
- name: s2
port: 80
- conditions:
# matches
# - /child/bar/stats
# - /child/foo/stats
# and so on and so forth
- regex: /.*/stats
services:
- name: s3
port: 80
apiVersion: projectcontour.io/v1
kind: HTTPProxy
metadata:
name: httpproxy-header-matching
spec:
fqdn: local.projectcontour.io
routes:
- conditions:
- queryParam:
# matches header `x-header` with value of `dev-value` or `prod-value`
name: x-header
regex: (dev|prod)-value
services:
- name: s4
port: 80
(#5319, @clayton-gonsalves)
New critical access log level was introduced to reduce the volume of logs for busy installations. Critical level produces access logs for response status >= 500.
(#5360, @davinci26)
This Change adds the ability to define a default global rate limit policy in the Contour configuration
to be used as a global rate limit policy by all HTTPProxy objects.
HTTPProxy object can decide to opt out and disable this feature using disabled
config.
apiVersion: v1
kind: ConfigMap
metadata:
name: contour
namespace: projectcontour
data:
contour.yaml: |
rateLimitService:
extensionService: projectcontour/ratelimit
domain: contour
failOpen: false
defaultGlobalRateLimitPolicy:
descriptors:
- entries:
- remoteAddress: {}
- entries:
- genericKey:
value: foo
(#5363, @shadialtarsha)
Support setting of MaxRequestsPerConnection on listeners or clusters via the contour configuration.
(#5417, @clayton-gonsalves)
In some (particularly local development) environments the automaxprocs library fails due to the cgroup namespace setup.
This failure is no longer fatal for Contour.
Contour will now simply log the error and continue with the automatic GOMAXPROCS detection ignored.
(#5427, @sunjayBhatia)
For conformance with Gateway API v0.7.1+, routes that utilize HTTP method matching now have an explicit precedence over routes with header/query matches.
See the Gateway API documentation for a description of this precedence order.
This change applies not only to HTTPRoute but also HTTPProxy method matches (implemented in configuration via a header match on the :method
header).
(#5434, @sunjayBhatia)
Previously Contour would strip any port from the Host header in a downstream request for convenience in routing.
This resulted in backends not receiving the Host header with a port.
We no longer do this, for conformance with Gateway API (this change also applies to HTTPProxy and Ingress configuration).
(#5437, @sunjayBhatia)
Contour now supports Gateway API's TCPRoute resource.
This route type provides simple TCP forwarding for traffic received on a given Listener port.
This is a simple example of a Gateway and TCPRoute configuration:
kind: Gateway
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
name: contour
namespace: projectcontour
spec:
gatewayClassName: contour
listeners:
- name: tcp-listener
protocol: TCP
port: 10000
allowedRoutes:
namespaces:
from: All
---
apiVersion: gateway.networking.k8s.io/v1alpha2
kind: TCPRoute
metadata:
name: echo-1
namespace: default
spec:
parentRefs:
- namespace: projectcontour
name: contour
sectionName: tcp-listener
rules:
- backendRefs:
- name: s1
port: 80
(#5471, @skriss)
Contour now supports using TLSRoute and TCPRoute in combination with TLS termination.
To use this feature, create a Gateway with a Listener like the following:
- name: tls-listener
protocol: TLS
port: 5000
tls:
mode: Terminate
certificateRefs:
- name: tls-cert-secret
allowedRoutes:
namespaces:
from: All
---
It is then possible to attach either 1+ TLSRoutes, or a single TCPRoute, to this Listener.
If using TLSRoute, traffic can be routed to a different backend based on SNI.
If using TCPRoute, all traffic is forwarded to the backend referenced in the route.
(#5481, @skriss)
per_connection_buffer_limit_bytes
value for ClustersAllow changing per_connection_buffer_limit_bytes
for all Clusters. Default is not set to keep compatibility with existing configurations. Envoy recommends setting to 32KiB for Edge proxies.
(#5493, @rajatvig)
per_connection_buffer_limit_bytes
value for ListenersAllow changing per_connection_buffer_limit_bytes
for Listeners. Default is not set to keep compatibility with existing configurations.
Envoy recommends setting to 32KiB for Edge proxies.
(#5513, @rajatvig)
This ensures that the order of execution of extauth and global ratelimit is the same across HTTP and HTTPS virtualhosts, which is Auth goes first then Global ratelimit. (#5559, @clayton-gonsalves)
Adds support for IgnoreCase
in route header matching condition. This brings parity to matching capabilities of query param.
(#5567, @davinci26)
TreatMissingAsEmpty
specifies if the header match rule specified header does not exist, this header value will be treated as empty. Defaults to false.
Unlike the underlying Envoy implementation this is only supported for negative matches (e.g. NotContains, NotExact).
(#5584, @davinci26)
Currently, Contour supports a single RequestMirror filter per rule in HTTPRoute or GRPCRoute.
Envoy however, supports more than one mirror backend using request_mirror_policies
This PR adds support for multiple gateway-api RequestMirror filters within the same HTTP or GRPC rule.
(#5652, @LiorLieberman)
Contour now supports Gateway API v0.8.0, keeping up to date with conformance and API changes.
This release mainly contains refinements to status conditions, conformance test additions, and the addition of CEL validation for Gateway API CRDs.
The previous version of Contour supported Gateway API v0.6.2 and there have been multiple releases in the interim.
See v0.7.0 release notes, v0.7.1 release notes , and v0.8.0 release notes for more detail on the content of these releases.
(#5726, @sunjayBhatia)
ipFamilyPolicy
field to ContourDeployment.spec.envoy.networkPublishing
to control dual-stack-ness of the generated service. (#5386, @Jean-Daniel)Ingress.spec.tls.secretName
with certificate delegation and projectcontour.io/tls-cert-namespace
annotation. (#5463, @tsaarni)contour-certgen-v1-26-0
instead of contour-certgen-v1.26.0
to follow Kubernetes pod naming rules. (#5484, @tsaarni)mirror: true
and a weight
of 1-100. See the traffic mirroring docs for more information. (#5516, @hshamji)1.2
and 1.3
with a default of 1.3
. (#5533, @izturn)Gateway.Status.Addresses
. Only the first IP was exposed before, even for dual-stack service. (#5651, @Jean-Daniel)ghcr.io/projectcontour/contour-authserver:v4
. (#5725, @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.26.0 is tested against Kubernetes 1.26 through 1.28.
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.
Published by skriss about 1 year ago
We are delighted to present version v1.26.0-rc.1 of Contour, our layer 7 HTTP reverse proxy for Kubernetes clusters.
A big thank you to everyone who contributed to the release.
Please note that this is pre-release software, and as such we do not recommend installing it in production environments.
Feedback and bug reports are welcome!
Contour now supports Gateway Listeners with many different ports.
Previously, Contour only allowed a single port for HTTP, and a single port for HTTPS/TLS.
As an example, the following Gateway, with two HTTP ports and two HTTPS ports, is now fully supported:
kind: Gateway
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
name: contour
spec:
gatewayClassName: contour
listeners:
- name: http-1
protocol: HTTP
port: 80
allowedRoutes:
namespaces:
from: Same
- name: http-2
protocol: HTTP
port: 81
allowedRoutes:
namespaces:
from: Same
- name: https-1
protocol: HTTPS
port: 443
allowedRoutes:
namespaces:
from: Same
tls:
mode: Terminate
certificateRefs:
- name: tls-cert-1
- name: https-2
protocol: HTTPS
port: 444
allowedRoutes:
namespaces:
from: Same
tls:
mode: Terminate
certificateRefs:
- name: tls-cert-2
If you are using the Contour Gateway Provisioner, ports for all valid Listeners will automatically be exposed via the Envoy service, and will update when any Listener changes are made.
If you are using static provisioning, you must keep the Service definition in sync with the Gateway spec manually.
Note that if you are using the Contour Gateway Provisioner along with HTTPProxy or Ingress for routing, then your Gateway must have exactly one HTTP Listener and one HTTPS Listener.
For this case, Contour supports a custom HTTPS Listener protocol value, to avoid having to specify TLS details in the Listener (since they're specified in the HTTPProxy or Ingress instead):
kind: Gateway
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
name: contour-with-httpproxy
spec:
gatewayClassName: contour
listeners:
- name: http
protocol: HTTP
port: 80
allowedRoutes:
namespaces:
from: All
- name: https
protocol: projectcontour.io/https
port: 443
allowedRoutes:
namespaces:
from: All
(#5160, @skriss)
Metrics on status update counts and duration are now output by the xDS server.
This should enable deployments at scale to diagnose delays in status updates and possibly tune the --kubernetes-client-qps
and --kubernetes-client-burst
flags.
(#5037, @sunjayBhatia)
The contour serve
command takes a new optional flag, --watch-namespaces
, that can
be used to restrict the namespaces where the Contour instance watches for resources.
Consequently, resources in other namespaces will not be known to Contour and will not
be acted upon.
You can watch a single or multiple namespaces, and you can further restrict the root
namespaces with --root-namespaces
just like before. Root namespaces must be a subset
of the namespaces being watched, for example:
--watch-namespaces=my-admin-namespace,my-app-namespace --root-namespaces=my-admin-namespace
If the --watch-namespaces
flag is not used, then all namespaces will be watched by default.
(#5214, @nsimons)
This Change Adds 2 features to HTTPProxy
In addition to prefix
and exact
, HTTPProxy now also support regex
.
apiVersion: projectcontour.io/v1
kind: HTTPProxy
metadata:
name: root-regex-match
spec:
fqdn: local.projectcontour.io
routes:
- conditions:
# matches
# - /list/1234
# - /list/
# - /list/foobar
# and so on and so forth
- regex: /list/.*
services:
- name: s1
port: 80
- conditions:
# matches
# - /admin/dev
# - /admin/prod
- regex: /admin/(prod|dev)
services:
- name: s2
port: 80
apiVersion: projectcontour.io/v1
kind: HTTPProxy
metadata:
name: root-regex-match
spec:
fqdn: local.projectcontour.io
includes:
- name: child-regex-match
conditions:
- prefix: /child
routes:
- conditions:
- prefix: /
services:
- name: s1
port: 80
apiVersion: projectcontour.io/v1
kind: HTTPProxy
metadata:
name: child-regex-match
spec:
fqdn: local.projectcontour.io
routes:
- conditions:
# matches
# - /child/list/1234
# - /child/list/
# - /child/list/foobar
# and so on and so forth
- regex: /list/.*
services:
- name: s1
port: 80
- conditions:
# matches
# - /child/admin/dev
# - /child/admin/prod
- regex: /admin/(prod|dev)
services:
- name: s2
port: 80
- conditions:
# matches
# - /child/bar/stats
# - /child/foo/stats
# and so on and so forth
- regex: /.*/stats
services:
- name: s3
port: 80
apiVersion: projectcontour.io/v1
kind: HTTPProxy
metadata:
name: httpproxy-header-matching
spec:
fqdn: local.projectcontour.io
routes:
- conditions:
- queryParam:
# matches header `x-header` with value of `dev-value` or `prod-value`
name: x-header
regex: (dev|prod)-value
services:
- name: s4
port: 80
(#5319, @clayton-gonsalves)
Contour now supports Gateway API v0.7.1, keeping up to date with conformance and API changes.
This release mainly contains refinements to status conditions and conformance test additions.
See v0.7.0 release notes and v0.7.1 release notes .
(#5353, @sunjayBhatia)
New critical access log level was introduced to reduce the volume of logs for busy installations. Critical level produces access logs for response status >= 500.
(#5360, @davinci26)
This Change adds the ability to define a default global rate limit policy in the Contour configuration
to be used as a global rate limit policy by all HTTPProxy objects.
HTTPProxy object can decide to opt out and disable this feature using disabled
config.
apiVersion: v1
kind: ConfigMap
metadata:
name: contour
namespace: projectcontour
data:
contour.yaml: |
rateLimitService:
extensionService: projectcontour/ratelimit
domain: contour
failOpen: false
defaultGlobalRateLimitPolicy:
descriptors:
- entries:
- remoteAddress: {}
- entries:
- genericKey:
value: foo
(#5363, @shadialtarsha)
Support setting of MaxRequestsPerConnection on listeners or clusters via the contour configuration.
(#5417, @clayton-gonsalves)
In some (particularly local development) environments the automaxprocs library fails due to the cgroup namespace setup.
This failure is no longer fatal for Contour.
Contour will now simply log the error and continue with the automatic GOMAXPROCS detection ignored.
(#5427, @sunjayBhatia)
For conformance with Gateway API v0.7.1+, routes that utilize HTTP method matching now have an explicit precedence over routes with header/query matches.
See the Gateway API documentation for a description of this precedence order.
This change applies not only to HTTPRoute but also HTTPProxy method matches (implemented in configuration via a header match on the :method
header).
(#5434, @sunjayBhatia)
Previously Contour would strip any port from the Host header in a downstream request for convenience in routing.
This resulted in backends not receiving the Host header with a port.
We no longer do this, for conformance with Gateway API (this change also applies to HTTPProxy and Ingress configuration).
(#5437, @sunjayBhatia)
Contour now supports Gateway API's TCPRoute resource.
This route type provides simple TCP forwarding for traffic received on a given Listener port.
This is a simple example of a Gateway and TCPRoute configuration:
kind: Gateway
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
name: contour
namespace: projectcontour
spec:
gatewayClassName: contour
listeners:
- name: tcp-listener
protocol: TCP
port: 10000
allowedRoutes:
namespaces:
from: All
---
apiVersion: gateway.networking.k8s.io/v1alpha2
kind: TCPRoute
metadata:
name: echo-1
namespace: default
spec:
parentRefs:
- namespace: projectcontour
name: contour
sectionName: tcp-listener
rules:
- backendRefs:
- name: s1
port: 80
(#5471, @skriss)
Contour now supports using TLSRoute and TCPRoute in combination with TLS termination.
To use this feature, create a Gateway with a Listener like the following:
- name: tls-listener
protocol: TLS
port: 5000
tls:
mode: Terminate
certificateRefs:
- name: tls-cert-secret
allowedRoutes:
namespaces:
from: All
---
It is then possible to attach either 1+ TLSRoutes, or a single TCPRoute, to this Listener.
If using TLSRoute, traffic can be routed to a different backend based on SNI.
If using TCPRoute, all traffic is forwarded to the backend referenced in the route.
(#5481, @skriss)
per_connection_buffer_limit_bytes
value for ClustersAllow changing per_connection_buffer_limit_bytes
for all Clusters. Default is not set to keep compatibility with existing configurations. Envoy recommends setting to 32KiB for Edge proxies.
(#5493, @rajatvig)
per_connection_buffer_limit_bytes
value for ListenersAllow changing per_connection_buffer_limit_bytes
for Listeners. Default is not set to keep compatibility with existing configurations.
Envoy recommends setting to 32KiB for Edge proxies.
(#5513, @rajatvig)
Adds support for IgnoreCase
in route header matching condition. This brings parity to matching capabilities of query param.
(#5567, @davinci26)
TreatMissingAsEmpty
specifies if the header match rule specified header does not exist, this header value will be treated as empty. Defaults to false.
Unlike the underlying Envoy implementation this is only supported for negative matches (e.g. NotContains, NotExact).
(#5584, @davinci26)
This ensures that the order of execution of extauth and global ratelimit is the same across HTTP and HTTPS virtualhosts, which is Auth goes first then Global ratelimit.
(#5559, @clayton-gonsalves)
ipFamilyPolicy
field to ContourDeployment.spec.envoy.networkPublishing
to control dual-stack-ness of the generated service. (#5386, @Jean-Daniel)Ingress.spec.tls.secretName
with certificate delegation and projectcontour.io/tls-cert-namespace
annotation. (#5463, @tsaarni)contour-certgen-v1-26-0
instead of contour-certgen-v1.26.0
to follow Kubernetes pod naming rules. (#5484, @tsaarni)mirror: true
and a weight
of 1-100. See the traffic mirroring docs for more information. (#5516, @hshamji)The simplest way to install v1.26.0-rc.1 is to apply one of the example configurations:
With Gateway API:
kubectl apply -f https://raw.githubusercontent.com/projectcontour/contour/v1.26.0-rc.1/examples/render/contour-gateway.yaml
Without Gateway API:
kubectl apply -f https://raw.githubusercontent.com/projectcontour/contour/v1.26.0-rc.1/examples/render/contour.yaml
Contour v1.26.0-rc.1 is tested against Kubernetes 1.25 through 1.27.
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.
Published by sunjayBhatia about 1 year ago
We are delighted to present version v1.25.2 of Contour, our layer 7 HTTP reverse proxy for Kubernetes clusters.
For a fresh install of Contour, consult the getting started documentation.
To upgrade an existing Contour installation, please consult the upgrade documentation.
Contour v1.25.2 is tested against Kubernetes 1.25 through 1.27.
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.
Published by sunjayBhatia about 1 year ago
We are delighted to present version v1.25.1 of Contour, our layer 7 HTTP reverse proxy for Kubernetes clusters.
For a fresh install of Contour, consult the getting started documentation.
To upgrade an existing Contour installation, please consult the upgrade documentation.
Contour v1.25.1 is tested against Kubernetes 1.25 through 1.27.
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.
Published by sunjayBhatia about 1 year ago
We are delighted to present version v1.24.5 of Contour, our layer 7 HTTP reverse proxy for Kubernetes clusters.
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.5 is tested against Kubernetes 1.24 through 1.26.
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.
Published by skriss about 1 year ago
We are delighted to present version v1.23.6 of Contour, our layer 7 HTTP reverse proxy for Kubernetes clusters.
For a fresh install of Contour, consult the getting started documentation.
To upgrade an existing Contour installation, please consult the upgrade documentation.
Contour v1.23.6 is tested against Kubernetes 1.23 through 1.25.
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.
Published by skriss over 1 year ago
We are delighted to present version v1.25.0 of Contour, our layer 7 HTTP reverse proxy for Kubernetes clusters.
A big thank you to everyone who contributed to the release.
Contour's HTTPProxy now supports configuring Envoy's RBAC filter for allowing or denying requests by IP.
An HTTPProxy can optionally include one or more IP filter rules, which define CIDR ranges to allow or deny requests based on origin IP. Filters can indicate whether the direct IP should be used or whether a reported IP from PROXY
or X-Forwarded-For
should be used instead. If the latter, Contour's numTrustedHops
setting will be respected when determining the source IP. Filters defined at the VirtualHost level apply to all routes, unless overridden by a route-specific filter.
For more information, see:
(#5008, @ecordell)
Contour now supports exporting tracing data to OpenTelemetry
The Contour configuration file and ContourConfiguration CRD will be extended with a new optional tracing
section. This configuration block, if present, will enable tracing and will define the trace properties needed to generate and export trace data.
contour
.100
.256
.(#5043, @yangyy93)
Contour now supports external authorization for all hosts by setting the config as part of the contourConfig
like so:
globalExtAuth:
extensionService: projectcontour-auth/htpasswd
failOpen: false
authPolicy:
context:
header1: value1
header2: value2
responseTimeout: 1s
Individual hosts can also override or opt out of this global configuration.
You can read more about this feature in detail in the guide.
(#4994, @clayton-gonsalves)
HttpProxy conditions block now also supports exact path match condition.
(#5000, @arjunsalyan)
Contour now supports specifying an internalRedirectPolicy
on a Route
to handle 3xx redirects internally, that is capturing a configurable 3xx redirect response, synthesizing a new request, sending it to the upstream specified by the new route match, and returning the redirected response as the response to the original request.
(#5010, @Jean-Daniel)
Contour now implements HTTP query parameter matching for HTTPProxy resource-based routes. It supports Exact
, Prefix
, Suffix
, Regex
and Contains
string matching conditions together with the IgnoreCase
modifier and also the Present
matching condition. For example, the following HTTPProxy will route requests based on the configured condition examples for the given query parameter search
:
apiVersion: projectcontour.io/v1
kind: HTTPProxy
metadata:
name: httpproxy-queryparam-matching
spec:
routes:
- conditions:
- queryParam:
# will match e.g. '?search=example' as is
name: search
exact: example
services:
- name: s1
port: 80
- conditions:
- queryParam:
# will match e.g. '?search=prefixthis' or any string value prefixed by `prefix` (case insensitive)
name: search
prefix: PreFix
ignoreCase: true
services:
- name: s2
port: 80
- conditions:
- queryParam:
# will match e.g. '?search=thispostfix' or any string value suffixed by `postfix` (case sensitive)
name: search
suffix: postfix
services:
- name: s3
port: 80
- conditions:
- queryParam:
# will match e.g. '?search=regularexp123' or any string value matching the given regular expression
name: search
regex: ^regular.*
services:
- name: s4
port: 80
- conditions:
- queryParam:
# will match e.g. '?search=somethinginsideanother' or any string value containing the substring 'inside' (case sensitive)
name: search
contains: inside
services:
- name: s5
port: 80
- conditions:
- queryParam:
# will match e.g. '?search=' or any string value given to the named parameter
name: search
present: true
services:
- name: s6
port: 80
(#5036, @relu)
The contour serve
command takes a new optional flag, --disable-feature
, that allows disabling certain features.
The flag is used to disable the informer for a custom resource, effectively making the corresponding CRD optional in the cluster. You can provide the flag multiple times.
Current options include extensionservices
and the experimental Gateway API features tlsroutes
and grpcroutes
.
For example, to disable ExtensionService CRD, use the flag as follows: --disable-feature=extensionservices
.
(#5080, @nsimons)
Contour now implements GRPCRoute (https://gateway-api.sigs.k8s.io/api-types/grpcroute/). The "core conformance" parts of the spec are implemented. See https://projectcontour.io/docs/1.25/guides/grpc/#gateway-api-configuration on how to use GRPCRoute.
(#5114, @fangfpeng)
AllowPrivateNetwork
to CORSPolicy
for support Access-Control-Allow-Private-Network. (#5034, @lvyanru8200)path
field on the HTTPRoute RequestRedirect filter. (#5068, @skriss)contour_dag_cache_object
, to indicate the total number of items that are currently in the DAG cache. (#5109, @izturn)NotImplemented
condition with the upstream Accepted: false
condition with reason UnsupportedValue
to match the spec. (#5125, @skriss)%REQ()
operator in request/response header policies now properly supports HTTP/2 pseudo-headers, header fallbacks, and truncating header values. (#5130, @sunjayBhatia)GOMAXPROCS
to match the number of CPUs available to the container which results in lower and more stable CPU usage under high loads and where the container and node CPU counts differ significantly.GOMAXPROCS
to a fixed value as an environment variable. (#5211, @rajatvig)envoy.health.port
and envoy.metrics.port
if they are defined in ContourDeployment.spec.runtimeSettings
. (#5233, @Jean-Daniel)For a fresh install of Contour, consult the getting started documentation.
To upgrade an existing Contour installation, please consult the upgrade documentation.
Contour v1.25.0 is tested against Kubernetes 1.25 through 1.27.
We’re immensely grateful for all the community contributions that help make Contour even better! For this release, we would like to give a special shoutout to the folks who joined our ContribFest at KubeCon EU 2023:
We'd also like to thank the other contributors to this release:
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.
Published by sunjayBhatia over 1 year ago
We are delighted to present version v1.24.4 of Contour, our layer 7 HTTP reverse proxy for Kubernetes clusters.
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.4 is tested against Kubernetes 1.24 through 1.26.
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.
Published by skriss over 1 year ago
We are delighted to present version v1.25.0-rc.1 of Contour, our layer 7 HTTP reverse proxy for Kubernetes clusters.
A big thank you to everyone who contributed to the release.
Please note that this is pre-release software, and as such we do not recommend installing it in production environments.
Feedback and bug reports are welcome!
Contour's HTTPProxy now supports configuring Envoy's RBAC filter for allowing or denying requests by IP.
An HTTPProxy can optionally include one or more IP filter rules, which define CIDR ranges to allow or deny requests based on origin IP.
Filters can indicate whether the direct IP should be used or whether a reported IP from PROXY
or X-Forwarded-For
should be used instead.
If the latter, Contour's numTrustedHops
setting will be respected when determining the source IP.
Filters defined at the VirtualHost level apply to all routes, unless overridden by a route-specific filter.
For more information, see:
(#5008, @ecordell)
Contour now supports exporting tracing data to OpenTelemetry
The Contour configuration file and ContourConfiguration CRD will be extended with a new optional tracing
section. This configuration block, if present, will enable tracing and will define the trace properties needed to generate and export trace data.
contour
.100
.256
.(#5043, @yangyy93)
Contour now supports external authorization for all hosts by setting the config as part of the contourConfig
like so:
globalExtAuth:
extensionService: projectcontour-auth/htpasswd
failOpen: false
authPolicy:
context:
header1: value1
header2: value2
responseTimeout: 1s
Individual hosts can also override or opt out of this global configuration.
You can read more about this feature in detail in the guide.
(#4994, @clayton-gonsalves)
HttpProxy conditions block now also supports exact path match condition.
(#5000, @arjunsalyan)
Contour now supports specifying an internalRedirectPolicy
on a Route
to handle 3xx redirects internally, that is capturing a configurable 3xx redirect response, synthesizing a new request,
sending it to the upstream specified by the new route match,
and returning the redirected response as the response to the original request.
(#5010, @Jean-Daniel)
Contour now implements HTTP query parameter matching for HTTPProxy
resource-based routes. It supports Exact
, Prefix
, Suffix
, Regex
and
Contains
string matching conditions together with the IgnoreCase
modifier
and also the Present
matching condition.
For example, the following HTTPProxy will route requests based on the configured
condition examples for the given query parameter search
:
apiVersion: projectcontour.io/v1
kind: HTTPProxy
metadata:
name: httpproxy-queryparam-matching
spec:
routes:
- conditions:
- queryParam:
# will match e.g. '?search=example' as is
name: search
exact: example
services:
- name: s1
port: 80
- conditions:
- queryParam:
# will match e.g. '?search=prefixthis' or any string value prefixed by `prefix` (case insensitive)
name: search
prefix: PreFix
ignoreCase: true
services:
- name: s2
port: 80
- conditions:
- queryParam:
# will match e.g. '?search=thispostfix' or any string value suffixed by `postfix` (case sensitive)
name: search
suffix: postfix
services:
- name: s3
port: 80
- conditions:
- queryParam:
# will match e.g. '?search=regularexp123' or any string value matching the given regular expression
name: search
regex: ^regular.*
services:
- name: s4
port: 80
- conditions:
- queryParam:
# will match e.g. '?search=somethinginsideanother' or any string value containing the substring 'inside' (case sensitive)
name: search
contains: inside
services:
- name: s5
port: 80
- conditions:
- queryParam:
# will match e.g. '?search=' or any string value given to the named parameter
name: search
present: true
services:
- name: s6
port: 80
(#5036, @relu)
The contour serve
command takes a new optional flag, --disable-feature
, that allows disabling
certain features.
The flag is used to disable the informer for a custom resource, effectively making the corresponding
CRD optional in the cluster. You can provide the flag multiple times.
Current options include extensionservices
and the experimental Gateway API features tlsroutes
and
grpcroutes
.
For example, to disable ExtensionService CRD, use the flag as follows: --disable-feature=extensionservices
.
(#5080, @nsimons)
Contour now implements GRPCRoute (https://gateway-api.sigs.k8s.io/api-types/grpcroute/).
The "core conformance" parts of the spec are implemented.
See https://projectcontour.io/docs/v1.25.0/guides/grpc/#gateway-api-configuration
on how to use GRPCRoute.
(#5114, @fangfpeng)
AllowPrivateNetwork
to CORSPolicy
for support Access-Control-Allow-Private-Network. (#5034, @lvyanru8200)path
field on the HTTPRoute RequestRedirect filter. (#5068, @skriss)contour_dag_cache_object
, to indicate the total number of items that are currently in the DAG cache. (#5109, @izturn)NotImplemented
condition with the upstream Accepted: false
condition with reason UnsupportedValue
to match the spec. (#5125, @skriss)%REQ()
operator in request/response header policies now properly supports HTTP/2 pseudo-headers, header fallbacks, and truncating header values. (#5130, @sunjayBhatia)GOMAXPROCS
to match the number of CPUs available to the container which results in lower and more stable CPU usage under high loads and where the container and node CPU counts differ significantly.GOMAXPROCS
to a fixed value as an environment variable. (#5211, @rajatvig)envoy.health.port
and envoy.metrics.port
if they are defined in ContourDeployment.spec.runtimeSettings
. (#5233, @Jean-Daniel)The simplest way to install v1.25.0-rc.1 is to apply one of the example configurations:
With Gateway API:
kubectl apply -f https://raw.githubusercontent.com/projectcontour/contour/v1.25.0-rc.1/examples/render/contour-gateway.yaml
Without Gateway API:
kubectl apply -f https://raw.githubusercontent.com/projectcontour/contour/v1.25.0-rc.1/examples/render/contour.yaml
Contour v1.25.0-rc.1 is tested against Kubernetes 1.25 through 1.27.
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.
Published by sunjayBhatia over 1 year ago
We are delighted to present version v1.24.3 of Contour, our layer 7 HTTP reverse proxy for Kubernetes clusters.
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.3 is tested against Kubernetes 1.24 through 1.26.
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.
Published by sunjayBhatia over 1 year ago
We are delighted to present version v1.23.5 of Contour, our layer 7 HTTP reverse proxy for Kubernetes clusters.
For a fresh install of Contour, consult the getting started documentation.
To upgrade an existing Contour installation, please consult the upgrade documentation.
Contour v1.23.5 is tested against Kubernetes 1.23 through 1.25.
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.
Published by sunjayBhatia over 1 year ago
We are delighted to present version v1.22.6 of Contour, our layer 7 HTTP reverse proxy for Kubernetes clusters.
For a fresh install of Contour, consult the getting started documentation.
To upgrade an existing Contour installation, please consult the upgrade documentation.
Contour v1.22.6 is tested against Kubernetes 1.22 through 1.24.
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.
Published by skriss over 1 year ago
We are delighted to present version v1.22.5 of Contour, our layer 7 HTTP reverse proxy for Kubernetes clusters.
For a fresh install of Contour, consult the getting started documentation.
To upgrade an existing Contour installation, please consult the upgrade documentation.
Contour v1.22.5 is tested against Kubernetes 1.22 through 1.24.
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.
Published by skriss over 1 year ago
We are delighted to present version v1.23.4 of Contour, our layer 7 HTTP reverse proxy for Kubernetes clusters.
For a fresh install of Contour, consult the getting started documentation.
To upgrade an existing Contour installation, please consult the upgrade documentation.
Contour v1.23.4 is tested against Kubernetes 1.23 through 1.25.
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.
Published by skriss over 1 year ago
We are delighted to present version v1.24.2 of Contour, our layer 7 HTTP reverse proxy for Kubernetes clusters.
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.2 is tested against Kubernetes 1.24 through 1.26.
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.