Release 1.33.0 docs (#7212)

Signed-off-by: Sunjay Bhatia <[email protected]>

Author: sunjayBhatia

.github/dependabot.yml

@@ -33,7 +33,7 @@ updates:
       - "actions/download-artifact"
 
 # release branch N targets
-- target-branch: release-1.32
+- target-branch: release-1.33
   package-ecosystem: "gomod"
   directory: "/"
   schedule:
@@ -51,7 +51,7 @@ updates:
     k8s-dependencies:
       patterns:
       - "k8s.io/*"
-- target-branch: release-1.32
+- target-branch: release-1.33
   package-ecosystem: "github-actions"
   directory: "/"
   schedule:
@@ -72,7 +72,7 @@ updates:
       - "actions/download-artifact"
 
 # release branch N-1 targets
-- target-branch: release-1.31
+- target-branch: release-1.32
   package-ecosystem: "gomod"
   directory: "/"
   schedule:
@@ -90,7 +90,7 @@ updates:
     k8s-dependencies:
       patterns:
       - "k8s.io/*"
-- target-branch: release-1.31
+- target-branch: release-1.32
   package-ecosystem: "github-actions"
   directory: "/"
   schedule:
@@ -111,7 +111,7 @@ updates:
       - "actions/download-artifact"
 
 # release branch N-2 targets
-- target-branch: release-1.30
+- target-branch: release-1.31
   package-ecosystem: "gomod"
   directory: "/"
   schedule:
@@ -129,7 +129,7 @@ updates:
     k8s-dependencies:
       patterns:
       - "k8s.io/*"
-- target-branch: release-1.30
+- target-branch: release-1.31
   package-ecosystem: "github-actions"
   directory: "/"
   schedule:

.github/workflows/trivy-scan.yaml

@@ -16,9 +16,9 @@ jobs:
       matrix:
         branch:
         - main
+        - release-1.33
         - release-1.32
         - release-1.31
-        - release-1.30
     runs-on: ubuntu-latest
     permissions:
       security-events: write

changelogs/CHANGELOG-v1.33.0.md

@@ -0,0 +1,53 @@
+We are delighted to present version v1.33.0 of Contour, our layer 7 HTTP reverse proxy for Kubernetes clusters.
+
+A big thank you to everyone who contributed to the release.
+
+
+- [Minor Changes](#minor-changes)
+- [Other Changes](#other-changes)
+- [Installing/Upgrading](#installing-and-upgrading)
+- [Compatible Kubernetes Versions](#compatible-kubernetes-versions)
+- [Community Thanks!](#community-thanks)
+
+
+# Minor Changes
+
+## Distroless Envoy image
+
+The Envoy image used in the example manifests and as the default image in the Gateway Provisioner has been switched to the [distroless](https://www.envoyproxy.io/docs/envoy/latest/start/install#image-variants) variant.
+
+Previously, it was based on Ubuntu and included a minimal OS with a package manager.
+The distroless variant contains only the files required to run Envoy, improving security.
+
+(#7170, @tsaarni)
+
+
+## Update to Gateway API v1.3.0
+
+Gateway API CRD compatibility has been updated to release v1.3.0.
+
+Full release notes for Gateway API v1.3.0 can be found [here](https://github.com/kubernetes-sigs/gateway-api/releases/tag/v1.3.0).
+
+
+# Other Changes
+- Update to Go 1.25.1. See the [Go release notes](https://go.dev/doc/devel/release#go1.25.minor) for more information. (#7211, @sunjayBhatia)
+- Updates Envoy to v1.35.2. See the [Envoy release notes](https://www.envoyproxy.io/docs/envoy/v1.35.2/version_history/v1.35/v1.35) for more information about the content of the release. (#7197, @sunjayBhatia)
+
+
+# Installing and Upgrading
+
+For a fresh install of Contour, consult the [getting started documentation](https://projectcontour.io/getting-started/).
+
+To upgrade an existing Contour installation, please consult the [upgrade documentation](https://projectcontour.io/resources/upgrading/).
+
+
+# Compatible Kubernetes Versions
+
+Contour v1.33.0 is tested against Kubernetes 1.32 through 1.34.
+
+# Community Thanks!
+We’re immensely grateful for all the community contributions that help make Contour even better!
+
+
+# Are you a Contour user? We would love to know!
+If you're using Contour and want to add your organization to our adopters list, please visit this [page](https://projectcontour.io/resources/adopters/). 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](https://github.com/projectcontour/contour/issues/1269).

changelogs/unreleased/7170-tsaarni-minor.md

@@ -42,7 +42,7 @@
 # kubectl apply https://projectcontour.io/quickstart/contour.yaml
 [[redirects]]
   from = "/quickstart/contour.yaml"
-  to = "https://raw.githubusercontent.com/projectcontour/contour/release-1.32/examples/render/contour.yaml"
+  to = "https://raw.githubusercontent.com/projectcontour/contour/release-1.33/examples/render/contour.yaml"
   status = 302
 
 # Redirect versioned quickstarts so that they can easily be referenced by
@@ -59,7 +59,7 @@
 # kubectl apply https://projectcontour.io/quickstart/contour-gateway.yaml
 [[redirects]]
   from = "/quickstart/contour-gateway.yaml"
-  to = "https://raw.githubusercontent.com/projectcontour/contour/release-1.32/examples/render/contour-gateway.yaml"
+  to = "https://raw.githubusercontent.com/projectcontour/contour/release-1.33/examples/render/contour-gateway.yaml"
   status = 302
 
 # Redirect versioned quickstarts so that they can easily be referenced by
@@ -76,7 +76,7 @@
 # kubectl apply https://projectcontour.io/quickstart/contour-gateway-provisioner.yaml
 [[redirects]]
   from = "/quickstart/contour-gateway-provisioner.yaml"
-  to = "https://raw.githubusercontent.com/projectcontour/contour/release-1.32/examples/render/contour-gateway-provisioner.yaml"
+  to = "https://raw.githubusercontent.com/projectcontour/contour/release-1.33/examples/render/contour-gateway-provisioner.yaml"
   status = 302
 
 # Redirect versioned quickstarts so that they can easily be referenced by

changelogs/unreleased/7197-sunjayBhatia-small.md

@@ -28,7 +28,7 @@ params:
   github_url: "https://github.com/projectcontour/contour"
   github_raw_url: "https://raw.githubusercontent.com/projectcontour/contour"
   slack_url: "https://kubernetes.slack.com/messages/contour"
-  latest_version: "1.32"
+  latest_version: "1.33"
   use_advanced_docs: true
   docs_right_sidebar: true
   docs_search: true
@@ -38,6 +38,7 @@ params:
   docs_versioning: true
   docs_versions:
   - main
+  - "1.33"
   - "1.32"
   - "1.31"
   - "1.30"

changelogs/unreleased/7211-sunjayBhatia-small.md

@@ -0,0 +1,48 @@
+---
+cascade:
+  layout: docs
+  version: "1.33"
+  branch: release-1.33
+---
+
+## Overview
+Contour is an Ingress controller for Kubernetes that works by deploying the [Envoy proxy][1] as a reverse proxy and load balancer.
+Contour supports dynamic configuration updates out of the box while maintaining a lightweight profile.
+
+## Philosophy
+- Follow an opinionated approach which allows us to better serve most users
+- Design Contour to serve both the cluster administrator and the application developer
+- Use our experience with ingress to define reasonable defaults for both cluster administrators and application developers.
+- Meet users where they are by understanding and adapting Contour to their use cases
+
+See the full [Contour Philosophy][8] page.
+
+## Why Contour?
+Contour bridges other solution gaps in several ways:
+- Dynamically update the ingress configuration with minimal dropped connections
+- Safely support multiple types of ingress config in multi-team Kubernetes clusters
+  - [Ingress/v1][10]
+  - [HTTPProxy (Contour custom resource)][2]
+  - [Gateway API][9]
+- Cleanly integrate with the Kubernetes object model
+
+## Prerequisites
+Contour is tested with Kubernetes clusters running version [1.21 and later][4].
+
+## Get started
+Getting started with Contour is as simple as one command.
+See the [Getting Started][3] document.
+
+## Troubleshooting
+If you encounter issues review the [troubleshooting][5] page, [file an issue][6], or talk to us on the [#contour channel][7] on Kubernetes slack.
+
+[1]: https://www.envoyproxy.io/
+[2]: config/fundamentals.md
+[3]: /getting-started
+[4]: /resources/compatibility-matrix.md
+[5]: /docs/main/troubleshooting
+[6]: https://github.com/projectcontour/contour/issues
+[7]: https://kubernetes.slack.com/messages/contour
+[8]: /resources/philosophy
+[9]: guides/gateway-api
+[10]: /docs/{{< param version >}}/config/ingress

netlify.toml

@@ -0,0 +1,74 @@
+# Contour Architecture
+
+The Contour Ingress controller is a collaboration between:
+
+* Envoy, which provides the high performance reverse proxy.
+* Contour, which acts as a management server for Envoy and provides it with configuration.
+
+These containers are deployed separately, Contour as a Deployment and Envoy as a Kubernetes Daemonset or Deployment, although other configurations are possible.
+
+In the Envoy Pods, Contour runs as an initcontainer in `bootstrap` mode and writes an Envoy bootstrap configuration to a temporary volume.
+This volume is passed to the Envoy container and directs Envoy to treat Contour as its [management server][1].
+
+After initialization is complete, the Envoy container starts, retrieves the bootstrap configuration written by Contour's `bootstrap` mode, and establishes a GRPC session with Contour to receive configuration.
+
+Envoy will gracefully retry if the management server is unavailable, which removes any container startup ordering issues.
+
+Contour is a client of the Kubernetes API.
+Contour watches Ingress, HTTPProxy, Gateway API, Secret, Service, and Endpoint objects, and acts as the management server for its Envoy sibling by translating its cache of objects into the relevant JSON stanzas: Service objects for CDS, Ingress for RDS, Endpoint objects for EDS, and so on).
+
+The transfer of information from Kubernetes to Contour is by watching the Kubernetes API utilizing [controller-runtime][4] primitives.
+
+Kubernetes readiness probes are configured to check whether Envoy is ready to accept connections.
+The Envoy readiness probe sends GET requests to `/ready` in Envoy's administration endpoint.
+
+For Contour, a liveness probe checks the `/healthz` running on the Pod's metrics port.
+Readiness probe is a check that Contour can access the Kubernetes API. 
+
+## Architectural Overview
+Below are a couple of high level architectural diagrams of how Contour works inside a Kubernetes cluster as well as showing the data path of a request to a backend pod.
+
+A request to `projectcontour.io/blog` gets routed via a load balancer to an instance of an Envoy proxy which then sends the request to a pod.
+
+![architectural overview][2]
+
+Following is a diagram of how Contour and Envoy are deployed in a Kubernetes cluster. 
+
+### Kubernetes API Server
+
+The following API objects are watched:
+- Services
+- Endpoints
+- Secrets
+- Ingress
+- HTTPProxy
+- Gateway API (Optional)
+
+### Contour Deployment
+
+Contour is deployed in the cluster using a Kubernetes Deployment.
+It has built-in leader election which is responsible for updating httproxy/ingress/gateway api resources via Kube API server.
+All instances are able to serve xDS configuration to any Envoy instance, but only the leader can write status back to the API server.
+
+The data being served from contour instances are eventually consistent in an HA based deployment.
+However HA mode is operationally scalable when you have high request rate from envoy to contour as requests are loadbalanced among contour instances.
+This also helps availability zone /data center degradation events as your service continue to function.
+
+### Envoy Deployment
+
+Envoy can be deployed in two different models, as a Kubernetes Daemonset or as a Kubernetes Deployment. 
+
+Daemonset is the standard deployment model where a single instance of Envoy is deployed per Kubernetes Node.
+This allows for simple Envoy pod distribution across the cluster as well as being able to expose Envoy using `hostPorts` to improve network performance. 
+One potential downside of this deployment model is when a node is removed from the cluster (e.g. on a cluster scale down, etc) then the configured `preStop` hooks are not available so connections can be dropped.
+This is a limitation that applies to any Daemonset in Kubernetes.
+
+An alternative Envoy deployment model is utilizing a Kubernetes Deployment with a configured `podAntiAffinity` which attempts to mirror the Daemonset deployment model.
+A benefit of this model compared to the Daemonset version is when a node is removed from the cluster, the proper shutdown events are available so connections can be cleanly drained from Envoy before terminating.
+
+![architectural overview 2][3]
+
+[1]: https://www.envoyproxy.io/docs/envoy/v1.13.0/api-docs/xds_protocol
+[2]: ../img/archoverview.png
+[3]: ../img/contour_deployment_in_k8s.png
+[4]: https://github.com/kubernetes-sigs/controller-runtime