diff --git a/content/ngf/how-to/data-plane-configuration.md b/content/ngf/how-to/data-plane-configuration.md index 4285528bd..a18725ce5 100644 --- a/content/ngf/how-to/data-plane-configuration.md +++ b/content/ngf/how-to/data-plane-configuration.md @@ -375,3 +375,128 @@ To view the full list of configuration options, see the `NginxProxy spec` in the --- +### Patch data plane Service, Deployment, and DaemonSet + +NGINX Gateway Fabric supports advanced customization of the data plane Service, Deployment, and DaemonSet objects using patches in the `NginxProxy` resource. This allows you to apply Kubernetes-style patches to these resources, enabling custom labels, annotations, or other modifications that are not directly exposed via the NginxProxy spec. + +#### Supported Patch Types + +You can specify one or more patches for each of the following resources: + +- `spec.kubernetes.service.patches` +- `spec.kubernetes.deployment.patches` +- `spec.kubernetes.daemonSet.patches` + +Each patch has two fields: + +- `type`: The patch type. Supported values are: + - `StrategicMerge` (default): Strategic merge patch (Kubernetes default for most resources) + - `Merge`: JSON merge patch (RFC 7386) + - `JSONPatch`: JSON patch (RFC 6902) +- `value`: The patch data. For `StrategicMerge` and `Merge`, this should be a JSON object. For `JSONPatch`, this should be a JSON array of patch operations. + +Patches are applied in the order they appear in the array. Later patches can override fields set by earlier patches. + +#### Example: Configure Service with session affinity + +```yaml +apiVersion: gateway.nginx.org/v1alpha2 +kind: NginxProxy +metadata: + name: ngf-proxy-patch-service +spec: + kubernetes: + service: + patches: + - type: StrategicMerge + value: + spec: + sessionAffinity: ClientIP + sessionAffinityConfig: + clientIP: + timeoutSeconds: 300 +``` + +#### Example: Configure Deployment with custom strategy + +```yaml +apiVersion: gateway.nginx.org/v1alpha2 +kind: NginxProxy +metadata: + name: ngf-proxy-patch-deployment +spec: + kubernetes: + deployment: + patches: + - type: Merge + value: + spec: + strategy: + type: RollingUpdate + rollingUpdate: + maxUnavailable: 0 + maxSurge: 2 +``` + +#### Example: Use JSONPatch to configure DaemonSet host networking and priority + +```yaml +apiVersion: gateway.nginx.org/v1alpha2 +kind: NginxProxy +metadata: + name: ngf-proxy-patch-daemonset +spec: + kubernetes: + daemonSet: + patches: + - type: JSONPatch + value: + - op: add + path: /spec/template/spec/hostNetwork + value: true + - op: add + path: /spec/template/spec/dnsPolicy + value: "ClusterFirstWithHostNet" + - op: add + path: /spec/template/spec/priorityClassName + value: "system-node-critical" +``` + +#### Example: Multiple patches, later patch overrides earlier + +```yaml +apiVersion: gateway.nginx.org/v1alpha2 +kind: NginxProxy +metadata: + name: ngf-proxy-multi-patch +spec: + kubernetes: + service: + patches: + - type: StrategicMerge + value: + spec: + sessionAffinity: ClientIP + publishNotReadyAddresses: false + - type: StrategicMerge + value: + spec: + sessionAffinity: None + publishNotReadyAddresses: true +``` + +In this example, the final Service will have `sessionAffinity: None` and `publishNotReadyAddresses: true` because the second patch overrides the values from the first patch. + +{{< note >}} +**Which patch type should I use?** + +- **StrategicMerge** is the default and most user-friendly for Kubernetes-native resources like Deployments and Services. It understands lists and merges fields intelligently (e.g., merging containers by name). Use this for most use cases. +- **Merge** (JSON Merge Patch) is simpler and works well for basic object merges, but does not handle lists or complex merging. Use this if you want to replace entire fields or for non-Kubernetes-native resources. +- **JSONPatch** is the most powerful and flexible, allowing you to add, remove, or replace specific fields using RFC 6902 operations. Use this for advanced or fine-grained changes, but it is more verbose and error-prone. + +If unsure, start with StrategicMerge. Use JSONPatch only if you need to surgically modify fields that cannot be addressed by the other patch types. + +Patches are applied after all other NginxProxy configuration is rendered. Invalid patches will result in a validation error and will not be applied. +{{< /note >}} + +--- diff --git a/content/ngf/how-to/scaling.md b/content/ngf/how-to/scaling.md index 8e9961798..b316cf1d0 100644 --- a/content/ngf/how-to/scaling.md +++ b/content/ngf/how-to/scaling.md @@ -16,36 +16,64 @@ It provides guidance on how to scale each plane effectively, and when you should 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: +You have multiple options for scaling the data plane: +- Increasing the number of [worker connections](https://nginx.org/en/docs/ngx_core_module.html#worker_connections) for an existing deployment - Increasing the number of replicas for an existing deployment - Creating a new Gateway for a new data plane -#### When to increase replicas or create a new Gateway +#### When to increase worker connections, replicas, or create a new Gateway -Understanding when to increase replicas or create a new Gateway is key to managing traffic effectively. +Understanding when to increase worker connections, 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 worker connections or replicas is ideal when you need to handle more traffic without changing the overall routing configuration. Setting the worker connections field allows a single NGINX data plane instance to handle more connections without needing to scale the replicas. However, scaling the replicas can be beneficial to reduce single points of failure. -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. +Scaling replicas can be done manually or automatically using a [Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) (HPA). -All replicas will share the same configuration from the Gateway used to set up the data plane, simplifying configuration management. +To update worker connections (default: 1024), replicas, or enable autoscaling, you can edit the `NginxProxy` resource: -There are two ways to modify the number of replicas for an NGINX deployment: +```shell +kubectl edit nginxproxies.gateway.nginx.org ngf-proxy-config -n nginx-gateway +``` -First, at the time of installation you can modify the field `nginx.replicas` in the `values.yaml` or add the `--set nginx.replicas=` flag to the `helm install` command: +{{< call-out "note" >}} -```shell -helm install ngf oci://ghcr.io/nginx/charts/nginx-gateway-fabric --create-namespace -n nginx-gateway --set nginx.replicas=5 +The NginxProxy resource in this example lives in the control plane namespace (default: `nginx-gateway`) and applies to the GatewayClass, but you can also define one per Gateway. See the [Data plane configuration]({{< ref "/ngf/how-to/data-plane-configuration.md" >}}) document for more information. + +{{< /call-out >}} + +- Worker connections is set using the `workerConnections` field: + +```yaml +spec: + workerConnections: 4096 ``` -Secondly, you can update the `NginxProxy` resource while NGINX is running to modify the `kubernetes.deployment.replicas` field and scale the data plane deployment dynamically: +- Replicas are set using the `kubernetes.deployment.replicas` field: -```shell -kubectl edit nginxproxies.gateway.nginx.org ngf-proxy-config -n nginx-gateway +```yaml +spec: + kubernetes: + deployment: + replicas: 3 +``` + +- Autoscaling can be enabled using the `kubernetes.deployment.autoscaling` field. The default `replicas` value will be used until the Horizontal Pod Autoscaler is running. + +```yaml +spec: + kubernetes: + deployment: + autoscaling: + enable: true + maxReplicas: 10 ``` -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. +See the `NginxProxy` section of the [API reference]({{< ref "/ngf/reference/api.md" >}}) for the full specification. + +All of these fields are also available at installation time by setting them in the [helm values](https://github.com/nginx/nginx-gateway-fabric/blob/main/charts/nginx-gateway-fabric/values.yaml). + +An 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. @@ -60,7 +88,9 @@ Scaling the control plane can be beneficial in the following scenarios: 1. _Higher availability_ - When a control plane pod crashes, runs out of memory, or goes down during an upgrade, it can interrupt configuration delivery. By scaling to multiple replicas, another pod can quickly step in and take over, keeping things running smoothly with minimal downtime. 1. _Faster configuration distribution_ - As the number of connected NGINX instances grows, a single control plane pod may become a bottleneck in handling connections or streaming configuration updates. Scaling the control plane improves concurrency and responsiveness when delivering configuration over gRPC. -To scale the control plane, use the `kubectl scale` command on the control plane deployment to increase or decrease the number of replicas. For example, the following command scales the control plane deployment to 3 replicas: +To automatically scale the control plane, you can create a [Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) (HPA) in the control plane namespace (default: `nginx-gateway`). At installation time, the [NGINX Gateway Fabric helm chart](https://github.com/nginx/nginx-gateway-fabric/blob/main/charts/nginx-gateway-fabric/values.yaml) allows you to set the HPA configuration in the `nginxGateway.autoscaling` section, which will provision an HPA for you. If NGINX Gateway Fabric is already running, then you can manually define the HPA and deploy it. + +To manually scale the control plane, use the `kubectl scale` command on the control plane deployment to increase or decrease the number of replicas. For example, the following command scales the control plane deployment to 3 replicas: ```shell kubectl scale deployment -n nginx-gateway ngf-nginx-gateway-fabric --replicas 3 diff --git a/content/ngf/install/upgrade-version.md b/content/ngf/install/upgrade-version.md index a415eb0c6..4d6e06f89 100644 --- a/content/ngf/install/upgrade-version.md +++ b/content/ngf/install/upgrade-version.md @@ -13,15 +13,13 @@ It covers the necessary steps for minor versions as well as major versions (such Many of the nuances in upgrade paths relate to how custom resource definitions (CRDs) are managed. -{{< call-out "tip" >}} -To avoid interruptions, review the [Delay pod termination for zero downtime upgrades](#configure-delayed-pod-termination-for-zero-downtime-upgrades) section. +## Minor NGINX Gateway Fabric upgrades +{{< call-out "important" >}} +Upgrading from v2.0.x to v2.1 requires the NGINX Gateway Fabric control plane to be uninstalled and then reinstalled to avoid any downtime to user traffic. CRDs do not need to be removed. The NGINX data plane deployment is not affected by this process, and traffic should still flow uninterrupted. The steps are described below. {{< /call-out >}} - -## Minor NGINX Gateway Fabric upgrades - {{< call-out "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. @@ -72,7 +70,7 @@ Warning: kubectl apply should be used on resource created by either kubectl crea {{% tab name="Helm" %}} -{{< call-out "important" >}} If you are using NGINX Plus and have a different Secret name than the default `nplus-license` name, specify the Secret name by setting `--set nginx.usage.secretName=` when running `helm upgrade`. {{< /call-out >}} +{{< call-out "important" >}} If you are using NGINX Plus and have a different Secret name than the default `nplus-license` name, specify the Secret name by setting `--set nginx.usage.secretName=` when running `helm install` or `helm upgrade`. {{< /call-out >}} To upgrade the release with Helm, you can use the OCI registry, or download the chart and upgrade from the source. @@ -80,6 +78,15 @@ If needed, replace `ngf` with your chosen release name. **Upgrade from the OCI registry** +To avoid downtime when upgrading from v2.0.x to v2.1, run the following commands. Be sure to include your previous installation flags and values if necessary. This will not affect user traffic, as the NGINX data plane deployment won't be removed as part of this process. + +```shell +helm uninstall ngf -n nginx-gateway +helm install ngf oci://ghcr.io/nginx/charts/nginx-gateway-fabric -n nginx-gateway +``` + +Otherwise, for all other version upgrades: + ```shell helm upgrade ngf oci://ghcr.io/nginx/charts/nginx-gateway-fabric -n nginx-gateway ``` @@ -88,7 +95,14 @@ helm upgrade ngf oci://ghcr.io/nginx/charts/nginx-gateway-fabric -n nginx-gatewa {{< include "/ngf/installation/helm/pulling-the-chart.md" >}} -To upgrade, run the following command: +To avoid downtime when upgrading from v2.0.x to v2.1, run the following. Be sure to include your previous installation flags and values if necessary. This will not affect user traffic, as the NGINX data plane deployment won't be removed as part of this process. + +```shell +helm uninstall ngf -n nginx-gateway +helm install ngf . -n nginx-gateway +``` + +Otherwise, for all other version upgrades: ```shell helm upgrade ngf . -n nginx-gateway @@ -98,7 +112,9 @@ helm upgrade ngf . -n nginx-gateway {{% tab name="Manifests" %}} -Select the deployment manifest that matches your current deployment from options available in the [Deploy NGINX Gateway Fabric]({{< ref "/ngf/install/manifests.md#deploy-nginx-gateway-fabric-1">}}) section and apply it. +Select the deployment manifest that matches your current deployment from options available in the [Deploy NGINX Gateway Fabric]({{< ref "/ngf/install/manifests.md#deploy-nginx-gateway-fabric-1">}}) section. + +To avoid downtime when upgrading from v2.0.x to v2.1, delete the previous NGINX Gateway Fabric control plane deployment in the `nginx-gateway` namespace, using `kubectl delete deployment`. Then `kubectl apply` the updated manifest file. This will not affect user traffic, as the NGINX data plane deployment won't be removed as part of this process. {{% /tab %}} @@ -259,50 +275,3 @@ To upgrade from NGINX Open Source to NGINX Plus, update the Helm command to incl ```shell helm upgrade ngf oci://ghcr.io/nginx/charts/nginx-gateway-fabric --set nginx.image.repository=private-registry.nginx.com/nginx-gateway-fabric/nginx-plus --set nginx.plus=true --set nginx.imagePullSecret=nginx-plus-registry-secret -n nginx-gateway ``` - -## Delay pod termination for zero downtime upgrades {#configure-delayed-pod-termination-for-zero-downtime-upgrades} - -{{< include "/ngf/installation/delay-pod-termination/delay-pod-termination-overview.md" >}} - -Follow these steps to configure delayed pod termination: - -1. Open the `values.yaml` for editing. - -1. **Add delayed shutdown hooks**: - - - In the `values.yaml` file, add `lifecycle: preStop` hooks to both the `nginx` and `nginx-gateway` container definitions. These hooks instruct the containers to delay their shutdown process, allowing time for connections to close gracefully. Update the `sleep` value to what works for your environment. - - ```yaml - nginxGateway: - <...> - lifecycle: - preStop: - exec: - command: - - /usr/bin/gateway - - sleep - - --duration=40s # This flag is optional, the default is 30s - - nginx: - <...> - lifecycle: - preStop: - exec: - command: - - /bin/sleep - - "40" - ``` - -1. **Set the termination grace period**: - - - {{< include "/ngf/installation/delay-pod-termination/termination-grace-period.md">}} - -1. Save the changes. - -{{< call-out "note" >}} -For additional information on configuring and understanding the behavior of containers and pods during their lifecycle, refer to the following Kubernetes documentation: - -- [Container Lifecycle Hooks](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks) -- [Pod Lifecycle](https://kubernetes.io/docs/concepts/workloads/Pods/Pod-lifecycle/#Pod-termination) - -{{< /call-out>}} \ No newline at end of file diff --git a/content/ngf/overview/gateway-api-compatibility.md b/content/ngf/overview/gateway-api-compatibility.md index d3e019006..0b77c3cc3 100644 --- a/content/ngf/overview/gateway-api-compatibility.md +++ b/content/ngf/overview/gateway-api-compatibility.md @@ -136,9 +136,11 @@ See the [controller]({{< ref "/ngf/reference/cli-help.md#controller">}}) command - `ResolvedRefs/True/ResolvedRefs` - `ResolvedRefs/False/InvalidCertificateRef` - `ResolvedRefs/False/InvalidRouteKinds` + - `ResolvedRefs/False/RefNotPermitted` - `Conflicted/True/ProtocolConflict` - `Conflicted/True/HostnameConflict` - `Conflicted/False/NoConflicts` + - `OverlappingTLSConfig/True/OverlappingHostnames` ### HTTPRoute @@ -167,7 +169,7 @@ See the [controller]({{< ref "/ngf/reference/cli-help.md#controller">}}) command - `requestHeaderModifier`: Supported. If multiple filters are configured, NGINX Gateway Fabric will choose the first and ignore the rest. - `urlRewrite`: Supported. If multiple filters are configured, NGINX Gateway Fabric will choose the first and ignore the rest. Incompatible with `requestRedirect`. - `responseHeaderModifier`: Supported. If multiple filters are configured, NGINX Gateway Fabric will choose the first and ignore the rest. - - `requestMirror`: Supported. Multiple mirrors can be specified. + - `requestMirror`: Supported. Multiple mirrors can be specified. Percent and fraction-based mirroring are supported. - `extensionRef`: Supported for SnippetsFilters. - `backendRefs`: Partially supported. Backend ref `filters` are not supported. - `status` @@ -189,6 +191,7 @@ See the [controller]({{< ref "/ngf/reference/cli-help.md#controller">}}) command - `ResolvedRefs/False/BackendNotFound` - `ResolvedRefs/False/UnsupportedValue`: Custom reason for when one of the HTTPRoute rules has a backendRef with an unsupported value. - `ResolvedRefs/False/InvalidIPFamily`: Custom reason for when one of the HTTPRoute rules has a backendRef that has an invalid IPFamily. + - `ResolvedRefs/False/UnsupportedProtocol` - `PartiallyInvalid/True/UnsupportedValue` ### GRPCRoute diff --git a/content/ngf/overview/product-telemetry.md b/content/ngf/overview/product-telemetry.md index 837f71eda..45237d56d 100644 --- a/content/ngf/overview/product-telemetry.md +++ b/content/ngf/overview/product-telemetry.md @@ -32,6 +32,7 @@ Telemetry data is collected once every 24 hours and sent to a service managed by - **SnippetsFilters Info** a list of directive-context strings from applied SnippetFilters and a total count per strings. The actual value of any NGINX directive is **not** collected. - **Control Plane Pod Count** the count of NGINX Gateway Fabric Pods. - **Data Plane Pod Count** the count of NGINX data plane Pods. +- **NGINX One Console Connection Info** indicates whether the connection to the NGINX One Console is enabled. This data is used to identify the following information: - The flavors of Kubernetes environments that are most popular among our users. @@ -39,6 +40,7 @@ This data is used to identify the following information: - The scale of NGINX Gateway Fabric Deployments. - The scale of Gateway API resources. - The used features of NGINX Gateway Fabric. +- The cluster is connected to NGINX One Console. Our goal is to publicly discuss data trends to drive roadmap discussions in our [Community Meeting](https://github.com/nginx/nginx-gateway-fabric/discussions/1472). @@ -56,4 +58,4 @@ helm install ... --set nginxGateway.productTelemetry.enable=false ### Manifests -Add the `--product-telemetry-disable` flag to the `nginx-gateway` container in your Deployment manifest. +Add the `--product-telemetry-disable` flag to the `nginx-gateway` container in your Deployment manifest. \ No newline at end of file diff --git a/content/ngf/reference/api.md b/content/ngf/reference/api.md index d88e6111b..47984b6a3 100644 --- a/content/ngf/reference/api.md +++ b/content/ngf/reference/api.md @@ -1827,6 +1827,23 @@ If not specified, or set to false, http2 will be enabled for all servers.

