Merge branch 'nginx:main' into main

Author: yluf5

content/ngf/changelog.md

@@ -4,7 +4,7 @@ toc: true
 weight: 900
 nd-content-type: reference
 nd-product: NGF
-nd-docs: "DOCS-1359"
+nd-docs: DOCS-1359
 ---
 
 See the NGINX Gateway Fabric changelog page:

content/ngf/get-started.md

@@ -4,11 +4,11 @@ weight: 200
 toc: true
 nd-content-type: how-to
 nd-product: NGF
-nd-docs: DOCS-000
+nd-docs: DOCS-1834
 ---
 
 {{< important >}}
-This document is for trying out NGINX Gateway Fabric, and not intended for a production environment. 
+This document is for trying out NGINX Gateway Fabric, and not intended for a production environment.
 
 For standard deployments, you should read the [Install NGINX Gateway Fabric]({{< ref "/ngf/install/" >}}) section.
 {{< /important >}}
@@ -102,7 +102,7 @@ customresourcedefinition.apiextensions.k8s.io/referencegrants.gateway.networking
 
 ### Install the Helm chart
 
-Use `helm` to install NGINX Gateway Fabric, specifying the NodePort configuration that will be set on the 
+Use `helm` to install NGINX Gateway Fabric, specifying the NodePort configuration that will be set on the
 NGINX Service when it is provisioned:
 
 ```shell

content/ngf/how-to/control-plane-configuration.md

@@ -4,7 +4,7 @@ weight: 400
 toc: true
 type: how-to
 product: NGF
-docs: DOCS-1416
+nd-docs: DOCS-1839
 ---
 
 Learn how to dynamically update the NGINX Gateway Fabric control plane configuration.

content/ngf/how-to/data-plane-configuration.md

@@ -4,7 +4,7 @@ weight: 500
 toc: true
 type: how-to
 product: NGF
-docs: DOCS-000
+nd-docs: DOCS-1838
 ---
 
 Learn how to dynamically update the NGINX Gateway Fabric global data plane configuration.
@@ -342,7 +342,7 @@ EOF
 
 ## Configure infrastructure-related settings
 
-You can configure deployment and service settings for all data plane instances by editing the `NginxProxy` resource at the Gateway or GatewayClass level. These settings can also be specified under the `nginx` section in the Helm values file. You can edit things such as replicas, pod scheduling options, container resource limits, extra volume mounts, service types and load balancer settings. 
+You can configure deployment and service settings for all data plane instances by editing the `NginxProxy` resource at the Gateway or GatewayClass level. These settings can also be specified under the `nginx` section in the Helm values file. You can edit things such as replicas, pod scheduling options, container resource limits, extra volume mounts, service types and load balancer settings.
 
 The following command creates an `NginxProxy` resource with 2 replicas, sets `container.resources.requests` to 100m CPU and 128Mi memory, configures a 90 second `pod.terminationGracePeriodSeconds`, and sets the service type to `LoadBalancer` with IP `192.87.9.1` and AWS NLB annotation.
 

content/ngf/how-to/scaling.md

@@ -4,7 +4,7 @@ weight: 700
 toc: true
 type: how-to
 product: NGF
-docs: DOCS-0000
+nd-docs: DOCS-1840
 ---
 
 This document describes how you can separately scale the NGINX Gateway Fabric control plane and data plane.
@@ -14,7 +14,7 @@ It provides guidance on how to scale each plane effectively, and when you should
 
 ### Scaling the data plane
 
-The data plane is the NGINX deployment that handles user traffic to backend applications. Every Gateway object created provisions its own NGINX deployment and configuration. 
+The data plane is the NGINX deployment that handles user traffic to backend applications. Every Gateway object created provisions its own NGINX deployment and configuration.
 
 You have two options for scaling the data plane:
 
@@ -25,9 +25,9 @@ You have two options for scaling the data plane:
 
 Understanding when to increase replicas or create a new Gateway is key to managing traffic effectively.
 
-Increasing data plane replicas is ideal when you need to handle more traffic without changing the configuration. 
+Increasing data plane replicas is ideal when you need to handle more traffic without changing the configuration.
 
-For example, if you're routing traffic to `api.example.com` and notice an increase in load, you can scale the replicas from 1 to 5 to better distribute the traffic and reduce latency. 
+For example, if you're routing traffic to `api.example.com` and notice an increase in load, you can scale the replicas from 1 to 5 to better distribute the traffic and reduce latency.
 
 All replicas will share the same configuration from the Gateway used to set up the data plane, simplifying configuration management.
 
@@ -45,15 +45,15 @@ Secondly, you can update the `NginxProxy` resource while NGINX is running to mod
 kubectl edit nginxproxies.gateway.nginx.org ngf-proxy-config -n nginx-gateway
 ```
 
-The alternate way to scale the data plane is by creating a new Gateway.  This is beneficial when you need distinct configurations, isolation, or separate policies. 
+The alternate way to scale the data plane is by creating a new Gateway.  This is beneficial when you need distinct configurations, isolation, or separate policies.
 
