Release NGF 1.6.1 (#172)

Author: lucacome

content/ngf/get-started.md

@@ -36,14 +36,14 @@ Create the file _cluster-config.yaml_ with the following contents, noting the hi
 apiVersion: kind.x-k8s.io/v1alpha4
 kind: Cluster
 nodes:
-- role: control-plane
-  extraPortMappings:
-  - containerPort: 31437
-    hostPort: 8080
-    protocol: TCP
-  - containerPort: 31438
-    hostPort: 8443
-    protocol: TCP
+  - role: control-plane
+    extraPortMappings:
+      - containerPort: 31437
+        hostPort: 8080
+        protocol: TCP
+      - containerPort: 31438
+        hostPort: 8443
+        protocol: TCP
 ```
 
 {{< warning >}}
@@ -73,7 +73,7 @@ Thanks for using kind! 😊
 ```
 
 {{< note >}}
-If you have cloned [the NGINX Gateway Fabric repository](https://github.com/nginx/nginx-gateway-fabric/tree/main), you can also create a kind cluster from the root folder with the following *make* command:
+If you have cloned [the NGINX Gateway Fabric repository](https://github.com/nginx/nginx-gateway-fabric/tree/main), you can also create a kind cluster from the root folder with the following _make_ command:
 
 ```shell
 make create-kind-cluster
@@ -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,23 +159,23 @@ 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:
     app.kubernetes.io/name: nginx-gateway-fabric
     app.kubernetes.io/instance: ngf
   ports:
-  - name: http
-    port: 80
-    protocol: TCP
-    targetPort: 80
-    nodePort: 31437
-  - name: https
-    port: 443
-    protocol: TCP
-    targetPort: 443
-    nodePort: 31438
+    - name: http
+      port: 80
+      protocol: TCP
+      targetPort: 80
+      nodePort: 31437
+    - name: https
+      port: 443
+      protocol: TCP
+      targetPort: 443
+      nodePort: 31438
 ```
 
 Apply it using `kubectl`:

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.
 
 ---
 
@@ -136,18 +136,18 @@ If you need to disable metrics:
 1. Set the `-metrics-disable` [command-line argument]({{< ref "/ngf/reference/cli-help.md">}}) to `true` in the NGINX Gateway Fabric Pod's configuration. Remove any other `-metrics-*` arguments.
 2. In the Pod template for NGINX Gateway Fabric, delete the metrics port entry from the container ports list:
 
-    ```yaml
-    - name: metrics
-      containerPort: 9113
-    ```
+   ```yaml
+   - name: metrics
+     containerPort: 9113
+   ```
 
 3. Also, remove the following annotations from the NGINX Gateway Fabric Pod template:
 
-    ```yaml
-    annotations:
-        prometheus.io/scrape: "true"
-        prometheus.io/port: "9113"
-    ```
+   ```yaml
+   annotations:
+     prometheus.io/scrape: "true"
+     prometheus.io/port: "9113"
+   ```
 
 #### Changing the default port
 
@@ -156,19 +156,19 @@ To change the default port for metrics:
 1. Update the `-metrics-port` [command-line argument]({{< ref "/ngf/reference/cli-help.md">}}) in the NGINX Gateway Fabric Pod's configuration to your chosen port number.
 2. In the Pod template, change the metrics port entry to reflect the new port:
 
-    ```yaml
-    - name: metrics
-      containerPort: <new-port>
-    ```
+   ```yaml
+   - name: metrics
+     containerPort: <new-port>
+   ```
 
 3. Modify the `prometheus.io/port` annotation in the Pod template to match the new port:
 
-    ```yaml
-    annotations:
-        <...>
-        prometheus.io/port: "<new-port>"
-        <...>
-    ```
+   ```yaml
+   annotations:
+       <...>
+       prometheus.io/port: "<new-port>"
+       <...>
+   ```
 
 ---
 
@@ -180,9 +180,9 @@ For enhanced security with HTTPS:
 
 2. Add an HTTPS scheme annotation to the Pod template:
 
-    ```yaml
-    annotations:
-        <...>
-        prometheus.io/scheme: "https"
-        <...>
-    ```
+   ```yaml
+   annotations:
+       <...>
+       prometheus.io/scheme: "https"
+       <...>
+   ```

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/).
 
@@ -104,7 +104,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:
@@ -123,8 +123,8 @@ spec:
     exporter:
       endpoint: otel-collector.tracing.svc:4317
     spanAttributes:
-    - key: cluster-attribute-key
-      value: cluster-attribute-value
+      - key: cluster-attribute-key
+        value: cluster-attribute-value
 ```
 
 ```shell
@@ -144,24 +144,24 @@ spec:
     name: ngf-proxy-config
 status:
   conditions:
-  - lastTransitionTime: "2024-05-22T15:18:35Z"
-    message: GatewayClass is accepted
-    observedGeneration: 1
-    reason: Accepted
-    status: "True"
-    type: Accepted
-  - lastTransitionTime: "2024-05-22T15:18:35Z"
-    message: Gateway API CRD versions are supported
-    observedGeneration: 1
-    reason: SupportedVersion
-    status: "True"
-    type: SupportedVersion
-  - lastTransitionTime: "2024-05-22T15:18:35Z"
-    message: parametersRef resource is resolved
-    observedGeneration: 1
-    reason: ResolvedRefs
-    status: "True"
-    type: ResolvedRefs
+    - lastTransitionTime: "2024-05-22T15:18:35Z"
+      message: GatewayClass is accepted
+      observedGeneration: 1
+      reason: Accepted
+      status: "True"
+      type: Accepted
+    - lastTransitionTime: "2024-05-22T15:18:35Z"
+      message: Gateway API CRD versions are supported
+      observedGeneration: 1
+      reason: SupportedVersion
+      status: "True"
+      type: SupportedVersion
+    - lastTransitionTime: "2024-05-22T15:18:35Z"
+      message: parametersRef resource is resolved
+      observedGeneration: 1
+      reason: ResolvedRefs
+      status: "True"
+      type: ResolvedRefs
 ```
 
 If you already have NGINX Gateway Fabric installed, then you can create the `NginxProxy` resource and link it to the GatewayClass `parametersRef`:
@@ -172,10 +172,10 @@ kubectl edit gatewayclasses.gateway.networking.k8s.io nginx
 
 Save the public IP address and port of NGINX Gateway Fabric into shell variables:
 
-   ```text
-   GW_IP=XXX.YYY.ZZZ.III
-   GW_PORT=<port number>
-   ```
+```text
+GW_IP=XXX.YYY.ZZZ.III
+GW_PORT=<port number>
+```
 
 You can now create the application, route, and tracing policy.
 
@@ -283,7 +283,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

@@ -21,18 +21,17 @@ The following image shows the traffic flow that we will be creating with these r
 
 The goal is to create a set of rules that will result in client requests being sent to specific backends based on the request attributes. In this diagram, we have two versions of the `coffee` service. Traffic for v1 needs to be directed to the old application, while traffic for v2 needs to be directed towards the new application. We also have two `tea` services, one that handles GET operations and one that handles POST operations. Both the `tea` and `coffee` applications share the same Gateway.
 
-
 ---
 
 ## Before you begin
 
 - [Install]({{< ref "/ngf/installation/" >}}) NGINX Gateway Fabric.
 - Save the public IP address and port of NGINX Gateway Fabric into shell variables:
 
-   ```text
-   GW_IP=XXX.YYY.ZZZ.III
-   GW_PORT=<port number>
-   ```
+  ```text
+  GW_IP=XXX.YYY.ZZZ.III
+  GW_PORT=<port number>
+  ```
 
 {{< note >}} In a production environment, you should have a DNS record for the external IP address that is exposed, and it should refer to the hostname that the gateway will forward for. {{< /note >}}
 
@@ -45,7 +44,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
 ```
 
 ---
@@ -117,7 +116,7 @@ This HTTPRoute has a few important properties:
 - The `parentRefs` references the gateway resource that we created, and specifically defines the `http` listener to attach to, via the `sectionName` field.
 - `cafe.example.com` is the hostname that is matched for all requests to the backends defined in this HTTPRoute.
 - The first rule defines that all requests with the path prefix `/coffee` and no other matching conditions are sent to the `coffee-v1` Service.
-- The second rule defines two matching conditions. If *either* of these conditions match, requests are forwarded to the `coffee-v2` Service:
+- The second rule defines two matching conditions. If _either_ of these conditions match, requests are forwarded to the `coffee-v2` Service:
 
   - Request with the path prefix `/coffee` and header `version=v2`
   - Request with the path prefix `/coffee` and the query parameter `TEST=v2`
@@ -173,7 +172,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

@@ -17,11 +17,11 @@ The `ClientSettingsPolicy` API allows Cluster Operators and Application Develope
 
 The settings in `ClientSettingsPolicy` correspond to the following NGINX directives:
 
-- [`client_max_body_size`](<https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size>)
-- [`client_body_timeout`](<https://nginx.org/en/docs/http/ngx_http_core_module.html#client_body_timeout>)
-- [`keepalive_requests`](<https://nginx.org/en/docs/http/ngx_http_core_module.html#keepalive_requests>)
-- [`keepalive_time`](<https://nginx.org/en/docs/http/ngx_http_core_module.html#keepalive_time>)
-- [`keepalive_timeout`](<https://nginx.org/en/docs/http/ngx_http_core_module.html#keepalive_timeout>)
+- [`client_max_body_size`](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size)
+- [`client_body_timeout`](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_body_timeout)
+- [`keepalive_requests`](https://nginx.org/en/docs/http/ngx_http_core_module.html#keepalive_requests)
+- [`keepalive_time`](https://nginx.org/en/docs/http/ngx_http_core_module.html#keepalive_time)
+- [`keepalive_timeout`](https://nginx.org/en/docs/http/ngx_http_core_module.html#keepalive_timeout)
 
 `ClientSettingsPolicy` is an [Inherited PolicyAttachment](https://gateway-api.sigs.k8s.io/reference/policy-attachment/) that can be applied to a Gateway, HTTPRoute, or GRPCRoute in the same namespace as the `ClientSettingsPolicy`.
 
@@ -41,7 +41,7 @@ For all the possible configuration options for `ClientSettingsPolicy`, see the [
 - [Install]({{< ref "/ngf/installation/" >}}) NGINX Gateway Fabric.
 - Save the public IP address and port of NGINX Gateway Fabric into shell variables:
 
-   ```text
+  ```text
   GW_IP=XXX.YYY.ZZZ.III
   GW_PORT=<port number>
   ```
@@ -51,20 +51,20 @@ 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:
 
@@ -87,7 +87,7 @@ For all the possible configuration options for `ClientSettingsPolicy`, see the [
 
   ```shell
   curl --resolve cafe.example.com:$GW_PORT:$GW_IP http://cafe.example.com:$GW_PORT/tea
-   ```
+  ```
 
   This request should receive a response from the tea Pod: