From fa598f196e10b953b462c834fbace7a3f95591fc Mon Sep 17 00:00:00 2001 From: Laurens Versluis Date: Tue, 4 Feb 2020 00:15:26 +0100 Subject: [PATCH] Typo fix (#18830) --- .../docs/tutorials/kubernetes-basics/update/update-intro.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/tutorials/kubernetes-basics/update/update-intro.html b/content/en/docs/tutorials/kubernetes-basics/update/update-intro.html index aa6f9b4063..3531cfd3b5 100644 --- a/content/en/docs/tutorials/kubernetes-basics/update/update-intro.html +++ b/content/en/docs/tutorials/kubernetes-basics/update/update-intro.html @@ -31,7 +31,7 @@ weight: 10

Users expect applications to be available all the time and developers are expected to deploy new versions of them several times a day. In Kubernetes this is done with rolling updates. Rolling updates allow Deployments' update to take place with zero downtime by incrementally updating Pods instances with new ones. The new Pods will be scheduled on Nodes with available resources.

In the previous module we scaled our application to run multiple instances. This is a requirement for performing updates without affecting application availability. By default, the maximum number of Pods that can be unavailable during the update and the maximum number of new Pods that can be created, is one. Both options can be configured to either numbers or percentages (of Pods). - In Kubernetes, updates are versioned and any Deployment update can be reverted to previous (stable) version.

+ In Kubernetes, updates are versioned and any Deployment update can be reverted to a previous (stable) version.