+disableSNIHostValidation
+ +bool + + + +(Optional) +

DisableSNIHostValidation disables the validation that ensures the SNI hostname +matches the Host header in HTTPS requests. When disabled, HTTPS connections can +be reused for requests to different hostnames covered by the same certificate. +This resolves HTTP/2 connection coalescing issues with wildcard certificates but +introduces security risks as described in Gateway API GEP-3567. +If not specified, defaults to false (validation enabled).

+ + + + kubernetes
@@ -1839,6 +1856,19 @@ KubernetesSpec

Kubernetes contains the configuration for the NGINX Deployment and Service Kubernetes objects.

+ + +workerConnections
+ +int32 + + + +(Optional) +

WorkerConnections specifies the maximum number of simultaneous connections that can be opened by a worker process. +Default is 1024.

+ + @@ -1988,6 +2018,114 @@ sigs.k8s.io/gateway-api/apis/v1alpha2.PolicyStatus +

AutoscalingSpec + +

+

+(Appears on: +DeploymentSpec) +

+

+

AutoscalingSpec is the configuration for the Horizontal Pod Autoscaling.

+

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
FieldDescription
+behavior
+ + +Kubernetes autoscaling/v2.HorizontalPodAutoscalerBehavior + + +		 +(Optional) +

Behavior configures the scaling behavior of the target +in both Up and Down directions (scaleUp and scaleDown fields respectively). +If not set, the default HPAScalingRules for scale up and scale down are used.

