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

Merge pull request #3206 from knightXun/patch-2 

fix wrong words
This commit is contained in:
Kubernetes Prow Robot 2019-02-05 12:56:19 -08:00 committed by GitHub
parent 0314de3c2d 8f90651572
commit 780acb6719
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 2 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
contributors/design-proposals/apps/deployment.md
View File

@ -132,7 +132,7 @@ The DeploymentController will process Deployments and crud ReplicaSets.
For each creation or update for a Deployment, it will:
1. Find all RSs (ReplicaSets) whose label selector is a superset of DeploymentSpec.Selector.
- For now, we will do this in the client - list all RSs and then filter the
- For now, we will do this in the client - list all RSs and then filter out the
ones we want. Eventually, we want to expose this in the API.
2. The new RS can have the same selector as the old RS and hence we add a unique
selector to all these RSs (and the corresponding label to their pods) to ensure
@ -153,7 +153,7 @@ For each creation or update for a Deployment, it will:
is same as hash of DeploymentSpec.PodTemplateSpec. If it exists already, then
this is the RS that will be ramped up. If there is no such RS, then we create
a new one using DeploymentSpec and then add a "pod-template-hash" label
to it. The size of the new RS depends on the used DeploymentStrategyType
to it. The size of the new RS depends on the used DeploymentStrategyType.
4. Scale up the new RS and scale down the olds ones as per the DeploymentStrategy.
Raise events appropriately (both in case of failure or success).
5. Go back to step 1 unless the new RS has been ramped up to desired replicas