Flow of deployment
Keptn deploys a Kubernetes Workload by passing through a well-defined execution flow.
The execution flow goes through six main phases:
Within each phase, all tasks and evaluations for each phase are executed in parallel. They are not affected by the order in which evaluations and tasks are listed in the KeptnApp resource or in the order of the pre/post-tasks and pre/post-evaluations that are listed in the Workflow manifests.
Kubernetes and Cloud Events
Keptn implements a Permit Scheduler Plugin that blocks the binding of the pods to a node until all the pre-conditions are fulfilled.
A Kubernetes deployment is started by the deployment engine that is implemented (such as Flux or Argo) or can be started by the following command:
Keptn does not care how a deployment manifest is applied to the cluster.
kubectl and Flux/Argo send the manifest to the Kubernetes API
so Keptn does not differentiate the actual deployment options.
This also means that one Keptn Application
can include services that are deployed with different methods.
The deployment is created
but the created pods are blocked and in pending state
until all the required pre-deployment tasks/evaluations
defined on either the
KeptnWorkload level pass.
Only then are the pods bound to a node and deployed.
If any pre-deployment evaluation or task fails,
KeptnApp issues an appropriate
and the deployment remains pending indefinitely,
until further changes or external intervention
either resolve the problem or terminate the execution.
If all evaluations and tasks in a phase are successful,
KeptnApp issues the appropriate
and initiates the next phase.
Summary of deployment flow
To view these events on your cluster, execute:
Note This only displays Kubernetes events, not Cloud Events.
Pre-deployment tasks can perform any kind of action needed to prepare for the deployment, including unit tests, load tests or other similar tests.
Pre-deployment evaluation phase
Pre-deployment evaluation can be used to assert the status of the cluster or of services the workload depends on, to assure it is deployed only if the specified prerequisites are met.
AppDeploy phase basically covers
the entire deployment and check phase of the workloads.
KeptnApp just observes whether
all pre and post-deployment tasks/evaluation are successful
and that the pods are deployed successfully.
When all activities are successful,
KeptnApp issues the
and continues to the next phase.
If any of these activities fail,
KeptnApp issues the
and terminates the deployment.
WorkloadPreDeployTasksSucceeded OR WorkloadPreDeployTasksErrored
WorkloadPreDeployEvaluationsSucceeded OR WorkloadPreDeployErrored
WorkloadDeploySucceeded OR WorkloadDeployErrored
WorkloadPostDeployTasksSucceeded OR WorkloadPostDeployTasksErrored
WorkloadPostDeployEvaluationsSucceeded OR WorkloadPostDeployEvaluationsErrored
AppDeploySucceeded OR AppDeployErrored
The post-deployment phase is typically used to run tests on the freshly deployed application, such as gathering performance data.
Post-deployment evaluation phase
The post-deployment evaluation can be used to analyze the cluster/application status after the new workload is deployed. The result of this phase does not revert or influence the deployment but can be used by other external tools, for instance, to react to a failure.
Events that are generated asynchronously
Additional phases/states exist, such as those that describe what is currently happening in the system. During the lifetime of the application, custom resources are created, updated, deleted or reconciled. Each reconciliation, or re-evaluation of the state of custom resources by the controller, can cause the generation of events. These include: