From 2590f59f2471a20b822271c0c11470b13a541bad Mon Sep 17 00:00:00 2001 From: Anthony Date: Tue, 15 Aug 2017 15:29:00 +0800 Subject: [PATCH] Update configure-pdb.md add "." and ":" to the sentence --- docs/tasks/run-application/configure-pdb.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/docs/tasks/run-application/configure-pdb.md b/docs/tasks/run-application/configure-pdb.md index 0f0eb0769c..fc42343274 100644 --- a/docs/tasks/run-application/configure-pdb.md +++ b/docs/tasks/run-application/configure-pdb.md @@ -26,7 +26,7 @@ nodes. ## Protecting an Application with a PodDisruptionBudget 1. Identify what application you want to protect with a PodDisruptionBudget (PDB). -1. Think about how your application reacts to disruptions +1. Think about how your application reacts to disruptions. 1. Create a PDB definition as a YAML file. 1. Create the PDB object from the YAML file. @@ -57,22 +57,22 @@ described in [Arbitrary Controllers and Selectors](#arbitrary-controllers-and-se Decide how many instances can be down at the same time for a short period due to a voluntary disruption. -- Stateless frontends +- Stateless frontends: - Concern: don't reduce serving capacity by more than 10%. - Solution: use PDB with minAvailable 90% for example. -- Single-instance Stateful Application +- Single-instance Stateful Application: - Concern: do not terminate this application without talking to me. - Possible Solution 1: Do not use a PDB and tolerate occasional downtime. - Possible Solution 2: Set PDB with maxUnavailable=0. Have an understanding (outside of Kubernetes) that the cluster operator needs to consult you before termination. When the cluster operator contacts you, prepare for downtime, and then delete the PDB to indicate readiness for disruption. Recreate afterwards. -- Multiple-instance Stateful application such as Consul, ZooKeeper, or etcd +- Multiple-instance Stateful application such as Consul, ZooKeeper, or etcd: - Concern: Do not reduce number of instances below quorum, otherwise writes fail. - Possible Solution 1: set maxUnavailable to 1 (works with varying scale of application). - Possible Solution 2: set minAvailable to quorum-size (e.g. 3 when scale is 5). (Allows more disruptions at once). - Restartable Batch Job: - - Concern: Job needs to complete in case of voluntary disruption + - Concern: Job needs to complete in case of voluntary disruption. - Possible solution: Do not create a PDB. The Job controller will create a replacement pod. ## Specifying a PodDisruptionBudget