+
+targetCPUUtilizationPercentage
+ +int32 + +		 +(Optional) +

Target cpu utilization percentage of HPA.

+
+targetMemoryUtilizationPercentage
+ +int32 + +		 +(Optional) +

Target memory utilization percentage of HPA.

+
+minReplicas
+ +int32 + +		 +(Optional) +

Minimum number of replicas.

+
+metrics
+ + +[]Kubernetes autoscaling/v2.MetricSpec + + +		 +(Optional) +

Metrics configures additional metrics options.

+
+maxReplicas
+ +int32 + +		 +

Maximum number of replicas.

+
+enable
+ +bool + +		 +

Enable or disable Horizontal Pod Autoscaler.

+

ContainerSpec

@@ -2065,6 +2203,34 @@ until the action is complete, unless the container process fails, in which case +readinessProbe
+ + +ReadinessProbeSpec + + + + +(Optional) +

ReadinessProbe defines the readiness probe for the NGINX container.

+ + + + +hostPorts
+ + +[]HostPort + + + + +(Optional) +

HostPorts are the list of ports to expose on the host.

+ + + + volumeMounts
@@ -2099,6 +2265,20 @@ until the action is complete, unless the container process fails, in which case +container
+ + +ContainerSpec + + + + +(Optional) +

Container defines container fields for the NGINX container.

