The latest release of Keptn is an exciting milestone for our team and growing Keptn community. Keptn is an open source reference implementation of continuous software delivery and automated operations for modern cloud-native applications. Below are six highlights from the 0.5.0 release with an explanation of why we made the changes so that you can get inspired to try them yourself.
#1 Reduce MTTR with new “Self-healing” capabilities
Keptn has significantly improved the self-healing capability by providing the means to define automated remediation steps to execute when certain service level objectives are violated. The diagram below shows the high level concept of “Evaluate, Decide, and Act” behind this new service.
This initial self-healing service supports a single use case based on Prometheus alerting for high CPU that triggers the automatic scale up the pods of an application. The actions and are defined using new the ‘remediation.yaml’ specification file described in highlight #2 below.
Automated run-books is all about improve Mean Time to Remediation (MTTR). You can read more about this initial use case in the Keptn docs and stay tuned for upcoming Keptn releases that will expand the support for remediations and problem alerting sources.
#2 Increase quality with New Site Reliability Engineering (SRE) specifications
For the new Keptn release, we have implemented a new services specification for quality gates and automated remediation that follow Google’s definitions for service level indicators and objectives as described in their SRE eBook:
- service level indicator (SLI): a carefully defined quantitative measure of some aspect of the level of service that is provided
- service level objective (SLO): a target value or range of values for a service level that is measured by an SLI
Previously Keptn used a single performance specification or “perfspec” file in JSON format that contained all the indicators or metrics to gather and their corresponding objectives. Going forward, there will be multiple files in YAML format that we believe will allow teams to standardize and define centrally shared indicator measurements, simply service objective definitions, and establish a more scalable and flexible specification for future enhancements.
Below is a summary of the new specification files:
- The ‘service-indicators.yaml’ file specifies the indicators that can be used to describe service objectives. These indicators are metrics gathered from monitoring sources and they are defined by a query. The query to obtain the metric is source-specific.
- The ‘service-objectives.yaml’ file specifies the service level objectives for one or more services. Therefore, this file first defines thresholds that express the fulfillment of the objectives in the pass and warning property.
- The ‘remediation.yaml’ file defines remediation actions to execute in response to a problem related to the defined problem pattern / service objective. This action is interpreted by Keptn to trigger the proper remediation.
We have already seen the benefits for encoded objectives combined into automated quality gates and we are excited in our continued improvements in this area.
NOTE: These changes mean there is a breaking change to the Keptn 0.4.0 and prior release “perfspec” files as well as the Keptn Pitometer service, so please review the new specification files here.#3 Integrate Keptn into your eco-system with the new API
This release introduces a Keptn API that can be used to send any type of event via a secured REST endpoint. With this new API, Keptn can be integrated into existing toolchains and workflows to trigger a new deployment/release rather than using the Keptn CLI.
Keptn 0.5.0 API provides the following services:
- Keptn API token authorization
- Send a Keptn event such as a service image configuring change event
- Onboard a project
- Onboard a project service
- Add and update service resources
Once you install Keptn, visit the Swagger web UI to review API endpoints and payload data models using this URL for your cluster:
https://api.keptn.<YOUR CLUSTER>/swagger-ui/#/The Keptn API does not replace the Keptn CLI. The Keptn CLI is still required to install Keptn and can run all the same tasks as the Keptn API. Internally, the Keptn CLI calls the Keptn API. The Keptn API interacts with the keptn event-broker service that is a conduit for task execution by the various Keptn services. These relationships are shown in this portion of the Keptn architecture diagram below.
#4 Extended Kubernetes Support
Keptn 0.5.0 brings coverage to all major platforms with the inclusion of Amazon Elastic Kubernetes Service (EKS) and Pivotal Container Service (PKS) on Google Cloud. So whether you are running EKS or PKS, Azure Kubernetes Service (AKS), Google Kubernetes Engine (GKE), OpenShift 3.11 or Native Kubernetes, Keptn has you covered!
#5 Extended Git support
In previous Keptn releases, it was required for Keptn to integrate with an external GitHub repository. In 0.5.0, Keptn stores these project configuration and resources files within a single self-hosted git repository resident in the Keptn cluster. This means that one can now try out Keptn without needing to have a GitHub account and repos.
In order to get resource files into this self-hosted git repository, the Keptn CLI was enhanced with a new “add-resource” command. Below is the structure for this new command.
keptn add-resource --project=PROJECT --stage=STAGE --service=SERVICE --resource=FILEPATH --resourceUri=FILEPATHAs to allow these files to be managed external to this self-hosted git repository, Keptn 0.5.0 provides the option to configure an “upstream” git repositories hosted on GitHub, GitLab or Bitbucket that is synchronized with this internal repository. This feature broadens the git platform support beyond GitHub and will allow for future “upstream” repository support.
Learn more about the configuration service that manages the resources here and how to configure upstream git repositories here.
#6 Improved Web UI
Based on community feedback, the release introduces a refreshed web UI called the Keptn’s Bridge. The Bridge gives users a comprehensive overview of events that occur during the deployments, testing and self healing of services managed by Keptn. Each stage of a pipeline now has standardized context information and the expandable details for an event as shown below.
Behind the scenes, a database was added for persistence of Keptn event and log data. The Keptn’s Bridge is installed as part of Keptn core services and in upcoming releases will continue to be enhanced with more features.
Learn more about the Keptn’s Bridge here.
How to get started
These six enhancements bring us closer to having an Enterprise-grade event-based framework for shipping and operating cloud-native applications on any Kubernetes cluster. So please follow this link to try out Keptn today!
