Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docs: add KeptnApp reference in getting started #2202

Merged
merged 6 commits into from
Oct 4, 2023
Merged
Changes from 5 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
113 changes: 109 additions & 4 deletions docs/content/en/docs/getting-started/_index.md
Original file line number Diff line number Diff line change
Expand Up @@ -469,11 +469,116 @@ View the Keptn Applications Dashboard and you should see the DORA metrics and an

## Step 14: More control over KeptnApp

You may have noticed that the `KeptnApp` Custom Resources are created automatically by Keptn.
To customize workloads and checks associated with the application, we can edit the autogenerated KeptnApp or create our own.

```yaml
apiVersion: lifecycle.keptn.sh/v1alpha3
kind: KeptnApp
metadata:
name: <app-name>
namespace: <app-namespace>
spec:
version: "x.y"
revision: x
workloads:
- name: <workload1-name>
version: <version-string>
- name: <workload2-name>
version: <version-string>
preDeploymentTasks:
- <list of tasks>
postDeploymentTasks:
- <list of tasks>
preDeploymentEvaluations:
- <list of evaluations>
postDeploymentEvaluations:
- <list of evaluations>
```

## Fields

- **apiVersion** -- API version being used.
- **kind** -- Resource type.
Must be set to `KeptnApp`

- **metadata**
- **name** -- Unique name of this application.
Names must comply with the
[Kubernetes Object Names and IDs](https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#dns-subdomain-names)
specification.

- **spec**
- **version** -- version of the Keptn application.
Changing this version number causes a new execution
of all application-level checks
- **revision** -- revision of a `version`.
The value is an integer that can be modified
to trigger another deployment of a `KeptnApp` of the same version.
For example, increment this number to restart a `KeptnApp` version
that failed to deploy, perhaps because a
`preDeploymentEvaluation` or `preDeploymentTask` failed.
See
[Restart an Application Deployment](../implementing/restart-application-deployment/)
for a longer discussion of this.
- **workloads**
- **name** - name of this Kubernetes
[workload](https://kubernetes.io/docs/concepts/workloads/).
Use the same naming rules listed above for the application name.
Provide one entry for each workload
associated with this Keptn application.
- **version** -- version number for this workload.
Changing this number causes a new execution
of checks for this workload only,
not the entire application.

The remaining fields are required only when implementing
the release lifecycle management feature.
If used, these fields must be populated manually:

- **preDeploymentTasks** -- list each task
to be run as part of the pre-deployment stage.
Task names must match the value of the `metadata.name` field
for the associated [KeptnTaskDefinition](taskdefinition.md) resource.
- **postDeploymentTasks** -- list each task
to be run as part of the post-deployment stage.
Task names must match the value of the `metadata.name` field
for the associated
[KeptnTaskDefinition](taskdefinition.md)
resource.
- **preDeploymentEvaluations** -- list each evaluation to be run
as part of the pre-deployment stage.
Evaluation names must match the value of the `metadata.name` field
for the associated
[KeptnEvaluationDefinition](evaluationdefinition.md)
resource.
- **postDeploymentEvaluations** -- list each evaluation to be run
as part of the post-deployment stage.
Evaluation names must match the value of the `metadata.name` field
for the associated [KeptnEvaluationDefinition](evaluationdefinition.md)
odubajDT marked this conversation as resolved.
Show resolved Hide resolved
resource.

## Example

The lifecycle toolkit automatically groups workloads into `KeptnApp`s by looking for matching
`app.kubernetes.io/part-of` annotations.
Any workloads with the same `part-of` annotation are said to be `part-of` the same `KeptnApp`.
```yaml
apiVersion: lifecycle.keptn.sh/v1alpha3
kind: KeptnApp
metadata:
name: podtato-head
namespace: podtato-kubectl
spec:
version: "latest"
workloads:
- name: podtato-head-left-arm
version: "my_vers12.5"
- name: podtato-head-left-leg
version: "my_v24"
postDeploymentTasks:
- post-deployment-hello
preDeploymentEvaluations:
- my-prometheus-definition
```

You may have noticed that the `KeptnApp` Custom Resources are created automatically by Keptn.

However, you can override this automatic behaviour by creating a custom `KeptnApp` CRD.
In this way, you are in full control of what constitutes a Keptn Application.
Expand Down
Loading