+ + + + pod
@@ -2113,16 +2293,16 @@ PodSpec -container
+patches
- -ContainerSpec + +[]Patch (Optional) -

Container defines container fields for the NGINX container.

+

Patches are custom patches to apply to the NGINX DaemonSet.

@@ -2159,6 +2339,20 @@ int32 +autoscaling
+ + +AutoscalingSpec + + + + +(Optional) +

Autoscaling defines the configuration for Horizontal Pod Autoscaling.

+ + + + pod
@@ -2185,6 +2379,20 @@ ContainerSpec

Container defines container fields for the NGINX container.

+ + +patches
+ + +[]Patch + + + + +(Optional) +

Patches are custom patches to apply to the NGINX Deployment.

+ +

DisableTelemetryFeature @@ -2238,6 +2446,48 @@ routing only to endpoints on the same node as the traffic was received on +

HostPort + +

+

+(Appears on: +ContainerSpec) +

+

+

HostPort exposes an nginx container port on the host.

+

+ + + + + + + + + + + + + + + + + +
FieldDescription
+port
+ +int32 + +		 +

Port to expose on the host.

+
+containerPort
+ +int32 + +		 +

ContainerPort is the port on the nginx container to map to the HostPort.

+

IPFamilyType (string alias)

@@ -2749,6 +2999,23 @@ If not specified, or set to false, http2 will be enabled for all servers.

