@@ -120,6 +120,31 @@ satisfy the StatefulSet specification.
120
120
Different kinds of object can also have different ` .status ` ; again, the API reference pages
121
121
detail the structure of that ` .status ` field, and its content for each different type of object.
122
122
123
+ ## Server side field validation
124
+
125
+ Starting with Kubernetes v1.25, the API server offers server side
126
+ [ field validation] ( /docs/reference/using-api/api-concepts/#field-validation )
127
+ that detects unrecognized or duplicate fields in an object. It provides all the functionality
128
+ of ` kubectl --validate ` on the server side.
129
+
130
+ The ` kubectl ` tool uses the ` --validate ` flag to set the level of field validation. It accepts the
131
+ values ` ignore ` , ` warn ` , and ` strict ` while also accepting the values ` true ` (equivalent to ` strict ` )
132
+ and ` false ` (equivalent to ` ignore ` ). The default validation setting for ` kubectl ` is ` --validate=true ` .
133
+
134
+ ` Strict `
135
+ : Strict field validation, errors on validation failure
136
+
137
+ ` Warn `
138
+ : Field validation is performed, but errors are exposed as warnings rather than failing the request
139
+
140
+ ` Ignore `
141
+ : No server side field validation is performed
142
+
143
+ When ` kubectl ` cannot connect to an API server that supports field validation it will fall back
144
+ to using client-side validation. Kubernetes 1.27 and later versions always offer field validation;
145
+ older Kubernetes releases might not. If your cluster is older than v1.27, check the documentation
146
+ for your version of Kubernetes.
147
+
123
148
## {{% heading "whatsnext" %}}
124
149
125
150
If you're new to Kubernetes, read more about the following:
0 commit comments