KeptnApp and KeptnWorkload resources
In its state, it tracks the currently active
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 a
PostDeploymentCheck can be triggered.
KeptnWorkload resources are created automatically
and without delay by the mutating webhook
as soon as the workload manifest is applied.
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
with annotations or labels that are applied to each
plus specific tasks and evaluations that you define
KeptnApp resource itself:
- The annotations described in
are used to automatically generate
KeptnAppresources that contain the identifications required to run the Keptn observability features.
- You must create a
KeptnAppContextresource that has the same name and namespace of your
KeptnAppto define the evaluations and tasks you want to run pre-/post-deployment. For more information check how to create tasks and how to create evaluations.
KeptnApp resources are generated automatically and
contain the identifications required to run the Keptn observability features.
spec.workloads.name and a
are also generated automatically as long as all the workloads you want in your app
are correctly annotated. (See basic annotations)
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
keptnAppCreationRequestTimeoutSeconds field in the
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.
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,
keptn.sh keys take precedence over
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
resources that are used for observability,
based on whether the
annotation/label is populated:
If either of these labels/annotations are populated, Keptn automatically generates a
KeptnAppresource that includes all workloads that have the same annotation/label, thus creating a
KeptnAppresource for each defined grouping
If only the
versionannotations/labels are available (in other words, neither the
app.kubernetes.io/part-ofannotation/label is populated), one
KeptnAppresource is created automatically for each workload.