+disableSNIHostValidation
+ +bool + + + +(Optional) +

DisableSNIHostValidation disables the validation that ensures the SNI hostname +matches the Host header in HTTPS requests. When disabled, HTTPS connections can +be reused for requests to different hostnames covered by the same certificate. +This resolves HTTP/2 connection coalescing issues with wildcard certificates but +introduces security risks as described in Gateway API GEP-3567. +If not specified, defaults to false (validation enabled).

+ + + + kubernetes
@@ -2761,6 +3028,19 @@ KubernetesSpec

Kubernetes contains the configuration for the NGINX Deployment and Service Kubernetes objects.

+ + +workerConnections
+ +int32 + + + +(Optional) +

WorkerConnections specifies the maximum number of simultaneous connections that can be opened by a worker process. +Default is 1024.

+ +

NodePort @@ -2791,9 +3071,7 @@ int32 -

Port is the NodePort to expose. -kubebuilder:validation:Minimum=1 -kubebuilder:validation:Maximum=65535

+

Port is the NodePort to expose.

@@ -2804,9 +3082,7 @@ int32 -

ListenerPort is the Gateway listener port that this NodePort maps to. -kubebuilder:validation:Minimum=1 -kubebuilder:validation:Maximum=65535

+

ListenerPort is the Gateway listener port that this NodePort maps to.

