keptn is a control plane for continuous delivery that runs on Kubernetes. It’s built on Knative and uses a publish-subscribe pattern to forward events, like when a new container has been pushed to an artifact registry, to one or a number of Knative services that react to that event. To continue the continuous delivery workflow those services need to send an event to keptn. The events that keptn understands are documented here. All keptn events follow the cloudevents specification v2.

keptn architecture

keptn has a number of core components that are set up during the installation of keptn. Istio and Knative are prerequisites. The CLI 1️⃣ needs to be installed on the local machine and is used to send commands to keptn. To communicate with keptn you need to know a shared secret that is generated during the installation and verified in the authentication component 2️⃣ . On the server side, the control component 3️⃣ receives the commands from the CLI and executes the requested task. To that end, it mostly uses other internal services or forwards event to the internal event broker 4️⃣ .

External tools can communicate with keptn through the external eventbroker component 5️⃣ . Again, the external tool and keptn must share a secret to validate the authenticity of an event. For example, when a new container has been pushed to an artifact registry you usually can configure webhooks to notify others about that event. The external eventbroker understands a number of external events, transforms them to keptn events and forwards them to the internal eventbroker using an internal channel.

Tools and components that run in the Kubernetes cluster can communicate with keptn using the internal eventbroker. The internal eventbroker receives keptn events and forwards those events to the appropriate channels 6️⃣ , based on the event type. Each channel can have a number of subscribers 7️⃣ that receive the event and can react to it. Subscribers are implemented with Knative services. Either the service executes a task as a reaction to the received event or it again transforms and forwards the event to a third party component 8️⃣ that then executes a task. Either way, after the task is done, a new event must be sent to keptn to continue the continuous delivery workflow.