Keptn is meant to be installed into an existing Kubernetes cluster that runs your deployment software. See Requirements for information about supported releases and advice about resources required.
Create local Kubernetes cluster
You can also create a local cluster using packages such as KinD, k3d, k3s, and Minikube to set up a local, lightweight Kubernetes cluster where you can install Keptn for personal study, demonstrations, and testing. For more information, see the Kubernetes Install Tools documentation.
The Keptn Lifecycle Toolkit: Installation and KeptnTask Creation in Minutes video demonstrates how to create a KinD cluster. on which you can install Keptn. The basic steps are:
Download, install, and run Docker
Create the local KinD cluster with the following command:
kind create cluster
See the KinD Quick Start Guide for more information
When the cluster has been created, run the following to verify that the cluster is working and that it is running a supported version of Kubernetes with the following command:
kubectl version --short
Prepare your cluster for Keptn
Keptn installs into an existing Kubernetes cluster. When setting up a local Kubernetes cluster to study or demonstrate Keptn, you need to provide these components.
Your cluster should include the following:
A supported version of Kubernetes. See Supported Kubernetes versions for details.
If you want to use the standardized observability feature, you must have an OpenTelemetry collector and a Prometheus operator installed on your cluster.
If you want a dashboard for reviewing metrics and traces, install Grafana or the dashboard of your choice.
For traces, install Jaeger or a similar tool.
For more information, see Requirements for Open Telemetry.
Also note that Keptn includes a light-weight cert-manager that, by default, is installed as part of the Keptn software. If you are using another cert-manager in the cluster, you can configure Keptn to instead use your cert-manager. See Use Keptn with cert-manager.io for detailed instructions.
How many namespaces?
You have significant flexibility to decide how many namespaces to use and how to set them up. See the Kubernetes Namespace documentation for some basic information. You can also search and find lots of “Best Practices for Namespaces” documents published on the web.
Some considerations for Keptn:
- Keptn primarily operates on Kubernetes Workload resources and KeptnApp resources that are activated and defined by annotations to each Workload.
resources need to be located
in the same namespace as the associated
resources that are used for pre- and post-deployment
can reference metrics from any namespace.
So you can create
KeptnMetricsin a centralized namespace (such as
keptn-lifecycle-toolkit) and access those metrics in evaluations on all namespaces in the cluster.
KeptnAppresource identifies the namespace to which it belongs. If you configure multiple namespaces, you can have
KeptnAppresources with the same name in multiple namespaces without having them conflict.
- You do not need separate namespaces for separate versions of your application.
KeptnAppresource includes fields to define the
versionas well as a
revision(used if you have to rerun a deployment but want to retain the version number).
So, possible namespace designs run the gamut:
- Run all your Keptn work in a single namespace
- Create a separate namespace for each logical grouping of your Keptn work
- Create a separate namespace for each workload