Skip to content

Commit 162deb5

Browse files
authored
Extend resource validation doc to include NGF resources (#1399)
Problem: The resource validation doc does not include information on how we validate NGINX Gateway Fabric resources. Solution: Add a section on NGINX Gateway Fabric resources to the resource validation doc.
1 parent c02f0e8 commit 162deb5

File tree

1 file changed

+69
-6
lines changed

1 file changed

+69
-6
lines changed

site/content/overview/resource-validation.md

+69-6
Original file line numberDiff line numberDiff line change
@@ -1,12 +1,16 @@
11
---
2-
title: "Gateway API Resource Validation"
2+
title: "Resource Validation"
33
weight: 800
44
toc: true
55
docs: "DOCS-000"
66
---
77

88
## Overview
99

10+
This document describes how NGINX Gateway Fabric validates Gateway API and NGINX Gateway Fabric Kubernetes resources.
11+
12+
## Gateway API Resource Validation
13+
1014
NGINX Gateway Fabric validates Gateway API resources for several reasons:
1115

1216
- _Robustness_: to gracefully handle invalid resources.
@@ -15,7 +19,7 @@ NGINX Gateway Fabric validates Gateway API resources for several reasons:
1519

1620
The process involves four different steps, explained in detail in this document, with the goal of making sure that NGINX continues to handle traffic even if invalid Gateway API resources were created.
1721

18-
## Step 1 - OpenAPI Scheme validation by Kubernetes API Server
22+
### Step 1 - OpenAPI Scheme validation by Kubernetes API Server
1923

2024
The Kubernetes API server validates Gateway API resources against the OpenAPI schema embedded in the Gateway API CRDs. For example, if you create an HTTPRoute with an invalid hostname "cafe.!@#$%example.com", the API server will reject it with the following error:
2125

@@ -29,7 +33,7 @@ The HTTPRoute "coffee" is invalid: spec.hostnames[0]: Invalid value: "cafe.!@#$%
2933

3034
{{< note >}}While unlikely, bypassing this validation step is possible if the Gateway API CRDs are modified to remove the validation. If this happens, Step 4 will reject any invalid values (from NGINX perspective).{{< /note >}}
3135

32-
## Step 2 - CEL or Webhook validation by Kubernetes
36+
### Step 2 - CEL or Webhook validation by Kubernetes
3337

3438
- **Kubernetes 1.25 and later - CEL validation by Kubernetes API Server**
3539

@@ -60,7 +64,7 @@ The HTTPRoute "coffee" is invalid: spec.hostnames[0]: Invalid value: "cafe.!@#$%
6064

6165
{{< note >}}Bypassing this validation step is possible if the webhook is not running in the cluster. If this happens, Step 3 will reject the invalid values.{{< /note >}}
6266

63-
## Step 3 - Webhook validation by NGINX Gateway Fabric
67+
### Step 3 - Webhook validation by NGINX Gateway Fabric
6468

6569
To ensure that the resources are validated with the webhook validation rules, even if the webhook is not running, NGINX Gateway Fabric performs the same validation. However, NGINX Gateway Fabric performs the validation _after_ the Kubernetes API server accepts the resource.
6670

@@ -80,7 +84,7 @@ Events:
8084

8185
{{< note >}}This validation step always runs and cannot be bypassed. NGINX Gateway Fabric will ignore any resources that fail the webhook validation, like in the example above. If the resource previously existed, NGINX Gateway Fabric will remove any existing NGINX configuration for that resource.{{< /note >}}
8286

83-
## Step 4 - Validation by NGINX Gateway Fabric
87+
### Step 4 - Validation by NGINX Gateway Fabric
8488

8589
This step catches the following cases of invalid values:
8690

@@ -117,7 +121,7 @@ Status:
117121

118122
{{< note >}}This validation step always runs and cannot be bypassed.{{< /note >}}
119123

120-
## Confirm validation
124+
### Confirm validation
121125

122126
To confirm that a resource is valid and accepted by NGINX Gateway Fabric, check that the **Accepted** condition in the resource status has the Status field set to **True**. For example, in a status of a valid HTTPRoute, if NGINX Gateway Fabric accepts a parentRef, the status of that parentRef will look like this:
123127

@@ -141,3 +145,62 @@ Status:
141145
```
142146

143147
{{< note>}}Make sure the reported observed generation is the same as the resource generation.{{< /note >}}
148+
149+
## NGINX Gateway Fabric Resource Validation
150+
151+
### Step 1 - OpenAPI Scheme validation by Kubernetes API Server
152+
153+
The Kubernetes API server validates NGINX Gateway Fabric resources against the OpenAPI schema embedded in the NGINX Gateway Fabric CRDs. For example, if you create an NginxGateway with an invalid logging level, "some-level", the API server will reject it with the following error:
154+
155+
```shell
156+
kubectl apply -f nginx-gateway-config.yaml
157+
```
158+
159+
```text
160+
The NginxGateway "nginx-gateway-config" is invalid: spec.logging.level: Unsupported value: "some-level": supported values: "info", "debug", "error"
161+
```
162+
163+
{{< note >}}While unlikely, bypassing this validation step is possible if the NGINX Gateway Fabric CRDs are modified to remove the validation. If this happens, Step 2 will report an error in the resource's status.{{< /note >}}
164+
165+
### Step 2 - Validation by NGINX Gateway Fabric
166+
167+
This step validates the settings in the NGINX Gateway Fabric CRDs and rejects invalid resources. The validation error is reported via the status and as an Event. For example:
168+
169+
```shell
170+
kubectl describe nginxgateways.gateway.nginx.org nginx-gateway-config
171+
```
172+
173+
Status:
174+
175+
```text
176+
...
177+
Status:
178+
Conditions:
179+
Last Transition Time: 2023-12-15T21:02:30Z
180+
Message: Failed to update control plane configuration: logging.level: Unsupported value: "some-level": supported values: "info", "debug", "error"
181+
Observed Generation: 1
182+
Reason: Invalid
183+
Status: False
184+
Type: Valid
185+
```
186+
187+
Event:
188+
189+
```text
190+
Warning UpdateFailed 1s (x2 over 1s) nginx-gateway-fabric-nginx Failed to update control plane configuration: logging.level: Unsupported value: "some-level": supported values: "info", "debug", "error"
191+
```
192+
193+
### Confirm validation
194+
195+
To confirm that a resource is valid and accepted by NGINX Gateway Fabric, check that the **Valid** condition in the resource status has the Status field set to **True**. For example, the status of a valid NginxGateway will look like this:
196+
197+
```text
198+
Status:
199+
Conditions:
200+
Last Transition Time: 2023-12-15T21:04:49Z
201+
Message: NginxGateway is valid
202+
Observed Generation: 1
203+
Reason: Valid
204+
Status: True
205+
Type: Valid
206+
```

0 commit comments

Comments
 (0)