Keptn 0.7 improves the core use cases of continuous delivery and automated operations by providing enhanced stage control in the delivery workflow and by allowing the integration of custom remediation (aka. action) providers. Internally, Keptn has been hardened by restricting its permissions to the set of required ones, and it does not install Istio nor NGINX during the setup process.
The six key announcements of Keptn 0.7:
🚀 Delivery Assistant - SPEC 26: To better support the continuous delivery workflow of production-like use cases, Keptn 0.7 introduces the concept of manual deployment approvals for certain stages and it improves stage visibility in the Keptn Bridge.
🌟 Continuous Delivery with Helm 3 (instead of Helm 2): Keptn 0.7 moves away from using Helm 2 for deploying services; instead Helm 3 is used. As a result, Tiller - a core component of Helm 2 - is gone.
✨ Closed-loop Remediation with custom Integration - KEP 09 | SPEC 31: Keptn 0.7 lifts the automation of remediation workflows and the integration of custom remediation (aka. action) providers to the next level. A level where multiple remediation actions per problem type can be configured and the effect of each remediation action is validated based on the SLO/SLI validation Keptn offers. Consequently, fast feedback on executed remediation actions is given, providing better visibility into entire remediation scenarios. Please find a detailed blog post about this use case here.
🎉 Improved automation support with API extensions - KEP 10: Keptn 0.7 brings internally-used API endpoints to the Keptn public API. Thus, read operations as implemented in GET endpoints are publicly available and can be leveraged to get status information for projects, stages, and services.
🔒 Hardening of Keptn: The hardened of Keptn 0.7 in terms of its permissions on a K8s cluster has been improved by defining the role-based access control (RBAC) of each service.
⭐ Removed Istio and NGINX - KEP 18: Keptn 0.7 does not install Istio nor an NGNIX Ingress controller during the Keptn install process. Instead, the default Kubernetes service types NodePort or LoadBalancer are used for exposing Keptn to an external IP. In case, the Kubernetes service types ClusterIP is chosen, it is required to manually install an Ingress or to go with port-forwarding to access the Keptn API/Bridge; documentation is provided here.
Last but not least, many thanks to the community for the rich discussions around Keptn 0.7, the submitted Keptn Enhancement Proposals, and the implementation work!
Upgrade from 0.6.2 to 0.7:Keptn 0.7 uses Helm 3 while previous Keptn releases rely on Helm 2. To upgrade your Helm releases from Helm 2 to 3, two options are provided:
Job without Helm 3 Upgrade: This option is needed when the cluster contains Helm releases not managed by Keptn. If this job is executed, it is necessary to manually convert the releases from Helm 2 to 3 as explained on keptn.sh/docs.
Job with Helm 3 Upgrade: Full automation of Helm upgrade for installations were just Keptn is installed. If this job is executed, all Helm releases on the cluster are converted from Helm 2 to 3 and Tiller will be removed.