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.
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<br/><br/>
1. it has the core as defined above out of `properties`, `items`, `additionalProperties`, `type`, `nullable`, `title`, `description`,<br/>
2. all types are defined,<br/>
3. the core is extended with value validation following the constraints:<br/>
(i) inside of value validations no `additionalProperties`, `type`, `nullable`, `title`, `description`<br/>
(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<br/>
(i) data received via an API request<br/>
(ii) after conversion and admission requests<br/>
(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.