-For example, if you're routing traffic to a new domain `admin.example.com` and require a different TLS certificate, stricter rate limits, or separate authentication policies, creating a new Gateway could be a good approach. 
+For example, if you're routing traffic to a new domain `admin.example.com` and require a different TLS certificate, stricter rate limits, or separate authentication policies, creating a new Gateway could be a good approach.
 
 It allows for safe experimentation with isolated configurations and makes it easier to enforce security boundaries and specific routing rules.
 
 ### Scaling the control plane
 
-The control plane builds configuration based on defined Gateway API resources and sends that configuration to the NGINX data planes. With leader election enabled by default, the control plane can be scaled horizontally by running multiple replicas, although only the pod with leader lease can actively manage configuration status updates. 
+The control plane builds configuration based on defined Gateway API resources and sends that configuration to the NGINX data planes. With leader election enabled by default, the control plane can be scaled horizontally by running multiple replicas, although only the pod with leader lease can actively manage configuration status updates.
 
 Scaling the control plane can be beneficial in the following scenarios:
 
@@ -70,11 +70,11 @@ To scale the control plane, use the `kubectl scale` command on the control plane
 
 When scaling the control plane, it's important to understand how status updates are handled for Gateway API resources.
 
-All control plane pods can send NGINX configuration to the data planes. However, only the leader control plane pod is allowed to write status updates to Gateway API resources. 
+All control plane pods can send NGINX configuration to the data planes. However, only the leader control plane pod is allowed to write status updates to Gateway API resources.
 
-If an NGINX instance connects to a non-leader pod, and an error occurs when applying the config, that error status will not be written to the Gateway object status. 
+If an NGINX instance connects to a non-leader pod, and an error occurs when applying the config, that error status will not be written to the Gateway object status.
 
-To mitigate the potential for this issue, ensure that the number of NGINX data plane pods equals or exceeds the number of control plane pods. 
+To mitigate the potential for this issue, ensure that the number of NGINX data plane pods equals or exceeds the number of control plane pods.
 
 This increases the likelihood that at least one of the data planes is connected to the leader control plane pod. If an applied configuration has an error, the leader pod will be aware of it and status can still be written.
 

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

@@ -4,7 +4,7 @@ weight: 600
 toc: true
 type: how-to
 product: NGF
-docs: DOCS-1420
+nd-docs: DOCS-1841
 ---
 
 Learn how to use NGINX Gateway Fabric to upgrade applications without downtime.

content/ngf/install/deploy-data-plane.md

@@ -4,7 +4,7 @@ weight: 600
 toc: true
 nd-content-type: how-to
 nd-product: NGF
-nd-docs: DOCS-000
+nd-docs: DOCS-1854
 ---
 
 ## Overview
@@ -104,13 +104,13 @@ The NginxProxy custom resource can modify the provisioning of the Service object
 
 {{< note >}} Updating most Kubernetes related fields in NginxProxy will trigger a restart of the related resources. {{< /note >}}
 
-An NginxProxy resource is created by default after deploying NGINX Gateway Fabric. This NginxProxy resource is attached to the GatewayClass (created on NGINX Gateway Fabric installation), and 
+An NginxProxy resource is created by default after deploying NGINX Gateway Fabric. This NginxProxy resource is attached to the GatewayClass (created on NGINX Gateway Fabric installation), and
 its settings are applied globally to all Gateways.
 
 Use `kubectl get` and `kubectl describe` to get some more information on the resource:
 
 ```shell
-kubectl get nginxproxies -A   
+kubectl get nginxproxies -A
 ```
 ```text
 NAMESPACE       NAME                      AGE
@@ -159,7 +159,7 @@ Under `Spec.Kubernetes` you can see a few things:
 - How many NGINX Deployment replicas are specified
 - The type of Service and external traffic policy
 
-{{< note >}} Depending on installation configuration, the default NginxProxy settings may be slightly different from what is shown in the example. 
+{{< note >}} Depending on installation configuration, the default NginxProxy settings may be slightly different from what is shown in the example.
 For more information on NginxProxy and its configurable fields, see the [API reference]({{< ref "/ngf/reference/api.md" >}}). {{< /note >}}
 
 Modify the NginxProxy resource to change the type of Service.
@@ -173,7 +173,7 @@ type: NodePort
 After saving the changes, use `kubectl get` on the service, and you should see the service type has changed to `LoadBalancer`.
 
 ```shell
-kubectl get service cafe-nginx      
+kubectl get service cafe-nginx
 ```
 ```text
 NAME         TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
@@ -184,7 +184,7 @@ cafe-nginx   NodePort       10.96.172.204   <none>        80:32615/TCP   3h5m
 
 While the majority of configuration will happen on the NginxProxy resource, that is not always the case. Uniquely, if
 you want to set any annotations or labels on the NGINX Deployment or Service, you need to set those annotations on the Gateway which
-provisioned them. 
+provisioned them.
 
 You can use `kubectl edit` on the Gateway and add the following to the `spec`:
 

content/ngf/install/nginx-plus.md

@@ -4,7 +4,7 @@ weight: 300
 toc: true
 nd-content-type: how-to
 nd-product: NGF
