|
Measures reported by KuberDeployTest
A Deployment provides declarative updates for Pods and ReplicaSets. While a Pod encapsulates an application's container (or, in some cases, multiple containers), storage resources, a unique network IP, and options that govern how the container(s) should run, a ReplicaSet is used to maintain a stable set of replica (identical) Pods running at any given time.
Using a Deployment, you can easily:
Deploy a ReplicaSet Update Pods (PodTemplateSpec) Rollback to older Deployment versions Scale Deployment up or down Pause and resume the Deployment Determine state of replicas Clean up older ReplicaSets Canary Deployment
Whenever a Deployment is used to perform such operations, it is only natural that administrators want to know the status of the deployment - whether it is paused or progressing. Most importantly, administrators will want to be alerted if the Deployment was unable to deliver the intended/desired result of the operation. For instance, an administrator would want to be alerted if any deployment fails to create the desired number of available replicas in a ReplicaSet, fails to update one/more replicas with changes to a Pod template, or does not have the adequate number of Pods to reach full capacity. This is because, such failures may result in a mismatch between the cluster's desired state and its actual state, which in turn may affect the availability and performance of the containerized applications that overlay the cluster. This is where the Deployments by Namespace test helps!
This test auto-discovers Deployments in a Namespace, and for each Deployment, reports the overall status of the deployment - i.e., whether the desired state of the Deployment is the same as its actual state. If the state of the Deployment is Unhealthy, then you can use this test to figure out what could have caused the anomaly - is it because of a replica failure? is it because of unavailable Pods? or is it because of the Pods that are not yet up-to-date with changes made to the Pod template?
Outputs of the test:One set of results for each Deployment in every namespace configured in the Kubernetes cluster being monitored.
First-level Descriptor:Namespace
Second-level Descriptor:Deployment
The measures made by this test are as follows:
| Measurement |
Description |
Measurement Unit |
Interpretation |
| Deploy_state |
Indicates whether/not the desired state of this deployment is the same as its actual state. |
|
This measure reports the value Healthy if the desired state of the Deployment is the same as its actual state. In other words, if the value of the Replicas measure is the same as the value of Total available pods with deployment measure, then this measure will report the value Healthy. If not, this measure will report the value Unhealthy. For instance, if the Deployment seeks to deploy a ReplicaSet with 3 replica (Pods) in it, and succeeds in creating such a ReplicaSet, then the value of this measure will be Healthy. On the other hand, if the Deployment created a ReplicaSet with only two available replica Pods, then the value of this measure will be Unhealthy.
The numeric values that correspond to these measure values are as follows:
| Numeric Value |
Measure Value |
| 1 |
Healthy |
| 0 |
Unhealthy |
Note:
By default, this measure reports the Measure Values discussed above to indicate the state of a Deployment. In the graph of this measure however, the same is indicated using the numeric equivalents only. |
| Status |
Indicates whether/not this Deployment has been paused. |
|
You can pause a Deployment before triggering one or more updates and then resume it. This allows you to apply multiple fixes in between pausing and resuming without triggering unnecessary rollouts.
The values that this measure can report and their corresponding numeric values are listed in the table below:
| Numeric Value |
Measure Value |
| 1 |
Yes |
| 0 |
No |
Note:
By default, this measure reports the Measure Values discussed above to indicate the whether/not a Deployment has been paused. In the graph of this measure however, the same is indicated using the numeric equivalents only. |
| Deployment_age |
Indicates how old this Deployment is. |
|
The value of this measure is expressed in number of days, hours, and minutes. You can use the detailed diagnosis of this measure to know the images that a Deployment pulled from the Container Registry to create containers on replica Pods. |
| Progress_state |
Indicates whether/not this Deployment is in progress. |
|
A Deployment enters various states during its lifecycle.
Kubernetes marks a Deployment as progressing when one of the following tasks is performed:
The Deployment creates a new ReplicaSet. The Deployment is scaling up its newest ReplicaSet. The Deployment is scaling down its older ReplicaSet(s). New Pods become ready or available (ready for at least MinReadySeconds).
Kubernetes marks a Deployment as complete when it has the following characteristics:
The Deployment has minimum availability. Minimum availability means that the Deployment's number of available replicas equals or exceeds the number required by the Deployment strategy. All of the replicas associated with the Deployment have been updated to the latest version you have specified, meaning any updates you've requested have been completed. No old pods for the Deployment are running.
Your Deployment may get stuck trying to deploy its newest ReplicaSet without ever completing. This can occur due to some of the following factors:
Typically, a Deployment is considered to have Failed, if it is making progress for a duration beyond the progressDeadlineSeconds configuration.
This measure reports the value Yes for a Deployment, if it is in the progressing or complete state. The value No is reported, if the Deployment is in fail to progress state. The value Unknown is reported if the Deployment is not in any of the above-mentioned states - i.e., if the state cannot be determined.
The numeric values that correspond to these measure values are as follows:
| Numeric Value |
Measure Value |
| 1 |
Yes |
| 0 |
No |
| 2 |
Unknown |
Note:
By default, this measure reports the Measure Values discussed above to indicate whether/not a Deployment is progressing. In the graph of this measure however, the same is indicated using the numeric equivalents only. |
| Available_state |
Indicates whether/not this Deployment is available. |
Number |
A deployment is said to be Available, if it has minimum availability. Minimum availability is dictated by the parameters specified in the deployment strategy. For instance, if the default Rolling Update strategy is used, then the Max Unavailable parameter of the strategy indicates the Minimum Availability during an upgrade. For example, if the Max Unavailable is set to 25% , then it means that a minimum of 75% of Pods should be available in the Deployment when an update is in progress.
If the Deployment is Available, then the value of this measure is Yes. If the Deployment is unavailable - i.e., if the Minimum Availability criteria is not met - then, the value of this measure is No. If the availability of the Deployment cannot be determined, then the value of this measure will be Unknown.
The values that this measure can report and their corresponding numeric values are listed in the table below:
| Numeric Value |
Measure Value |
| 1 |
Yes |
| 0 |
No |
| 2 |
Unknown |
Note:
By default, this measure reports the Measure Values discussed above to indicate whether/not a Deployment is Available. In the graph of this measure however, the same is indicated using the numeric equivalents only.
If the value of this measure for any Deployment is No, then you can use the detailed diagnosis of this measure to identify the unavailable Pods in the Deployment, and the reason for their unavailability. A Pod is said to be Available, if it is ready without any containers crashing for at least the duration configured against minReadySeconds in the Pod specification. Any Pod that is not ready, or is ready but has containers crashing for a period of time beyond the minReadySeconds duration, is automatically considered Unavailable. |
| Replica_state |
Indicates whether/not any replica in this Deployment has failed. |
|
The value Yes for this measure, indicates that one/more replicas in the Deployment could not be created. The value No indicates that all replicas were created. The value Unknown implies that the state of the replicas could not be determined.
The values that this measure can report and their corresponding numeric values are listed in the table below:
| Numeric Value |
Measure Value |
| 1 |
Yes |
| 0 |
No |
| 2 |
Unknown |
Note:
By default, this measure reports the Measure Values discussed above to indicate whether/not any replicas in the Deployment could not be created. In the graph of this measure however, the same is indicated using the numeric equivalents only.
If the failure of one/more replicas causes a a mismatch between the desired state and actual state of the Deployment, then the value of the Status measure of that Deployment will change to Unhealthy. |
| Observed_count |
Indicates the generation observed after this Deployment. |
Number |
A generation is a sequence number representing a specific generation of the desired state.
If the value of this measure for a Deployment matches with the desired generation sequence number of that Deployment, it implies that the Deployment is complete.
If it does not match, then it means that a Deployment is progressing or has failed. In other words, if the value of the Is progressing? measure for a Deployment is Yes or No, then it means that the desired generation sequence number and the observed generation sequence number of that Deployment is not the same. |
| Replicas |
Indicates the desired number of non-terminated Pod replicas targeted by this Deployment. |
Number |
|
| Update_replica |
Indicates the total number of non-terminated Pod replicas that have been updated by this Deployment with changes (if any) made to the Pod template specification. |
Number |
Typically, whenever changes are made to a Deployment's Pod template - say, labels or container images of the template are changed - then a Deployment rollout is triggered. A new ReplicaSet is created and the Deployment manages moving the Pods from the old ReplicaSet to the new one at a controlled rate. Ideally, the value of this measure should be the same as the value of the Replicas measure. If not, then it means that the desired number of Pod replicas are not yet fully updated with the changes to the Pod template. |
| Ready_replica |
Indicates the number of ready Pods created by this Deployment. |
Number |
|
| Avail_replica |
Indicates the number of available Pods created by this Deployment. |
Number |
A Pod is said to be Available, if it is ready without any containers crashing for at least the duration configured against minReadySeconds in the Pod specification. Ideally, the value of this measure should be the same as the value of the Replicas measure. If not, then the Status measure of this test will report the value Unhealthy. This means that the desired state of the Deployment is not the same as its actual state. |
| UnAvail_replica |
Indicates the total number of unavailable Pods created by this Deployment. |
Number |
Any Pod that is not ready, or is ready but has containers crashing for a period of time beyond the minReadySeconds duration, is automatically considered Unavailable. Ideally, the value of this measure should be 0. If this measure reports a non-zero value or a value equal to or close to the value of the Replicas measure, then the Status measure of this test will report the value Unhealthy. This means that the desired state of the Deployment is not the same as its actual state. In the event that this measure reports a non-zero value, then use the detailed diagnosis of this measure to identify the unavailable Pod replicas in the Deployment. |
| Collision_count |
Indicates the count of hash collisions for this deployment. |
Number |
The Deployment controller uses this field as a collision avoidance mechanism when it needs to create the name for the newest ReplicaSet. |
| No_pods_deploy |
Indicates the number of Pods created by this Deployment that are currently running. |
Number |
To know which Pods created by this Deployment are currently running, use the detailed diagnosis of this measure. |
| Old_replica |
Indicates the number of old Replica Sets that this Deployment should retain to allow rollback. |
Number |
A Deployment's revision history is stored in the ReplicaSets it controls. When configuring a Deployment, you can optionally specify .spec.revisionHistoryLimit, where you can indicate the number of old ReplicaSets to retain to allow rollback. This value is reported as the value of this measure. Old ReplicaSets consume resources in etcd and crowd the output of kubectl get rs. The configuration of each Deployment revision is stored in its ReplicaSets; therefore, once an old ReplicaSet is deleted, you lose the ability to rollback to that revision of Deployment. By default, 10 old ReplicaSets will be kept, however its ideal value depends on the frequency and stability of new Deployments. More specifically, setting this field to zero means that all old ReplicaSets with 0 replicas will be cleaned up. In this case, a new Deployment rollout cannot be undone, since its revision history is cleaned up. |
|