Home / Keptn v1 Docs / News / Release Announcements / Keptn 0.8.0
Keptn 0.8 improves the core use cases of continuous delivery and automated operations by implementing the new Shipyard version v0.2. This new Shipyard version has been proposed and refined in KEP 06.
Key announcements:
🚀 Separated and explicit Shipyard-defined processes (aka. task sequences) for continuous delivery / automated remediation: With this Keptn release, it is possible to have multiple processes (called task sequences) within one stage. These task sequences are separated from each other and list the tasks that are triggered sequentially.
🎉 Support individual tasks in sequences: It is now possible to add custom tasks to a task sequence to address needs of delivery/remediation use-cases that go beyond the opinionated approach Keptn is offering.
⭐ Trigger of a sequence can be configured - allowing multiple parallel stages: The new Shipyard supports the definition of triggers that launch the execution of a task sequences. This helps to make it explicit when a sequence gets triggers. Besides, this linking mechanism allows connecting multiple sequences (of different stages) to listen to the same trigger. Consequently, it is possible to connect multiple stages, which are on the same level, to one preceding stage.
🌟 New types of events: In course of implement the new Shipyard version in Keptn, the Keptn Cloud-events were streamlined and follow now a common pattern. Basically, Keptn just sends out an event of type: sh.keptn.event.{task.name}.triggered
and other services react on:
sh.keptn.event.{task.name}.triggered
> sent out by Keptnsh.keptn.event.{task.name}.started
> sent out by a Keptn-service when starting the taskssh.keptn.event.{task.name}.status.changed
> sent out by a Keptn-service to inform about a status updatesh.keptn.event.{task.name}.finished
> sent out by a Keptn-service when the task is finished✨ Multi-cluster support: Based on the implementation of Shipyard v0.2, Keptn - as a control-plane for delivery and remediation - is now capable of serving multiple clusters. This is known as the split between Control plane and Execution plane. For this use-case, the Keptn project offers to run the helm-service (to deploy) and jmeter-service (to test) on the Execution plane. This Execution plane can be on a cluster other than the cluster where Keptn is installed.
💫 Sequence screen in Keptn Bridge: The new capabilities of Keptn for dealing with task sequences received a dedicated screen in the Keptn Bridge. This screen provides filtering capabilities and a stage-divided view on the performed delivery or remediation tasks.
Screenshot here
Supporting features:
🎉 Query usage statistics of your Keptn: With this release, it is possible to retrieve usage statistics of a Keptn by using the /api/statistics/v1
endpoint. This returns the number of events processed in the specified time frame.
🌟 Keptn CLI supports multiple Keptn installations: The new Keptn CLI easies working with multiple Keptns since it recognizes switches between Kubernetes clusters and then asks for switching the context Keptn context too. Consequently, your CLI will be automatically connected to the Keptn running on another K8s cluster.
⭐ Deployment of custom Helm Charts: An extension of the helm-service allows to deploy custom Helm Charts meaning that the Helm Chart can contain any custom resource and is not limited to a Kubernetes service and deployment. Note: When using this option, the automatic rollback capability of Keptn is not supported and the Helm Chart is not under control by Keptn. Consequently, this feature is currently marked as experimental.
✨ SLI breakdown displayed as a table in Keptn Bridge: For the quality gates capabilities of Keptn, the SLI breakdown is now displayed as a table given a better overview of the individual results.
Noteworthy changes and improvements:
Last but not least, many thanks to the community for the rich discussions around Keptn 0.8, the submitted Keptn Enhancement Proposals, and the implementation work!
Implemented Keptn spec version: 0.2.0
/api/controlPlane/v1
/api/configuration-service/v1
/api/controlPlane/v1/project
/api/controlPlane/v1/stage
/api/controlPlane/v1/service
/api/v1/project/{project}/stage/{stage}/service/{service}/evaluation
/api/mongodb-datastore/event
keptn send event start-evaluation
to trigger an evaluation has been marked as deprecated. Use keptn trigger evaluation
instead:
keptn trigger evaluation --project=my-sockshop --service=foobar --stage=hardening
keptn send event new-artifact
to send a configuration change that triggers a delivery of a new artifact has been marked as deprecated. Use kept trigger delivery
instead:
keptn trigger delivery --project=sockshop --service=carts-db --image=docker.io/mongo --tag=4.2.2 --sequence=delivery-direct
The Service screen does not show the Keptn CloudEvents anymore since this information has moved to the new Sequence screen.
The old deep links still work but are adapted to the new screens as described here
keptn install
hangs in case of ImagePullBackOff 2988/service
endpoint 3195/service
endpoint 2754/project
endpoint 2804/api/v1/metadata
returns null during K8s api downtime 2870keptn --help
Continue working with current Keptn context and remove Keptn context switch from 2721keptn create service
| onboard service
| delete service
- adapt CLI commands to use endpoint of the shipyard-controller 2557keptn create project
- support for creating a project using the new shipyard spec 2266keptn get event
- allow polling Keptn Cloud-events (e.g., by cloud-event-id) 2572keptn get event
- ensure compatibility with new cloud-events (e.g., evaluation.finished instead of evaluation-done) 2873keptn get project
- display shipyard version 2908keptn generate cloud-events-spec
- new command for generating Keptn Cloud-events specification 2926keptn install --help
- improved install message 2584keptn send event new-artifact
- adapt CLI command to CloudEvents spec of 0.8.0 2558keptn upgrade
- better instructions on how to download new CLI version 2560keptn upgrade
- avoid the version check via a flag 2689keptn upgrade project
- upgrader for migrating from Shipyard v0.1 to Shipyard v0.2 2500keptn version
- re-add the version check into the root command 2571api-gateway-nginx:
configuration-service:
distributor:
*.triggered
events 2166eventbroker:
gatekeeper-service –> approval-service:
helm-service:
deployment_strategy: user_managed
that allows to deploy custom Helm charts 2764release.triggered
and sends release.started/finished
event 2265deployment.triggered
and sends deployment.started/finished
event 2262jmeter-service:
lighthouse-service:
mongodb-datastore:
evaluation.invalidated
events 3270evaluation-done
events used in Keptn < 0.8 2949triggeredid
in input 2514remediation-service
shipyard-controller:
triggeredid
to finished event for a sequence 3329data.message
property from previous .finished
event before sending next .triggered
event 3043result=fail
3027*.started
events in a MongoDB collection per project 2159*.triggered
events in a MongoDB collection per project 2158.triggered
event is available for a .started/.finished
event 2956.triggered
event 2816statistics-service:
evaluation.finished
events (instead of evaluation-done
) 2866sh.keptn.event.[stage].[sequence].finished
2534helm-service
and jmeter-service
on execution plane on a separate cluster/namespace 3418keptn create project
with --shipyard
pointing to an URL does not properly work 2511add-path
command is disabled 2694This section lists bugs and limitations that are known but not fixed in this release. They will get addressed in one of the next releases.
approval.triggered
events in the Bridge leads to a scroll-up / jump-up in Firefox #2369sh.keptn.event.service.delete.finished
event from helm-service 2989
sh.keptn.event.service.delete.finished
events when running on the execution plane. This leads in the limitation that deleting deployed services on the execution plan becomes a manual task. To delete a deployed service, execute:
helm ls -n <NAMESPACE>
helm delete <HELM_RELEASE> -n <NAMESPACE>