-nd-docs: DOCS-000
+nd-docs: DOCS-1853
 ---
 
 ## Overview

content/ngf/install/secure-certificates.md

@@ -4,13 +4,14 @@ weight: 100
 toc: true
 nd-content-type: how-to
 nd-product: NGF
+nd-docs: DOCS-1851
 ---
 
-By default, NGINX Gateway Fabric installs self-signed certificates to secure the connection between the NGINX Gateway Fabric control plane and the NGINX data plane pods. These certificates are created by a `cert-generator` job when NGINX Gateway Fabric is first installed. 
+By default, NGINX Gateway Fabric installs self-signed certificates to secure the connection between the NGINX Gateway Fabric control plane and the NGINX data plane pods. These certificates are created by a `cert-generator` job when NGINX Gateway Fabric is first installed.
 
 However, because these certificates are self-signed and will expire after 3 years, we recommend a solution such as [cert-manager](https://cert-manager.io) to create and manage these certificates in a production environment.
 
-This guide will step through how to install and use `cert-manager` to secure this connection. 
+This guide will step through how to install and use `cert-manager` to secure this connection.
 
 {{< caution >}}
 
@@ -179,7 +180,7 @@ Specify the Secret name using the `certGenerator.agentTLSSecretName` helm value.
 
 {{%tab name="Manifests"%}}
 
-Specify the Secret name using the `agent-tls-secret` command-line argument. 
+Specify the Secret name using the `agent-tls-secret` command-line argument.
 
 {{% /tab %}}
 

content/ngf/install/upgrade-version.md

@@ -4,18 +4,18 @@ weight: 700
 toc: true
 type: how-to
 product: NGF
-docs: DOCS-0000
+nd-docs: DOCS-1852
 ---
 
-This document describes how to upgrade NGINX Gateway Fabric when a new version releases. 
+This document describes how to upgrade NGINX Gateway Fabric when a new version releases.
 
 It covers the necessary steps for minor versions as well as major versions (such as 1.x to 2.x).
 
 Many of the nuances in upgrade paths relate to how custom resource definitions (CRDs) are managed.
 
-{{< tip >}} 
+{{< tip >}}
 
-To avoid interruptions, review the [Delay pod termination for zero downtime upgrades](#configure-delayed-pod-termination-for-zero-downtime-upgrades) section. 
+To avoid interruptions, review the [Delay pod termination for zero downtime upgrades](#configure-delayed-pod-termination-for-zero-downtime-upgrades) section.
 
 {{< /tip >}}
 
@@ -24,7 +24,7 @@ To avoid interruptions, review the [Delay pod termination for zero downtime upgr
 
 {{< important >}} NGINX Plus users need a JWT secret before upgrading from version 1.4.0 to 1.5.x.
 
-Follow the steps in [Set up the JWT]({{< ref "/ngf/install/nginx-plus.md#set-up-the-jwt" >}}) to create the Secret. 
+Follow the steps in [Set up the JWT]({{< ref "/ngf/install/nginx-plus.md#set-up-the-jwt" >}}) to create the Secret.
 
 {{< /important >}}
 
@@ -33,7 +33,7 @@ Follow the steps in [Set up the JWT]({{< ref "/ngf/install/nginx-plus.md#set-up-
 
 To upgrade your Gateway API resources, take the following steps:
 
-- Use [Technical specifications]({{< ref "/ngf/reference/technical-specifications.md" >}}) to verify your Gateway API resources are compatible with your NGINX Gateway Fabric version. 
+- Use [Technical specifications]({{< ref "/ngf/reference/technical-specifications.md" >}}) to verify your Gateway API resources are compatible with your NGINX Gateway Fabric version.
 - Review the [release notes](https://github.com/kubernetes-sigs/gateway-api/releases) for any important upgrade-specific information.
 
 To upgrade the Gateway API resources, run the following command:
@@ -56,7 +56,7 @@ Run the following command to upgrade the CRDs:
 kubectl apply -f https://raw.githubusercontent.com/nginx/nginx-gateway-fabric/v{{< version-ngf >}}/deploy/crds.yaml
 ```
 
-{{< note >}} 
+{{< note >}}
 
 Ignore the following warning, as it is expected.
 
@@ -119,7 +119,7 @@ To remove the previous version 1.x of NGINX Gateway Fabric, follow these steps:
 First, run the following command to uninstall NGINX Gateway Fabric from the `nginx-gateway` namespace, and update `ngf` to your release name if it is different:
 
 ```shell
-helm uninstall ngf -n nginx-gateway 
+helm uninstall ngf -n nginx-gateway
 ```
 
 Afterwards, remove CRDs associated with NGINX Gateway Fabric version 1.x with the following command:
@@ -240,7 +240,7 @@ You can then follow [this localhost link](http://localhost:1313/nginx-gateway-fa
 
 ## Upgrade from NGINX Open Source to NGINX Plus
 
-{{< important >}} 
+{{< important >}}
 
 Ensure that you [Set up the JWT]({{< ref "/ngf/install/nginx-plus.md#set-up-the-jwt" >}}) before upgrading. These instructions only apply to Helm.