From 247e0da93238bc67ca72a5078efa36740ee5b974 Mon Sep 17 00:00:00 2001 From: Janet Kuo Date: Fri, 2 Dec 2016 13:35:50 -0800 Subject: [PATCH] Address Devin's comments --- _data/tasks.yml | 2 +- docs/tasks/index.md | 2 +- docs/tasks/manage-stateful-set/scale-stateful-set.md | 10 +++++----- 3 files changed, 7 insertions(+), 7 deletions(-) diff --git a/_data/tasks.yml b/_data/tasks.yml index 65cd74db91..75c60e32e2 100644 --- a/_data/tasks.yml +++ b/_data/tasks.yml @@ -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/ diff --git a/docs/tasks/index.md b/docs/tasks/index.md index 14fc254b60..e89610777c 100644 --- a/docs/tasks/index.md +++ b/docs/tasks/index.md @@ -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 diff --git a/docs/tasks/manage-stateful-set/scale-stateful-set.md b/docs/tasks/manage-stateful-set/scale-stateful-set.md index 53bdab4a08..a74b8f80d7 100644 --- a/docs/tasks/manage-stateful-set/scale-stateful-set.md +++ b/docs/tasks/manage-stateful-set/scale-stateful-set.md @@ -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