@@ -2862,6 +3138,84 @@ be unique across all targetRef entries in the ObservabilityPolicy.

+

Patch + +

+

+(Appears on: +DaemonSetSpec, +DeploymentSpec, +ServiceSpec) +

+

+

Patch defines a patch to apply to a Kubernetes object.

+

+ + + + + + + + + + + + + + + + + +
FieldDescription
+type
+ + +PatchType + + +		 +(Optional) +

Type is the type of patch. Defaults to StrategicMerge.

+
+value
+ +k8s.io/apiextensions-apiserver/pkg/apis/apiextensions/v1.JSON + +		 +(Optional) +

Value is the patch data as raw JSON. +For StrategicMerge and Merge patches, this should be a JSON object. +For JSONPatch patches, this should be a JSON array of patch operations.

+
+

PatchType +(string alias)

+

+

+(Appears on: +Patch) +

+

+

PatchType specifies the type of patch.

+

+ + + + + + + + + + + + + + +
ValueDescription

"JSONPatch"

PatchTypeJSONPatch uses JSON patch (RFC 6902).

+

"Merge"

PatchTypeMerge uses merge patch (RFC 7386).

+

"StrategicMerge"

PatchTypeStrategicMerge uses strategic merge patch.

+

PodSpec

@@ -3003,6 +3357,53 @@ image isn’t present.

