Merge pull request #8702 from vpnachev/fix-typos/api_changes

Fix two typos and trim trailing whitespaces in api_changes.md

Author: k8s-ci-robot

contributors/devel/sig-architecture/api_changes.md

@@ -647,15 +647,15 @@ Of course, code needs tests - `pkg/apis/<group>/validation/validation_test.go`.
 
 ### Declarative Validation
 
-For new APIs, developers should use declarative validation for all validation rules that declarative validation supports. 
-See the [declarative validation tag catalog](https://kubernetes.io/docs/reference/using-api/declarative-validation/) for the list of supported validation rules.  
-This allows you to define validation rules directly on the API types using special Go comment tags. 
+For new APIs, developers should use declarative validation for all validation rules that declarative validation supports.
+See the [declarative validation tag catalog](https://kubernetes.io/docs/reference/using-api/declarative-validation/) for the list of supported validation rules.
+This allows you to define validation rules directly on the API types using special Go comment tags.
 These validation rules are easier to write, review, and maintain as they live alongside the type and field definitions.
 
 A new code generator, `validation-gen`, processes these tags to produce the validation logic automatically, reducing the need to write manual validation code in `validation.go`.
 
 
-Setting up validation code generation involves the following steps. 
+Setting up validation code generation involves the following steps.
 For APIs already using declarative validation, the first 2 plumbing steps can be skipped:
 - Register the desired API group with validation-gen, similar to other code generators([Example PR doc.go change](https://github.com/kubernetes/kubernetes/pull/130724))
 - Wire up the `strategy.go` for the desired API group to use declarative validation ([Example PR strategy.go change](https://github.com/kubernetes/kubernetes/pull/130724))
@@ -695,16 +695,16 @@ type ReplicationControllerSpec struct {
 
 In this example, the `+k8s:optional` and `+k8s:minimum=0` tags specify that the `Replicas` and `MinReadySeconds` fields are optional and must have a value of at least 0 if present.
 
-After adding these tags to your types, you will need to run the code generator to create or update the validation functions. 
-This is typically done by running `make update` or `hack/update-codegen.sh`.  
-To only run the declarative validation code generator, use `hack/update-codegen.sh validation`.  
-Running the validation-gen code generator will create a `zz_generated.validations.go` file for the declarative validations of the associated tagged API types and fields.  
+After adding these tags to your types, you will need to run the code generator to create or update the validation functions.
+This is typically done by running `make update` or `hack/update-codegen.sh`.
+To only run the declarative validation code generator, use `hack/update-codegen.sh validation`.
+Running the validation-gen code generator will create a `zz_generated.validations.go` file for the declarative validations of the associated tagged API types and fields.
 The generated validation methods in this file are then called via the modified `strategy.go` file in the above steps.
 
-Testing the validation logic for the behaviour of a type is identical to the testing that would be done for hand-written validation code.  
+Testing the validation logic for the behaviour of a type is identical to the testing that would be done for hand-written validation code.
 Users will need to write go unit tests similar to what is done for hand-written validation logic that verify specific cases are allowed, disallowed, etc and the validation behaviour is as expected.
 
-While the goal is to express as much validation declaratively as possible, some complex or validation rules might still require manual implementation in `validation.go`. 
+While the goal is to express as much validation declaratively as possible, some complex or validation rules might still require manual implementation in `validation.go`.
 
 ## Edit version conversions
 
@@ -775,7 +775,7 @@ The generators that create go code have a `--go-header-file` flag
 which should be a file that contains the header that should be
 included. This header is the copyright that should be present at the
 top of the generated file and should be checked with the
-[`repo-infra/verify/verify-boilerplane.sh`](https://git.k8s.io/repo-infra/verify/verify-boilerplate.sh)
+[`repo-infra/verify/verify-boilerplate.sh`](https://git.k8s.io/repo-infra/verify/verify-boilerplate.sh)
 script at a later stage of the build.
 
 To invoke these generators, you can run `make update`, which runs a bunch of
@@ -1310,7 +1310,7 @@ best illustrates these cases:
 
 A good example of ratcheting validation was introduced in [this pull request](https://github.com/kubernetes/kubernetes/pull/130233).
 It introduced validation for the optional `.spec.serviceName` field for StatefulSet,
-such that old resources (nregarldess of whether they are valid or not) will succeed
+such that old resources (regardless of whether they are valid or not) will succeed
 the validation check, but new resources must adhere to stricter validation rules
 for that field. The relevant changes include:
 - A struct with options passed to validation methods (here it's the `StatefulSetValidationOptions`