From bda3cea5a6b3ea222be305f79d091ac77dd1a633 Mon Sep 17 00:00:00 2001
From: Aldo Culquicondor <1299064+alculquicondor@users.noreply.github.com>
Date: Thu, 14 Jan 2021 14:47:31 -0500
Subject: [PATCH] Remove indication that a failed scheduling attempt removes
 the Pod

/sig scheduling
---
 content/en/docs/concepts/workloads/pods/pod-lifecycle.md | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/content/en/docs/concepts/workloads/pods/pod-lifecycle.md b/content/en/docs/concepts/workloads/pods/pod-lifecycle.md
index df83f7c5f3..832785923a 100644
--- a/content/en/docs/concepts/workloads/pods/pod-lifecycle.md
+++ b/content/en/docs/concepts/workloads/pods/pod-lifecycle.md
@@ -38,8 +38,7 @@ If a {{< glossary_tooltip term_id="node" >}} dies, the Pods scheduled to that no
 are [scheduled for deletion](#pod-garbage-collection) after a timeout period.
 
 Pods do not, by themselves, self-heal. If a Pod is scheduled to a
-{{< glossary_tooltip text="node" term_id="node" >}} that then fails,
-or if the scheduling operation itself fails, the Pod is deleted; likewise, a Pod won't
+{{< glossary_tooltip text="node" term_id="node" >}} that then fails, the Pod is deleted; likewise, a Pod won't
 survive an eviction due to a lack of resources or Node maintenance. Kubernetes uses a
 higher-level abstraction, called a
 {{< glossary_tooltip term_id="controller" text="controller" >}}, that handles the work of