Enabling and Understanding Application Status

This topic describes how to configure your application so that you can view the status of application instances in the Replicated vendor portal. It also describes the meaning of the different application statuses.

Overview

The vendor portal displays data on the status of instances of your application that are running in customer environments, including the current state (such as Ready or Degraded), the instance uptime, and the average amount of time it takes your application to reach a Ready state during installation. For more information about viewing instance data, see Instance Details.

To compute and display these insights, the vendor portal interprets and aggregates the state of one or more of the supported Kubernetes resources that are deployed to the cluster as part of your application.

The following resource types are supported:

• Deployment
• StatefulSet
• Service
• Ingress
• PersistentVolumeClaims (PVC)
• DaemonSet

For more information about how instance data is sent to the vendor portal, see About Instance and Event Data.

Enable Application Status Insights

To display insights on application status, the vendor portal requires that your application has one or more status informers. Status informers indicate the Kubernetes resources deployed as part of your application that are monitored for changes in state.

To enable status informers for your application, do one of the following, depending on the installation method:

• Helm Installations
• KOTS Installations

Helm Installations

To get instance status data for applications installed with Helm, include the Replicated SDK as a dependency of your application. For information about how to distribute the SDK with your application, see About the Replicated SDK.

After you include the SDK as a dependency, the requirements for enabling status informers vary depending on how your Helm chart-based application is installed:

• For applications installed by running helm install or helm upgrade, the Replicated SDK automatically detects and reports the status of the resources that are part of the Helm release. No additional configuration is required to get instance status data.

• For applications installed by running helm template then kubectl apply, the SDK cannot automatically detect and report the status of resources. You must configure custom status informers by overriding the statusInformers value in the Replicated SDK chart. For example:

  # Helm chart values.yaml file 
  
  replicated:
    statusInformers:
      - deployment/nginx
      - statefulset/mysql
  note

  Applications installed by running helm install or helm upgrade can also use custom status informers. When the replicated.statusInformers field is set, the SDK detects and reports the status of only the resources included in the replicated.statusInformers field.

KOTS Installations

For applications installed with Replicated KOTS, configure one or more status informers in the Replicated Application custom resource. For more information, see Add Status Informers in Adding Resource Status Informers.

When Helm chart-based applications that include the Replicated SDK are deployed by KOTS, the SDK inherits the KOTS status informers configured in the Application custom resource. In this case, the SDK does not automatically report the status of the resources that are part of the Helm release. This prevents discrepancies in the instance data in the vendor platform.

Understanding Application Status

This section provides information about how Replicated interprets and aggregates the status of Kubernetes resources for your application to report an application status.

Resource Statuses

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 provide more than one Kubernetes resource, Replicated aggregates all resource statuses to display a single application status.

Replicated 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