Release NGF 1.6.1

content/ngf/get-started.md

@@ -90,7 +90,7 @@ make create-kind-cluster
 Use `kubectl` to add the API resources for NGINX Gateway Fabric with the following command:
 
 ```shell
-kubectl kustomize "https://github.com/nginx/nginx-gateway-fabric/config/crd/gateway-api/standard?ref=v1.5.1" | kubectl apply -f -
+kubectl kustomize "https://github.com/nginx/nginx-gateway-fabric/config/crd/gateway-api/standard?ref=v1.6.1" | kubectl apply -f -
 ```
 
 ```text
@@ -105,7 +105,7 @@ customresourcedefinition.apiextensions.k8s.io/referencegrants.gateway.networking
 To use experimental features, you'll need to install the API resources from the experimental channel instead.
 
 ```shell
-kubectl kustomize "https://github.com/nginx/nginx-gateway-fabric/config/crd/gateway-api/experimental?ref=v1.5.1" | kubectl apply -f -
+kubectl kustomize "https://github.com/nginx/nginx-gateway-fabric/config/crd/gateway-api/experimental?ref=v1.6.1" | kubectl apply -f -
 ```
 
 {{< /note >}}
@@ -121,7 +121,7 @@ helm install ngf oci://ghcr.io/nginx/charts/nginx-gateway-fabric --create-namesp
 ```
 
 ```text
-Pulled: ghcr.io/nginx/charts/nginx-gateway-fabric:1.5.1
+Pulled: ghcr.io/nginx/charts/nginx-gateway-fabric:1.6.1
 Digest: sha256:9bbd1a2fcbfd5407ad6be39f796f582e6263512f1f3a8969b427d39063cc6fee
 NAME: ngf
 LAST DEPLOYED: Mon Oct 21 14:45:14 2024
@@ -159,7 +159,7 @@ metadata:
   labels:
     app.kubernetes.io/name: nginx-gateway-fabric
     app.kubernetes.io/instance: ngf
-    app.kubernetes.io/version: "1.5.1"
+    app.kubernetes.io/version: "1.6.1"
 spec:
   type: NodePort
   selector:

content/ngf/how-to/monitoring/prometheus.md

@@ -83,7 +83,7 @@ NGINX Gateway Fabric provides a variety of metrics for monitoring and analyzing
 
 ### NGINX/NGINX Plus metrics
 
-NGINX metrics cover specific NGINX operations such as the total number of accepted client connections. For a complete list of available NGINX/NGINX Plus metrics, refer to the [NGINX Prometheus Exporter developer docs](https://github.com/nginxinc/nginx-prometheus-exporter#exported-metrics).
+NGINX metrics cover specific NGINX operations such as the total number of accepted client connections. For a complete list of available NGINX/NGINX Plus metrics, refer to the [NGINX Prometheus Exporter developer docs](https://github.com/nginx/nginx-prometheus-exporter#exported-metrics).
 
 These metrics use the `nginx_gateway_fabric` namespace and include the `class` label, indicating the NGINX Gateway class. For example, `nginx_gateway_fabric_connections_accepted{class="nginx"}`.
 
@@ -119,13 +119,13 @@ You can configure monitoring metrics for NGINX Gateway Fabric using Helm or Mani
 
 ### Using Helm
 
-If you're setting up NGINX Gateway Fabric with Helm, you can adjust the `metrics.*` parameters to fit your needs. For detailed options and instructions, see the [Helm README](https://github.com/nginx/nginx-gateway-fabric/blob/v1.5.1/charts/nginx-gateway-fabric/README.md).
+If you're setting up NGINX Gateway Fabric with Helm, you can adjust the `metrics.*` parameters to fit your needs. For detailed options and instructions, see the [Helm README](https://github.com/nginx/nginx-gateway-fabric/blob/v1.6.1/charts/nginx-gateway-fabric/README.md).
 
 ---
 
 ### Using Kubernetes manifests
 
-For setups using Kubernetes manifests, change the metrics configuration by editing the NGINX Gateway Fabric manifest that you want to deploy. You can find some examples in the [deploy](https://github.com/nginx/nginx-gateway-fabric/tree/v1.5.1/deploy) directory.
+For setups using Kubernetes manifests, change the metrics configuration by editing the NGINX Gateway Fabric manifest that you want to deploy. You can find some examples in the [deploy](https://github.com/nginx/nginx-gateway-fabric/tree/v1.6.1/deploy) directory.
 
 ---
 

content/ngf/how-to/monitoring/tracing.md

@@ -15,7 +15,7 @@ This guide explains how to enable tracing on HTTPRoutes in NGINX Gateway Fabric
 
 NGINX Gateway Fabric supports tracing using [OpenTelemetry](https://opentelemetry.io/).
 
-The official [NGINX OpenTelemetry Module](https://github.com/nginxinc/nginx-otel) instruments the NGINX data plane to export traces to a configured collector. Tracing data can be used with an OpenTelemetry Protocol (OTLP) exporter, such as the [OpenTelemetry Collector](https://github.com/open-telemetry/opentelemetry-collector). 
+The official [NGINX OpenTelemetry Module](https://github.com/nginxinc/nginx-otel) instruments the NGINX data plane to export traces to a configured collector. Tracing data can be used with an OpenTelemetry Protocol (OTLP) exporter, such as the [OpenTelemetry Collector](https://github.com/open-telemetry/opentelemetry-collector).
 
 This collector can then export data to one or more upstream collectors like [Jaeger](https://www.jaegertracing.io/), [DataDog](https://docs.datadoghq.com/tracing/), and many others. This is called the [Agent model](https://opentelemetry.io/docs/collector/deployment/agent/).
 
@@ -64,8 +64,6 @@ kubectl port-forward -n tracing svc/jaeger 16686:16686 &
 
 Visit [http://127.0.0.1:16686](http://127.0.0.1:16686) to view the dashboard.
 
----
-
 ## Enable tracing
 
 To enable tracing, you must configure two resources:
@@ -104,7 +102,7 @@ The span attribute will be added to all tracing spans.
 To install:
 
 ```shell
