KeptnApp and KeptnWorkload resources

How Keptn applications work

Keptn Workloads

A KeptnWorkload resource augments a Kubernetes Workload with the ability to handle extra phases. It can execute the pre/ post-deployment evaluations of a Workload and run pre/ post-deployment tasks.

In its state, it tracks the currently active Workload Instances, (Pod, DaemonSet, StatefulSet, and ReplicaSet resources), as well as the overall state of the Pre Deployment phase, which Keptn can use to determine whether the pods belonging to a workload should be created and assigned to a node. When it detects that the referenced object has reached its desired state (e.g. all pods of a deployment are up and running), it knows that aPostDeploymentCheck can be triggered.

The KeptnWorkload resources are created automatically and without delay by the mutating webhook as soon as the workload manifest is applied.

Keptn Applications

A KeptnApp resource combines multiple Kubernetes workloads into a single entity that represent the application that is published. Note that the Kubernetes documentation often refers to workloads as applications, but each workload actually corresponds to one version of one deployable microservice, not the amalgamation of multiple microservices that typically comprise the released software.

Implementing Keptn applications provides the following benefits:

  • Observability tools report on the deployment of all workloads together rather than individually.
  • You can define pre-deployment evaluations and tasks that must all complete successfully before the scheduler creates the pods for any of the workloads.
  • You can define post-deployment evaluations and tasks that run only after all the workloads have completed successfully.

You control the content of a KeptnApp resource with annotations or labels that are applied to each Workload (Deployments, StatefulSets, and DaemonSets plus specific tasks and evaluations that you define for the KeptnApp resource itself:

  • The annotations described in Basic annotations are used to automatically generate KeptnApp resources that contain the identifications required to run the Keptn observability features.
  • You must manually add the annotations described in Annotations to KeptnApp to the basic KeptnApp manifest to define the evaluations and tasks you want to run pre/post-deployment.

The KeptnApp resources that are generated automatically contain the identifications required to run the Keptn observability features. The spec.workloads.name and a spec.workloads.version fields that define evaluations and tasks to be run pre- and post-deployment are not generated automatically but must be input manually.

By default, the KeptnApp resources are updated every 30 seconds when any of the Workloads have been modified; The timeout is provided because it may take some time to apply all KeptnWorkload resources to the cluster. This interval can be modified for the cluster by changing the value of the keptnAppCreationRequestTimeoutSeconds field in the KeptnConfig resource.

How basic annotations are implemented

The Basic annotations page gives instructions for applying the annotations or labels that identify the pods that Keptn should manage.

Three keptn.sh and three app.kubernetes.io keys are recognized. They are equivalent; you can use either of them and they can be implemented as either annotations or labels. Annotations take precedence over labels, and the keptn.sh keys take precedence over app.kubernetes.io keys. In other words:

  • The operator first checks if the keptn.sh/ key is present in the annotations, and then in the labels.
  • If neither is the case, it looks for the app.kubernetes.io/ equivalent, again first in the annotations, then in the labels.

Keptn automatically generates appropriate KeptnApp resources that are used for observability, based on whether the keptn.sh/app or app.kubernetes.io/part-of annotation/label is populated: resource for each defined group. that together constitute a single deployable Keptn Application.

  • If either of these labels/annotations are populated, Keptn automatically generates a KeptnApp resource that includes all workloads that have the same annotation/label, thus creating a KeptnApp resource for each defined grouping

  • If only the workload and version annotations/labels are available (in other words, neither the keptn.sh/app or app.kubernetes.io/part-of annotation/label is populated), one KeptnApp resource is created automatically for each workload.