kubernetes
/
community
mirror of https://github.com/kubernetes/community.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

correct some words 

Signed-off-by: liwenqi <vikilwq@zju.edu.cn>

correct again

Signed-off-by: liwenqi <vikilwq@zju.edu.cn>
This commit is contained in:
liwenqi 2016-12-21 17:51:19 +08:00
parent da351aac02
commit a1906f6355
3 changed files with 5 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
contributors/design-proposals/container-runtime-interface-v1.md
View File

@ -225,7 +225,7 @@ applicable to its platform, and should return an error otherwise.
### Keep it minimal ### Keep it minimal
The proposed interface is experimental, i.e., it will go through (many) changes The proposed interface is experimental, i.e., it will go through (many) changes
until it stabilizes. The principle is to to keep the interface minimal and until it stabilizes. The principle is to keep the interface minimal and
extend it later if needed. This includes a several features that are still in extend it later if needed. This includes a several features that are still in
discussion and may be achieved alternatively: discussion and may be achieved alternatively:

6
contributors/design-proposals/control-plane-resilience.md
View File

@ -10,9 +10,9 @@
Some amount of confusion exists around how we currently, and in future Some amount of confusion exists around how we currently, and in future
want to ensure resilience of the Kubernetes (and by implication want to ensure resilience of the Kubernetes (and by implication
Kubernetes Cluster Federation) control plane. This document is an attempt to capture that Kubernetes Cluster Federation) control plane. This document is an attempt to capture that
definitively. It covers areas including self-healing, high definitively. It covers areas including self-healing, high
availability, bootstrapping and recovery. Most of the information in availability, bootstrapping and recovery. Most of the information in
this document already exists in the form of github comments, this document already exists in the form of github comments,
PR's/proposals, scattered documents, and corridor conversations, so PR's/proposals, scattered documents, and corridor conversations, so
document is primarily a consolidation and clarification of existing document is primarily a consolidation and clarification of existing
@ -23,7 +23,7 @@ ideas.
* **Self-healing:** automatically restarting or replacing failed * **Self-healing:** automatically restarting or replacing failed
processes and machines without human intervention processes and machines without human intervention
* **High availability:** continuing to be available and work correctly * **High availability:** continuing to be available and work correctly
even if some components are down or uncontactable. This typically even if some components are down or uncontactable. This typically
involves multiple replicas of critical services, and a reliable way involves multiple replicas of critical services, and a reliable way
to find available replicas. Note that it's possible (but not to find available replicas. Note that it's possible (but not
desirable) to have high desirable) to have high

2
contributors/design-proposals/deploy.md
View File

@ -121,7 +121,7 @@ See issue [#17164](https://github.com/kubernetes/kubernetes/issues/17164).
We store previous deployment version information in annotations `rollout.kubectl.kubernetes.io/change-source` and `rollout.kubectl.kubernetes.io/version` of replication controllers of the deployment, to support rolling back changes as well as for the users to view previous changes with `kubectl rollout history`. We store previous deployment version information in annotations `rollout.kubectl.kubernetes.io/change-source` and `rollout.kubectl.kubernetes.io/version` of replication controllers of the deployment, to support rolling back changes as well as for the users to view previous changes with `kubectl rollout history`.
- `rollout.kubectl.kubernetes.io/change-source`, which is optional, records the kubectl command of the last mutation made to this rollout. Users may use `--record` in `kubectl` to record current command in this annotation. - `rollout.kubectl.kubernetes.io/change-source`, which is optional, records the kubectl command of the last mutation made to this rollout. Users may use `--record` in `kubectl` to record current command in this annotation.
- `rollout.kubectl.kubernetes.io/version` records a version number to distinguish the change sequence of a deployment's - `rollout.kubectl.kubernetes.io/version` records a version number to distinguish the change sequence of a deployment's
replication controllers. A deployment obtains the largest version number from its replication controllers and increments the number by 1 upon update or creation of the deployment, and update the version annotation of its new replication controller. replication controllers. A deployment obtains the largest version number from its replication controllers and increments the number by 1 upon update or creation of the deployment, and updates the version annotation of its new replication controller.
When the users perform a rollback, i.e. `kubectl rollout undo`, the deployment first looks at its existing replication controllers, regardless of their number of replicas. Then it finds the one with annotation `rollout.kubectl.kubernetes.io/version` that either contains the specified rollback version number or contains the second largest version number among all the replication controllers (current new replication controller should obtain the largest version number) if the user didn't specify any version number (the user wants to rollback to the last change). Lastly, it When the users perform a rollback, i.e. `kubectl rollout undo`, the deployment first looks at its existing replication controllers, regardless of their number of replicas. Then it finds the one with annotation `rollout.kubectl.kubernetes.io/version` that either contains the specified rollback version number or contains the second largest version number among all the replication controllers (current new replication controller should obtain the largest version number) if the user didn't specify any version number (the user wants to rollback to the last change). Lastly, it
starts scaling up that replication controller it's rolling back to, and scaling down the current ones, and then update the version counter and the rollout annotations accordingly. starts scaling up that replication controller it's rolling back to, and scaling down the current ones, and then update the version counter and the rollout annotations accordingly.