-helm install ngf oci://ghcr.io/nginxinc/charts/nginx-gateway-fabric --create-namespace -n nginx-gateway -f values.yaml
+helm install ngf oci://ghcr.io/nginx/charts/nginx-gateway-fabric --create-namespace -n nginx-gateway -f values.yaml
 ```
 
 You should see the following configuration:
@@ -179,8 +177,6 @@ Save the public IP address and port of NGINX Gateway Fabric into shell variables
 
 You can now create the application, route, and tracing policy.
 
----
-
 ### Create the application and route
 
 Create the basic **coffee** application:
@@ -283,7 +279,7 @@ To enable tracing for the coffee HTTPRoute, create the following policy:
 
 ```yaml
 kubectl apply -f - <<EOF
-apiVersion: gateway.nginx.org/v1alpha1
+apiVersion: gateway.nginx.org/v1alpha2
 kind: ObservabilityPolicy
 metadata:
   name: coffee

content/ngf/how-to/traffic-management/advanced-routing.md

@@ -45,7 +45,7 @@ The goal is to create a set of rules that will result in client requests being s
 Begin by deploying the `coffee-v1` and `coffee-v2` applications:
 
 ```shell
-kubectl apply -f https://raw.githubusercontent.com/nginx/nginx-gateway-fabric/v1.6.0/examples/advanced-routing/coffee.yaml
+kubectl apply -f https://raw.githubusercontent.com/nginx/nginx-gateway-fabric/v1.6.1/examples/advanced-routing/coffee.yaml
 ```
 
 ---
@@ -173,7 +173,7 @@ Let's deploy a different set of applications now called `tea` and `tea-post`. Th
 ### Deploy the Tea applications
 
 ```shell
-kubectl apply -f https://raw.githubusercontent.com/nginx/nginx-gateway-fabric/v1.6.0/examples/advanced-routing/tea.yaml
+kubectl apply -f https://raw.githubusercontent.com/nginx/nginx-gateway-fabric/v1.6.1/examples/advanced-routing/tea.yaml
 ```
 
 ---

