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

typo fix (#8667)

Browse Source
This commit is contained in:
lovejoy
2018-05-22 22:30:55 +08:00
committed by k8s-ci-robot
parent 0c5c9a5fdd
commit efbcfeee7c
3 changed files with 8 additions and 8 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/en/docs/concepts/workloads/controllers/deployment.md
+2 -2
View File
@@ -374,7 +374,7 @@ nginx-deployment-3066724191-eocby 0/1 ImagePullBackOff 0 6s
{{< note >}}
**Note:** The Deployment controller will stop the bad rollout automatically, and will stop scaling up the new
ReplicaSet. This depends on the rollingUpdate parameters (`maxUnavailable` specifically) that you have specified.
Kubernetes by default sets the value to 1 and `spec.replicas` to 1 so if you haven't cared about setting those
Kubernetes by default sets the value to 1 and `.spec.replicas` to 1 so if you haven't cared about setting those
parameters, your Deployment can have 100% unavailability by default! This will be fixed in Kubernetes in a future
version.
{{< /note >}}
@@ -702,7 +702,7 @@ due to some of the following factors:
* Application runtime misconfiguration
One way you can detect this condition is to specify a deadline parameter in your Deployment spec:
([`spec.progressDeadlineSeconds`](#progress-deadline-seconds)). `spec.progressDeadlineSeconds` denotes the
([`.spec.progressDeadlineSeconds`](#progress-deadline-seconds)). `.spec.progressDeadlineSeconds` denotes the
number of seconds the Deployment controller waits before indicating (in the Deployment status) that the
Deployment progress has stalled.