Displaying Application Status
This topic describes how to use status informers to display the status of an application instance in the Replicated admin console.
About Status Informers
You can configure the Application custom resource to display application status on the dashboard of the admin console.
The following shows an example of how an Unavailable status displays on the admin console dashboard:
To display application status on the admin console dashboard, you add one or more status informers. Status informers are supported Kubernetes resources for your application that you add to the statusInformers property of the Application custom resource manifest file. The app manager watches all Kubernetes resources that you add for changes in state.
Because status informers can help users diagnose and troubleshoot problems with their application instance, Replicated recommends that you add at least one resource to the statusInformers property for the app manager to watch. For more information, see Add Status Informers below.
The following resource types are supported for displaying application status:
- Deployment
- StatefulSet
- Service
- Ingress
- PersistentVolumeClaims (PVC)
- DaemonSet
You can target resources of the supported types that are deployed in any of the following ways:
- Deployed directly by the Replicated app manager.
- Deployed by a Kubernetes Operator that is deployed by the app manager. For more information, see About Packaging a Kubernetes Operator Application.
- Deployed by Helm. For more information, see Helm Overview.
Resource Statuses
The Replicated app manager records the status of each Kubernetes resource that you add to the statusInformers property. Possible resource statuses are Ready, Updating, Degraded, Unavailable, and Missing.
The following table lists the supported Kubernetes resources and the conditions that contribute to each status:
| Deployment | StatefulSet | Service | Ingress | PVC | DaemonSet | |
|---|---|---|---|---|---|---|
| Ready | Ready replicas equals desired replicas | Ready replicas equals desired replicas | All desired endpoints are ready, any load balancers have been assigned | All desired backend service endpoints are ready, any load balancers have been assigned | Claim is bound | Ready daemon pods equals desired scheduled daemon pods |
| Updating | The deployed replicas are from a different revision | The deployed replicas are from a different revision | N/A | N/A | N/A | The deployed daemon pods are from a different revision |
| Degraded | At least 1 replica is ready, but more are desired | At least 1 replica is ready, but more are desired | At least one endpoint is ready, but more are desired | At least one backend service endpoint is ready, but more are desired | N/A | At least one daemon pod is ready, but more are desired |
| Unavailable | No replicas are ready | No replicas are ready | No endpoints are ready, no load balancer has been assigned | No backend service endpoints are ready, no load balancer has been assigned | Claim is pending or lost | No daemon pods are ready |
| Missing | Missing is an initial deployment status indicating that informers have not reported their status because the application has just been deployed and the underlying resource has not been created yet. After the resource is created, the status changes. However, if a resource changes from another status to Missing, then the resource was either deleted or the informers failed to report a status. | |||||
Aggregate Application Status
When you add more than one Kubernetes resource to the statusInformers property, the app manager aggregates all resource statuses to display a single application status on the admin console dashboard.
The app manager uses the least available resource status to represent the aggregate application status. For example, if at least one resource has an Unavailable status, then the aggregate application status is Unavailable.
The following table describes the resource statuses that define each aggregate application status:
| Resource Statuses | Aggregate Application Status |
|---|---|
| No status available for any resource | Missing |
| One or more resources Unavailable | Unavailable |
| One or more resources Degraded | Degraded |
| One or more resources Updating | Updating |
| All resources Ready | Ready |
Add Status Informers
To add a status informer, include the statusInformers property in the Application custom resource manifest file.
Status informers are in the format [namespace/]type/name, where namespace is optional and defaults to the current namespace.
Example:
apiVersion: kots.io/v1beta1
kind: Application
metadata:
name: my-application
spec:
statusInformers:
- deployment/my-web-svc
- deployment/my-worker
The statusInformers property also supports template functions. Using template functions allows you to include or exclude a status informer based on a customer-provided configuration value:
Example:
statusInformers:
- deployment/my-web-svc
- '{{repl if ConfigOptionEquals "option" "value"}}deployment/my-worker{{repl else}}{{repl end}}'
In the example above, the deployment/my-worker status informer is excluded unless the statement in the ConfigOptionEquals template function evaluates to true.
For more information about using template functions in application manifest files, see About Template Functions.