content/ngf/how-to/traffic-management/client-settings.md

@@ -51,19 +51,19 @@ For all the possible configuration options for `ClientSettingsPolicy`, see the [
 - Create the coffee and tea example applications:
 
   ```yaml
-  kubectl apply -f https://raw.githubusercontent.com/nginx/nginx-gateway-fabric/v1.5.1/examples/client-settings-policy/app.yaml
+  kubectl apply -f https://raw.githubusercontent.com/nginx/nginx-gateway-fabric/v1.6.1/examples/client-settings-policy/app.yaml
   ```
 
 - Create a Gateway:
 
   ```yaml
-  kubectl apply -f https://raw.githubusercontent.com/nginx/nginx-gateway-fabric/v1.5.1/examples/client-settings-policy/gateway.yaml
+  kubectl apply -f https://raw.githubusercontent.com/nginx/nginx-gateway-fabric/v1.6.1/examples/client-settings-policy/gateway.yaml
    ```
 
 - Create HTTPRoutes for the coffee and tea applications:
 
   ```yaml
-  kubectl apply -f https://raw.githubusercontent.com/nginx/nginx-gateway-fabric/v1.5.1/examples/client-settings-policy/httproutes.yaml
+  kubectl apply -f https://raw.githubusercontent.com/nginx/nginx-gateway-fabric/v1.6.1/examples/client-settings-policy/httproutes.yaml
    ```
 
 - Test the configuration:

content/ngf/how-to/traffic-management/request-response-headers.md

@@ -67,7 +67,7 @@ This examples demonstrates how to configure traffic routing for a simple echo se
 Begin by deploying the example application `headers`. It is a simple application that returns the request headers which will be modified later.
 
 ```shell
-kubectl apply -f https://raw.githubusercontent.com/nginx/nginx-gateway-fabric/v1.6.0/examples/http-request-header-filter/headers.yaml
+kubectl apply -f https://raw.githubusercontent.com/nginx/nginx-gateway-fabric/v1.6.1/examples/http-request-header-filter/headers.yaml
 ```
 
 This will create the headers Service and a Deployment with one Pod. Run the following command to verify the resources were created:
@@ -179,7 +179,7 @@ kubectl delete httproutes.gateway.networking.k8s.io headers
 ```
 
 ```shell
-kubectl delete -f https://raw.githubusercontent.com/nginx/nginx-gateway-fabric/v1.6.0/examples/http-request-header-filter/headers.yaml
+kubectl delete -f https://raw.githubusercontent.com/nginx/nginx-gateway-fabric/v1.6.1/examples/http-request-header-filter/headers.yaml
 ```
 
 ---
@@ -195,7 +195,7 @@ Begin by configuring an application with custom headers and a simple HTTPRoute.
 Begin by deploying the example application `headers`. It is a simple application that adds response headers that will be modified later.
 
 ```shell
-kubectl apply -f https://raw.githubusercontent.com/nginx/nginx-gateway-fabric/v1.6.0/examples/http-response-header-filter/headers.yaml
+kubectl apply -f https://raw.githubusercontent.com/nginx/nginx-gateway-fabric/v1.6.1/examples/http-response-header-filter/headers.yaml
 ```
 
 This will create the headers Service and a Deployment with one Pod. Run the following command to verify the resources were created:

content/ngf/how-to/traffic-management/snippets.md

@@ -75,19 +75,19 @@ We have outlined a few best practices to keep in mind when using `SnippetsFilter
 - Create the coffee and tea example applications:
 
   ```yaml
-  kubectl apply -f https://raw.githubusercontent.com/nginx/nginx-gateway-fabric/v1.5.1/examples/snippets-filter/app.yaml
+  kubectl apply -f https://raw.githubusercontent.com/nginx/nginx-gateway-fabric/v1.6.1/examples/snippets-filter/app.yaml
   ```
 
 - Create a Gateway:
 
   ```yaml
-  kubectl apply -f https://raw.githubusercontent.com/nginx/nginx-gateway-fabric/v1.5.1/examples/snippets-filter/gateway.yaml
+  kubectl apply -f https://raw.githubusercontent.com/nginx/nginx-gateway-fabric/v1.6.1/examples/snippets-filter/gateway.yaml
    ```
 
 - Create HTTPRoutes for the coffee and tea applications:
 
   ```yaml
-  kubectl apply -f https://raw.githubusercontent.com/nginx/nginx-gateway-fabric/v1.5.1/examples/snippets-filter/httproutes.yaml
+  kubectl apply -f https://raw.githubusercontent.com/nginx/nginx-gateway-fabric/v1.6.1/examples/snippets-filter/httproutes.yaml
    ```
 
 - Test the configuration:

content/ngf/how-to/traffic-management/upgrade-apps-without-downtime.md

@@ -0,0 +1,140 @@
+---
+title: "Upgrade applications without downtime"
+toc: true
+weight: 300
+type: how-to
+product: NGF
+docs: "DOCS-1420"
+---
+
+Learn how to use NGINX Gateway Fabric to upgrade applications without downtime.
+
+---
+
+## Overview
+
+{{< note >}} See the [Architecture document]({{< relref "/overview/gateway-architecture.md" >}}) to learn more about NGINX Gateway Fabric architecture.{{< /note >}}
+
+NGINX Gateway Fabric allows upgrading applications without downtime. To understand the upgrade methods, you need to be familiar with the NGINX features that help prevent application downtime: Graceful configuration reloads and upstream server updates.
+
+---
+
+### Graceful configuration reloads
+
+If a relevant gateway API or built-in Kubernetes resource is changed, NGINX Gateway Fabric will update NGINX by regenerating the NGINX configuration. NGINX Gateway Fabric then sends a reload signal to the master NGINX process to apply the new configuration.
+
+We call such an operation a "reload", during which client requests are not dropped - which defines it as a graceful reload.
+
+This process is further explained in the [NGINX configuration documentation](https://nginx.org/en/docs/control.html?#reconfiguration).
+
+---
+
+### Upstream server updates
+
+Endpoints frequently change during application upgrades: Kubernetes creates pods for the new version of an application and removes the old ones, creating and removing the respective endpoints as well.
+
+NGINX Gateway Fabric detects changes to endpoints by watching their corresponding [EndpointSlices](https://kubernetes.io/docs/concepts/services-networking/endpoint-slices/).
+
+In an NGINX configuration, a service is represented as an [upstream](https://nginx.org/en/docs/http/ngx_http_upstream_module.html#upstream), and an endpoint as an [upstream server](https://nginx.org/en/docs/http/ngx_http_upstream_module.html#server).
+
+Adding and removing endpoints are two of the most common cases:
+
+- If an endpoint is added, NGINX Gateway Fabric adds an upstream server to NGINX that corresponds to the endpoint, then reloads NGINX. Next, NGINX will start proxying traffic to that endpoint.
+- If an endpoint is removed, NGINX Gateway Fabric removes the corresponding upstream server from NGINX. After a reload, NGINX will stop proxying traffic to that server. However, it will finish proxying any pending requests to that server before switching to another endpoint.
+
+As long as you have more than one endpoint ready, clients won't experience downtime during upgrades.
+
+{{< note >}}It is good practice to configure a [Readiness probe](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/) in the deployment so that a pod can report when it is ready to receive traffic. Note that NGINX Gateway Fabric will not add any endpoint to NGINX that is not ready.{{< /note >}}
+
+---
+
+## Prerequisites
+
+- You have deployed your application as a [deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/)
+- The pods of the deployment belong to a [service](https://kubernetes.io/docs/concepts/services-networking/service/) so that Kubernetes creates an [endpoint](https://kubernetes.io/docs/reference/kubernetes-api/service-resources/endpoints-v1/) for each pod.
+- You have exposed the application to the clients via an [HTTPRoute](https://gateway-api.sigs.k8s.io/api-types/httproute/) resource that references that service.
+
+For example, an application can be exposed using a routing rule like below:
+
+```yaml
+- matches:
+  - path:
+      type: PathPrefix
+      value: /
+  backendRefs:
+  - name: my-app
+    port: 80
+```
+
+{{< note >}}See the [Cafe example](https://github.com/nginx/nginx-gateway-fabric/tree/v1.6.1/examples/cafe-example) for a basic example.{{< /note >}}
+
+The upgrade methods in the next sections cover:
+
+- Rolling deployment upgrades
+- Blue-green deployments
+- Canary releases
+
+---
+
+## Rolling deployment upgrade
+
+To start a [rolling deployment upgrade](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment), you update the deployment to use the new version tag of the application. As a result, Kubernetes terminates the pods with the old version and create new ones. By default, Kubernetes also ensures that some number of pods always stay available during the upgrade.
+
+This upgrade will add new upstream servers to NGINX and remove the old ones. As long as the number of pods (ready endpoints) during an upgrade does not reach zero, NGINX will be able to proxy traffic, and therefore prevent any downtime.
+
+This method does not require you to update the **HTTPRoute**.
+
+---
+
+## Blue-green deployments
+
+With this method, you deploy a new version of the application (blue version) as a separate deployment, while the old version (green) keeps running and handling client traffic. Next, you switch the traffic from the green version to the blue. If the blue works as expected, you terminate the green. Otherwise, you switch the traffic back to the green.
+
+There are two ways to switch the traffic:
+
+- Update the service selector to select the pods of the blue version instead of the green. As a result, NGINX Gateway Fabric removes the green upstream servers from NGINX and adds the blue ones. With this approach, it is not necessary to update the **HTTPRoute**.
+- Create a separate service for the blue version and update the backend reference in the **HTTPRoute** to reference this service, which leads to the same result as with the previous option.
+
+---
+
+## Canary releases
+
+Canary releases involve gradually introducing a new version of your application to a subset of nodes in a controlled manner, splitting the traffic between the old are new (canary) release. This allows for monitoring and testing the new release's performance and reliability before full deployment, helping to identify and address issues without impacting the entire user base.
+
+To support canary releases, you can implement an approach with two deployments behind the same service (see [Canary deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#canary-deployment) in the Kubernetes documentation). However, this approach lacks precision for defining the traffic split between the old and the canary version. You can greatly influence it by controlling the number of pods (for example, four pods of the old version and one pod of the canary). However, note that NGINX Gateway Fabric uses [`random two least_conn`](https://nginx.org/en/docs/http/ngx_http_upstream_module.html#random) load balancing method, which doesn't guarantee an exact split based on the number of pods (80/20 in the given example).
+
+A more flexible and precise way to implement canary releases is to configure a traffic split in an **HTTPRoute**. In this case, you create a separate deployment for the new version with a separate service. For example, for the rule below, NGINX will proxy 95% of the traffic to the old version endpoints and only 5% to the new ones.
+
+```yaml
+- matches:
+  - path:
+      type: PathPrefix
+      value: /
+  backendRefs:
+  - name: my-app-old
+    port: 80
+    weight: 95
+  - name: my-app-new
+    port: 80
+    weight: 5
+```
+
+{{< note >}}Every request coming from the same client won't necessarily be sent to the same backend. NGINX will independently split each request among the backend references.{{< /note >}}
+
+By updating the rule you can further increase the share of traffic the new version gets and finally completely switch to the new version:
+
+```yaml
+- matches:
+  - path:
+      type: PathPrefix
+      value: /
+  backendRefs:
+  - name: my-app-old
+    port: 80
+    weight: 0
+  - name: my-app-new
+    port: 80
+    weight: 1
+```
+
+See the [Traffic splitting example](https://github.com/nginx/nginx-gateway-fabric/tree/v1.6.1/examples/traffic-splitting) from our repository.