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

Address Devin's comments

Browse Source
This commit is contained in:
Janet Kuo
2016-12-02 13:35:50 -08:00
committed by Devin Donnelly
parent eef081913b
commit 247e0da932
3 changed files with 7 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files
_data/tasks.yml
+1 -1
View File
@@ -37,5 +37,5 @@ toc:
section:
- title: Upgrading from PetSets to StatefulSets
path: /docs/tasks/manage-stateful-set/upgrade-pet-set-to-stateful-set/
- title: Scaling a Stateful Set
- title: Scaling a StatefulSet
path: /docs/tasks/manage-stateful-set/scale-stateful-set/
docs/tasks/index.md
+1 -1
View File
@@ -31,7 +31,7 @@ single thing, typically by giving a short sequence of steps.
#### Managing Stateful Applications
* [Upgrading from PetSets to StatefulSets](/docs/tasks/manage-stateful-set/upgrade-pet-set-to-stateful-set/)
* [Scaling a Stateful Set](/docs/tasks/manage-stateful-set/scale-stateful-set/)
* [Scaling a StatefulSet](/docs/tasks/manage-stateful-set/scale-stateful-set/)
### What's next
docs/tasks/manage-stateful-set/scale-stateful-set.md
+5 -5
View File
@@ -77,13 +77,13 @@ after those stateful Pods become running and ready.
With a StatefulSet of size > 1, if there is an unhealthy Pod, there is no way
for Kubernetes to know (yet) if it is due to a permanent fault or a transient
one (upgrade/maintenance/node reboot). If it were a permanent fault, scaling
without paying heed to it may lead to a state where the StatefulSet membership
one (upgrade/maintenance/node reboot). If the Pod is unhealthy due to a permanent fault, scaling
without correcting the fault may lead to a state where the StatefulSet membership
drops below a certain minimum number of "replicas" that are needed to function
correctly, leading to unavailability (or worse).
correctly. This may cause your StatefulSet to become unavailable.
If it were a transient one and the Pod were coming back up shortly, you won't
want that to interleave with your scale-up/scale-down operation. Some distributed
If the Pod is unhealthy due to a transient fault and the Pod might become available again,
the transient error may interfere with your scale-up/scale-down operation. Some distributed
databases have issues when nodes join and leave at the same time. It is better
to reason about scaling operations at the application level in these cases, and
perform scaling only when you're sure that your stateful application cluster is