You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The status of cluster Operators includes their condition type, informing you of the current state of your Operator's health. The following definitions cover a list of some common ClusterOperator condition types. Operators that have additional condition types and use Operator-specific language have been omitted.
9
+
The status of cluster Operators includes their condition type, which informs you of the current state of your Operator's health. The following definitions cover a list of some common ClusterOperator condition types. Operators that have additional condition types and use Operator-specific language have been omitted.
10
10
11
11
The Cluster Version Operator (CVO) is responsible for collecting the status conditions from cluster Operators so that cluster administrators can better understand the state of the {product-title} cluster.
12
12
@@ -19,25 +19,25 @@ The Cluster Version Operator (CVO) is responsible for collecting the status cond
19
19
20
20
21
21
* Available:
22
-
An Operator with the condition type `Available` is functional and available in the cluster. If the status is `False`, at least one part of the operand is non-functional and the condition requires an administrator to intervene.
22
+
The condition type `Available` indicates that an Operator is functional and available in the cluster. If the status is `False`, at least one part of the operand is non-functional and the condition requires an administrator to intervene.
23
23
24
24
* Progressing:
25
-
An Operator with the condition type `Progressing` is actively rolling out new code, propagating configuration changes, or otherwise moving from one steady state to another.
25
+
The condition type `Progressing` indicates that an Operator is actively rolling out new code, propagating configuration changes, or otherwise moving from one steady state to another.
26
26
+
27
-
Operators do not report the condition type `Progressing` as `True` when they are reconciling a previous known state. If the observed cluster state has changed and the Operator is reacting to it, then the status will report back as `True`, since it is moving from one steady state to another.
27
+
Operators do not report the condition type `Progressing` as `True` when they are reconciling a previous known state. If the observed cluster state has changed and the Operator is reacting to it, then the status reports back as `True`, since it is moving from one steady state to another.
28
28
+
29
29
* Degraded:
30
-
An Operator with the condition type `Degraded` has a current state that does not match the required state over a period of time. The period of time can vary by component, but a `Degraded`state represents persistent observation of an Operator's condition. As a result, an Operator will not fluctuate in and out of the `Degraded` state.
30
+
The condition type `Degraded`indicates that an Operator has a current state that does not match its required state over a period of time. The period of time can vary by component, but a `Degraded`status represents persistent observation of an Operator's condition. As a result, an Operator does not fluctuate in and out of the `Degraded` state.
31
31
+
32
32
There might be a different condition type if the transition from one state to another does not persist over a long enough period to report `Degraded`.
33
-
An Operator will not report `Degraded` during the course of a normal upgrade. An Operator may report `Degraded` in response to a persistent infrastructure failure that requires eventual administrator intervention.
33
+
An Operator does not report `Degraded` during the course of a normal upgrade. An Operator may report `Degraded` in response to a persistent infrastructure failure that requires eventual administrator intervention.
34
34
+
35
35
[NOTE]
36
36
====
37
37
This condition type is only an indication that something may need investigation and adjustment. As long as the Operator is available, the `Degraded` condition does not cause user workload failure or application downtime.
38
38
====
39
39
+
40
40
* Upgradeable:
41
-
An Operator with the condition type `Upgradeable` indicates whether the Operator is safe to upgrade based on the current cluster state. The message field will contain a human-readable description of what the administrator needs to do for the cluster to successfully update. The CVO allows updates when this condition is `True`, `Unknown` or missing.
41
+
The condition type `Upgradeable` indicates whether the Operator is safe to upgrade based on the current cluster state. The message field contains a human-readable description of what the administrator needs to do for the cluster to successfully update. The CVO allows updates when this condition is `True`, `Unknown` or missing.
42
42
+
43
43
When the `Upgradeable` status is `False`, only minor updates are impacted, and the CVO prevents the cluster from performing impacted updates unless forced.
The Cluster Version Operator (CVO) monitors cluster Operators and other components, and is responsible for collecting the status of both the cluster version and its Operators. This status includes the condition type, which informs you of the health and current state of the {product-title} cluster.
10
+
11
+
In addition to `Available`, `Progressing`, and `Upgradeable`, there are condition types that affect cluster versions and Operators.
12
+
13
+
* Failing:
14
+
The cluster version condition type `Failing` indicates that a cluster cannot reach its desired state, is unhealthy, and requires an administrator to intervene.
15
+
16
+
* Invalid:
17
+
The cluster version condition type `Invalid` indicates that the cluster version has an error that prevents the server from taking action. The CVO only reconciles the current state as long as this condition is set.
18
+
19
+
* RetrievedUpdates:
20
+
The cluster version condition type `RetrievedUpdates` indicates whether or not available updates have been retrieved from the upstream update server. The condition is `Unknown` before retrieval, `False` if the updates either recently failed or could not be retrieved, or `True` if the `availableUpdates` field is both recent and accurate.
21
+
22
+
* ReleaseAccepted:
23
+
The cluster version condition type `ReleaseAccepted` with a `True` status indicates that the requested release payload was successfully loaded without failure during image verification and precondition checking.
24
+
25
+
* ImplicitlyEnabledCapabilities:
26
+
The cluster version condition type `ImplicitlyEnabledCapabilities` with a `True` status indicates that there are enabled capabilities that the user is not currently requesting through `spec.capabilities`. The CVO does not support disabling capabilities if any associated resources were previously managed by the CVO.
xref:../updating/preparing-eus-eus-upgrade.adoc#preparing-eus-eus-upgrade[Preparing to perform an EUS-to-EUS update]: Due to fundamental Kubernetes design, all {product-title} updates between minor versions must be serialized. You must update from {product-title} 4.10 to 4.11, and then to 4.12. You cannot update from {product-title} 4.10 to 4.12 directly. However, if you want to update between two Extended Update Support (EUS) versions, you can do so by incurring only a single reboot of non-control plane hosts. For more information, see the following:
0 commit comments