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

crd versioning doc: fix nits (#9142)

Browse Source
This commit is contained in:
Nikhita Raghunath
2018-06-20 01:02:32 +05:30
committed by Misty Linville
parent c255ca9aa1
commit 3678425e44
2 changed files with 10 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md
+1 -1
View File
@@ -107,7 +107,7 @@ Use a custom resource (CRD or Aggregated API) if most of the following apply:
Kubernetes provides two ways to add custom resources to your cluster: Kubernetes provides two ways to add custom resources to your cluster:
- CRDs are simple and do not always require programming. - CRDs are simple and can be created without any programming.
- [API Aggregation](/docs/concepts/api-extension/apiserver-aggregation/) requires programming, but allows more control over API behaviors like how data is stored and conversion between API versions. - [API Aggregation](/docs/concepts/api-extension/apiserver-aggregation/) requires programming, but allows more control over API behaviors like how data is stored and conversion between API versions.
Kubernetes provides these two options to meet the needs of different users, so that neither ease of use nor flexibility are compromised. Kubernetes provides these two options to meet the needs of different users, so that neither ease of use nor flexibility are compromised.
content/en/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning.md
+9 -8
View File
@@ -107,7 +107,7 @@ by parsing the _name_ field to determine the version number, the stability
The algorithm used for sorting the versions is designed to sort versions in the The algorithm used for sorting the versions is designed to sort versions in the
same way that the Kubernetes project sorts Kubernetes versions. Versions start with a same way that the Kubernetes project sorts Kubernetes versions. Versions start with a
`v` followed by a number, an optional `beta` or `alpha` designation, and `v` followed by a number, an optional `beta` or `alpha` designation, and
optional additional versioning information. Broadly, a version string might look optional additional numeric versioning information. Broadly, a version string might look
like `v2` or `v2beta1`. Versions are sorted using the following algorithm: like `v2` or `v2beta1`. Versions are sorted using the following algorithm:
- Entries that follow Kubernetes version patterns are sorted before those that - Entries that follow Kubernetes version patterns are sorted before those that
@@ -149,14 +149,15 @@ the version.
When an object is written, it is persisted at the version designated as the When an object is written, it is persisted at the version designated as the
storage version at the time of the write. If the storage version changes, storage version at the time of the write. If the storage version changes,
existing objects are never converted automatically. However, newly-created existing objects are never converted automatically. However, newly-created
or updated objects are created at the new storage version. It is possible for an or updated objects are written at the new storage version. It is possible for an
object to have been written at a version that is no longer served. object to have been written at a version that is no longer served.
When you read an object, you specify the version as part of the path. If you When you read an object, you specify the version as part of the path. If you
specify a version that is different from the object's persisted version, specify a version that is different from the object's persisted version,
Kubernetes returns the object to you at the version you requested, but does not Kubernetes returns the object to you at the version you requested, but the
modify the persisted object. You can request an object at any version that is persisted object is neither changed on disk, nor converted in any way
currently served. (other than changing the `apiVersion` string) while serving the request.
You can request an object at any version that is currently served.
If you update an existing object, it is rewritten at the version that is If you update an existing object, it is rewritten at the version that is
currently the storage version. This is the only way that objects can change from currently the storage version. This is the only way that objects can change from
@@ -164,15 +165,15 @@ one version to another.
To illustrate this, consider the following hypothetical series of events: To illustrate this, consider the following hypothetical series of events:
1. The storage version is `v1beta`. You create an object. It is persisted in 1. The storage version is `v1beta1`. You create an object. It is persisted in
storage at version `v1beta1` storage at version `v1beta1`
2. You add version `v1` to your CustomResourceDefinition and designate it as 2. You add version `v1` to your CustomResourceDefinition and designate it as
the storage version. the storage version.
3. You read your object at version `v1beta`, then you read the object again at 3. You read your object at version `v1beta1`, then you read the object again at
version `v1`. Both returned objects are identical except for the apiVersion version `v1`. Both returned objects are identical except for the apiVersion
field. field.
4. You create a new object. It is persisted in storage at version `v1`. You now 4. You create a new object. It is persisted in storage at version `v1`. You now
have two objects, one of which is at `v1beta`, and the other of which is at have two objects, one of which is at `v1beta1`, and the other of which is at
`v1`. `v1`.
5. You update the first object. It is now persisted at version `v1` since that 5. You update the first object. It is now persisted at version `v1` since that
is the current storage version. is the current storage version.