+

ReadinessProbeSpec + +

+

+(Appears on: +ContainerSpec) +

+

+

ReadinessProbeSpec defines the configuration for the NGINX readiness probe.

+

+ + + + + + + + + + + + + + + + + +
FieldDescription
+port
+ +int32 + +		 +(Optional) +

Port is the port on which the readiness endpoint is exposed. +If not specified, the default port is 8081.

+
+initialDelaySeconds
+ +int32 + +		 +(Optional) +

InitialDelaySeconds is the number of seconds after the container has +started before the readiness probe is initiated. +If not specified, the default is 3 seconds.

+

RewriteClientIP

@@ -3286,6 +3687,20 @@ Each NodePort MUST map to a Gateway listener port, otherwise it will be ignored. The default NodePort range enforced by Kubernetes is 30000-32767.

+ + +patches
+ + +[]Patch + + + + +(Optional) +

Patches are custom patches to apply to the NGINX Service.

+ +

ServiceType diff --git a/content/ngf/reference/cli-help.md b/content/ngf/reference/cli-help.md index 193f1c45e..1a867a357 100644 --- a/content/ngf/reference/cli-help.md +++ b/content/ngf/reference/cli-help.md @@ -51,9 +51,13 @@ This command runs the NGINX Gateway Fabric control plane. | _usage-report-resolver_ | _string_ | The nameserver used to resolve the NGINX Plus usage reporting endpoint. Used with NGINX Instance Manager. | | _usage-report-skip-verify_ | _bool_ | Disable client verification of the NGINX Plus usage reporting server certificate. | | _usage-report-ca-secret_ | _string_ | The name of the Secret containing the NGINX Instance Manager CA certificate. Must exist in the same namespace that the NGINX Gateway Fabric control plane is running in (default namespace: nginx-gateway) | -| _usage-report-client-ssl-secret_ | _string_ | TThe name of the Secret containing the client certificate and key for authenticating with NGINX Instance Manager. Must exist in the same namespace that the NGINX Gateway Fabric control plane is running in (default namespace: nginx-gateway) | +| _usage-report-client-ssl-secret_ | _string_ | The name of the Secret containing the client certificate and key for authenticating with NGINX Instance Manager. Must exist in the same namespace that the NGINX Gateway Fabric control plane is running in (default namespace: nginx-gateway) | | _snippets-filters_ | _bool_ | Enable SnippetsFilters feature. SnippetsFilters allow inserting NGINX configuration into the generated NGINX config for HTTPRoute and GRPCRoute resources. | | _nginx-scc_ | _string_ | The name of the SecurityContextConstraints to be used with the NGINX data plane Pods. Only applicable in OpenShift. | +| _nginx-one-dataplane-key-secret_ | _string_ | The name of the secret which holds the dataplane key that is required to authenticate with the NGINX One Console. Secret must exist in the same namespace that the NGINX Gateway Fabric control plane is running in (default namespace: nginx-gateway). | +| _nginx-one-telemetry-endpoint-host_ | _string_ | The endpoint host that the NGINX One Console telemetry metrics will be sent to. | +| _nginx-one-telemetry-endpoint-port_ | _int_ | The endpoint port that the NGINX One Console telemetry metrics will be sent to. | +| _nginx-one-tls-skip-verify_ | _bool_ | Skip TLS verification for NGINX One Console connections. | {{% /bootstrap-table %}} diff --git a/layouts/shortcodes/version-ngf.html b/layouts/shortcodes/version-ngf.html index f93ea0ca3..50aea0e7a 100644 --- a/layouts/shortcodes/version-ngf.html +++ b/layouts/shortcodes/version-ngf.html @@ -1 +1 @@ -2.0.2 \ No newline at end of file +2.1.0 \ No newline at end of file