Skip to main content

Adding Resource Status Informers

This topic describes how to add status informers for your application. Status informers apply only to applications installed with Replicated KOTS. For information about how to collect application status data for applications installed with Helm, see Enabling and Understanding Application Status.

About Status Informers

Status informers are a feature of KOTS that report on the status of supported Kubernetes resources deployed as part of your application. You enable status informers by listing the target resources under the statusInformers property in the Replicated Application custom resource. KOTS watches all of the resources that you add to the statusInformers property for changes in state.

Possible resource statuses are Ready, Updating, Degraded, Unavailable, and Missing. For more information, see Understanding Application Status.

When you one or more status informers to your application, KOTS automatically does the following:

  • Displays application status for your users on the dashboard of the Admin Console. This can help users diagnose and troubleshoot problems with their instance. The following shows an example of how an Unavailable status displays on the Admin Console dashboard:

    Unavailable status on the Admin Console dashboard
  • Sends application status data to the Vendor Portal. This is useful for viewing insights on instances of your application running in customer environments, such as the current status and the average uptime. For more information, see Instance Details.

    The following shows an example of the Vendor Portal Instance details page with data about the status of an instance over time:

    Instance details full page

    View a larger version of this image

Add Status Informers

To create status informers for your application, add one or more supported resource types to the statusInformers property in the Application custom resource. See statusInformers in Application.

The following resource types are supported:

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

You can target resources of the supported types that are deployed in any of the following ways:

Examples

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.

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:

DeploymentStatefulSetServiceIngressPVCDaemonSet
ReadyReady replicas equals desired replicasReady replicas equals desired replicasAll desired endpoints are ready, any load balancers have been assignedAll desired backend service endpoints are ready, any load balancers have been assignedClaim is boundReady daemon pods equals desired scheduled daemon pods
UpdatingThe deployed replicas are from a different revisionThe deployed replicas are from a different revisionN/AN/AN/AThe deployed daemon pods are from a different revision
DegradedAt least 1 replica is ready, but more are desiredAt least 1 replica is ready, but more are desiredAt least one endpoint is ready, but more are desiredAt least one backend service endpoint is ready, but more are desiredN/AAt least one daemon pod is ready, but more are desired
UnavailableNo replicas are readyNo replicas are readyNo endpoints are ready, no load balancer has been assignedNo backend service endpoints are ready, no load balancer has been assignedClaim is pending or lostNo daemon pods are ready
MissingMissing 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 StatusesAggregate Application Status
No status available for any resourceMissing
One or more resources UnavailableUnavailable
One or more resources DegradedDegraded
One or more resources UpdatingUpdating
All resources ReadyReady