We are happy to announce that Keptn is now officially available via the Glasskube Package Manager to bring Keptn
to even more users.
Installing packages for Kubernetes clusters is one of the most pressing issues in the Cloud Native community.
There are still some unaddressed challenges like managing dependencies and streamlining updates across multiple
packages.
In this article we give an overview about Glasskube, Keptn and how the installation works.
In the dynamic world of cloud-native and microservices, installation and continuous upgrades of distributed systems
is a priority.
Embarking on a journey into the world of containerized applications often leads us into a labyrinth of configuration
and deployment intricacies.
Amidst this complexity, Helm charts emerge as the guiding light, streamlining the orchestration of Kubernetes-based
applications.
In this article, we're delving into the topic of Helm charts, in particular Umbrella charts - an approach that
simplifies the deployment and maintenance of microservice application architectures.
Let's uncover how these consolidated charts pave the way for smoother deployments, enhance scalability, and bring
harmony to the orchestration of complex Kubernetes environments.
In the dynamic world of DevOps and continuous delivery, keeping applications reliable
and high-performing is a top priority.
Site reliability engineers (SREs) rely on Service Level Objectives (SLOs) to set the standards that the
Service Level Indicators (SLIs) of an application must meet, like response time, error rate,
or any other metric that might be relevant to the application.
The use of SLOs is not a new concept, but integrating them into an application comes with its own set of issues:
Figuring out which SLIs and SLOs to use— do you get the SLI values from one monitoring source or multiple?
This complexity makes it harder to use them effectively.
Defining SLO priorities.
Imagine a new version of a service that fixes a concurrency problem but
slows down response time.
In this case, this may be a valid trade-off and the new version should
not be denied due to an increase in the response time, given that the error rate will decrease.
Situations like these call for a way of defining a grading logic
where different priorities can be assigned to SLOs.
Defining and storing SLOs.
It's crucial to clearly define and store these goals in one central place,
ideally a declarative resource in a GitOps repository, where each change can be easily traced back.
In this article, we'll explore how Keptn tackles these challenges with its new Analysis feature.
We will deploy a demo application onto a Kubernetes cluster to show Keptn helps SREs gather
and make sense of SLOs, making the whole process more straightforward and efficient.
The example application will provide some metrics by itself by serving them via its Prometheus endpoint,
while other data will come from Dynatrace.