whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Fix formatting in 2019-06-20-Future-of-CRDs-Structural-Schemas.md (#15037)

Browse Source 
* Fix formatting in 2019-06-20-Future-of-CRDs-Structural-Schemas.md

Hugo seems to be incompatible with the Github markdown formatting.

* Fix doc link

* Defaulting is alpha
This commit is contained in:
Dr. Stefan Schimanski
2019-06-20 23:42:36 +02:00
committed by Kubernetes Prow Robot
parent aba753c189
commit 07c5dcede1
1 changed files with 17 additions and 14 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/en/blog/_posts/2019-06-20-Future-of-CRDs-Structural-Schemas.md
+17 -14
View File
@@ -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. 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 ```yaml
type: object 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. As you can see also logical constraints using `oneOf`, `allOf`, `anyOf`, `not` are allowed.
To sum up, an OpenAPI schema is structural if To sum up, an OpenAPI schema is structural if<br/><br/>
1. it has the core as defined above out of `properties`, `items`, `additionalProperties`, `type`, `nullable`, `title`, `description`, 1. it has the core as defined above out of `properties`, `items`, `additionalProperties`, `type`, `nullable`, `title`, `description`,<br/>
2. all types are defined, 2. all types are defined,<br/>
3. the core is extended with value validation following the constraints: 3. the core is extended with value validation following the constraints:<br/>
1. inside of value validations no `additionalProperties`, `type`, `nullable`, `title`, `description`, (i) inside of value validations no `additionalProperties`, `type`, `nullable`, `title`, `description`<br/>
2. all fields mentioned in value validation are specified in the core. (ii) all fields mentioned in value validation are specified in the core.
Let us modify our example spec slightly, to make it non-structural: 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. Pruning can only be enabled if the global schema or the schemas of all versions are structural.
If pruning is enabled, the pruning algorithm 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 * assumes that the schema is complete, i.e. every field is mentioned and not-mentioned fields can be dropped
* is run on * is run on<br/>
* data received via an API request (i) data received via an API request<br/>
* after conversion and admission requests (ii) after conversion and admission requests<br/>
* when reading from etcd (using the schema version of the data in etcd). (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: 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 apiVersion: operations/v1
kind: MaintenanceNightlyJob kind: MaintenanceNightlyJob
spec: 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”] machines: [“az1-master1”,”az1-master2”,”az2-master3”]
# pruned: privileged: true # 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) * 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 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). * 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.