diff --git a/content/en/blog/_posts/2019-06-20-Future-of-CRDs-Structural-Schemas.md b/content/en/blog/_posts/2019-06-20-Future-of-CRDs-Structural-Schemas.md
index 0d965479a8230..4ef0dafa78ff5 100644
--- a/content/en/blog/_posts/2019-06-20-Future-of-CRDs-Structural-Schemas.md
+++ b/content/en/blog/_posts/2019-06-20-Future-of-CRDs-Structural-Schemas.md
@@ -58,7 +58,7 @@ The **core of a structural schema** is an OpenAPI v3 schema made out of
In addition, all types must be non-empty, and in each sub-schema only one of `properties`, `additionalProperties` or `items` may be used.
-Here is an example of our `MaintenanceJob`:
+Here is an example of our `MaintenanceNightlyJob`:
```yaml
type: object
@@ -110,12 +110,12 @@ Some notable restrictions for these additional value validations:
As you can see also logical constraints using `oneOf`, `allOf`, `anyOf`, `not` are allowed.
-To sum up, an OpenAPI schema is structural if
-1. it has the core as defined above out of `properties`, `items`, `additionalProperties`, `type`, `nullable`, `title`, `description`,
-2. all types are defined,
-3. the core is extended with value validation following the constraints:
- 1. inside of value validations no `additionalProperties`, `type`, `nullable`, `title`, `description`,
- 2. all fields mentioned in value validation are specified in the core.
+To sum up, an OpenAPI schema is structural if
+1. it has the core as defined above out of `properties`, `items`, `additionalProperties`, `type`, `nullable`, `title`, `description`,
+2. all types are defined,
+3. the core is extended with value validation following the constraints:
+ (i) inside of value validations no `additionalProperties`, `type`, `nullable`, `title`, `description`
+ (ii) all fields mentioned in value validation are specified in the core.
Let us modify our example spec slightly, to make it non-structural:
@@ -169,11 +169,12 @@ spec:
Pruning can only be enabled if the global schema or the schemas of all versions are structural.
If pruning is enabled, the pruning algorithm
+
* assumes that the schema is complete, i.e. every field is mentioned and not-mentioned fields can be dropped
-* is run on
- * data received via an API request
- * after conversion and admission requests
- * when reading from etcd (using the schema version of the data in etcd).
+* is run on
+ (i) data received via an API request
+ (ii) after conversion and admission requests
+ (iii) when reading from etcd (using the schema version of the data in etcd).
As we don’t specify `privileged` in our structural example schema, the malicious field is pruned from before persisting to etcd:
@@ -181,7 +182,9 @@ As we don’t specify `privileged` in our structural example schema, the malicio
apiVersion: operations/v1
kind: MaintenanceNightlyJob
spec:
- command: grep backdoor /etc/passwd || echo “backdoor:76asdfh76:/bin/bash” >> /etc/passwd || true
+ shell: >
+ grep backdoor /etc/passwd ||
+ echo “backdoor:76asdfh76:/bin/bash” >> /etc/passwd || true
machines: [“az1-master1”,”az1-master2”,”az2-master3”]
# pruned: privileged: true
```
@@ -227,8 +230,8 @@ Any new feature for CRDs starting from Kubernetes 1.15 will require to have a st
* publishing of OpenAPI validation schemas and therefore support for kubectl client-side validation, and `kubectl explain` support (beta in Kubernetes 1.15)
* CRD conversion (beta in Kubernetes 1.15)
-* CRD defaulting (beta in Kubernetes 1.15)
+* CRD defaulting (alpha in Kubernetes 1.15)
* Server-side apply (alpha in Kubernetes 1.15, CRD support pending).
-Of course [structural schemas](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/#specifying-a-structural-schema) are also described in the Kubernetes documentation for the 1.15 release.
+Of course [structural schemas](https://kubernetes.io/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/#specifying-a-structural-schema) are also described in the Kubernetes documentation for the 1.15 release.