remarks

Author: mimowo

keps/sig-apps/3329-retriable-and-non-retriable-failures/README.md

@@ -637,8 +637,8 @@ defined in the k8s.io/apis/core/v1 package. Thus, every addition of a new
 condition type will require an API review. The constants will allow users of the
 package to reduce the risk of typing mistakes.
 
-Additionally, for Beta, we will re-evaluate an idea of a generic condition
-type indicating that a pod can be retried, for example `Retriable`.
+Additionally, for Beta, we will re-evaluate an idea of a generic opinionated condition
+type indicating that a pod can be retried, for example `TerminatedByControlPlane`.
 
 Finally, we are going to cover the handling of pod failures associated with the
 new PodCondition types in integration tests.
@@ -671,6 +671,7 @@ condition makes it easier to determine if a failed pod should be restarted):
 - EvictedByTaints (Pod evicted by kube-controller-manager due to taints)
 - GarbageCollected (an orphaned Pod terminated by GC)
 - EvictedByAPI (Pod evicted by Eviction API)
+- EvictedFromUnhealthyNode (initiated by the node lifecycle controller)
 
 The already existing `status.conditions` field in Pod will be used by kubernetes
 control plane components (kube-scheduler and kube-controller-manager) to append
@@ -999,7 +1000,7 @@ Below are some examples to consider, in addition to the aforementioned [maturity
 - Re-evaluate modification to kubelet to send a dedicated condition when
   terminating a Pod, based on user feedback
 - Re-evaluate supporting of `onExitCodes` when `restartPolicy=OnFailure`
-- Re-evaluate introduction of a generic condition type such as `Retriable`
+- Re-evaluate introduction of a generic opinionated condition type
   indicating that a pod should be retried
 - The feature flag enabled by default