Writing Your Own Custom Playbook Action in Robusta
As we discussed in the first installment, Troubleshooting Kubernetes environments is complex. However, with Robusta on Kind, Troubleshooting Kubernetes is made much easier.
Introduction to Robusta
Robusta is a platform for monitoring and remediation that offers insightful information into Kubernetes clusters and integrates with a variety of monitoring and alerting tools.
It sits on top of your monitoring stacks, such as Prometheus or Elasticsearch, and explains why and how to fix alerts.
Robusta automates all processes that take place after your application is deployed. It’s similar to Zapier/IFTTT for DevOps, focusing on prebuilt automation rather than “build your own.”
How Robusta Automation Works
The division of YAML-defined automation into triggers, actions, and sinks simplifies things conceptually. This distinct division may lessen the entry barrier, particularly if you’re looking for accessible locations to start integrating your tooling.
Every automation consists of 3 distinct steps
Triggers
Simply put, a trigger represents a specific situation that initiates a response.
Example triggers
- on_pod_create
- on_deployment_create
- on_pod_update
- on_deployment_update
- on_pod_delete
Action-trigger Compatibility:
Now we need to understand how triggers are bound to actions.
There are two types of actions in robusta.
- Simple actions.
- Resource-related actions.
Simple Actions:
Simple actions require no particular parameters (as shown in figure A below) and can therefore be executed in response to any trigger. Eg:
This action checks network connectivity in your cluster using ping. Pings a hostname from within the cluster. So we do not need to give any Kubernetes resources to this action.
Resource-related Actions:
These actions require Kubernetes resources as input.
For example, a pod is required as input for the logs_enricher action.
As a result, logs_enricher can only be linked to triggers that output a pod. As an example, Figure B shows resource-related actions:
These actions can provide context for any pod-related event, such as on Prometheus alert or pod update.
Sinks:
Playbook results (findings) can be sent to one or more sinks (destinations).
The following sinks are supported:
- Robusta UI
- Slack
- MS Teams
Sending Findings to Specific Sinks:
You can set up a sink to only accept particular findings. For example, depending on the namespace, you can send notifications to multiple Slack channels, Figure C shows add findings in the values file:
Events and Triggers:
Events are Robusta objects that hold information on a particular resource in your cluster. When configuring Robusta as a user, triggers are defined in YAML ( generated_values.yaml ), but events are dealt with while writing playbook actions.
The basic concept is that triggers create event objects, which are then passed to action functions. Below is Figure D illustrates the lifecycle of robusta events.
Compatibility of Actions and Events
Let’s examine this from the viewpoint of a developer creating a Python playbook action.
By selecting the first parameter of your playbook’s Python function, you can specify which events your playbook is compatible with. As shown in Figure E below.
Since no other trigger can generate the event object for the above action because it requires PrometheusKubernetesAlert as input, it can only be connected to an on_prometheus_alert trigger.
However, since it doesn’t do anything with the alert itself, this action doesn’t really require a Prometheus alert as input. This action can be changed to take a PodEvent as input. As shown in Figure F below.
PrometheusKubernetesAlert is a subclass of PodEvent.Therefore, general object-oriented principles are applicable here. So, wherever a PodEvent is anticipated, PrometheusKubernetesAlert can be used.
Here is the illustration of the robusta event hierarchy for Prometheus in Figure G:
The Robusta triggers are arranged in a hierarchy. If a particular trigger is supported by action, all descendants of that trigger are also supported.
Writing Our First Playbook Action
Creating Your Own Playbook Repository
A playbook repository consists of the following directory structure as shown in Figure H below:
As an example, consider the following pyproject.toml in Figure I:
Note: The name of the inner playbooks directory must match the package name in your pyproject.toml file.
List any additional Python dependencies that your playbook needs in your pyproject.toml file. They’ll be installed by Robusta.
Write a Playbook Action in Python:
let’s take an example of a Python playbook action in Figure J
You must package the code as a playbook repository and import it into Robusta. It’s time to load our playbook action.
Loading Playbook Repository
You have two options for loading your playbook:
- From a git repository
- Using robusta playbooks push
From a Git Repository:
- Git playbook loading via HTTPS
You can load your playbook action from the Git repository via HTTPS as shown in Figure K below:
- Git playbook loading via SSH
You can also load your playbook action from the Git repository via SSH as shown in Figure L below:
Using Robusta Playbooks Push:
In the Robusta configuration file, first allow persistent playbooks storage by setting the helm value as shown in figure M below.
Once your repository is loaded, use the Robusta CLI and run the below command:
This mounts a persistent volume on the Robusta runner at /etc/robusta/playbooks/storage and copies the repository to it. Now that the actions in the repository are loaded, they can be used.
Using Your Custom Playbook Action
You can use your action once the playbook package has been loaded.
(generated_values.yaml). Below is Figure N showing how you can add a custom action in the Robusta configuration file.
The action above receives a PodEvent. As a result, it can be used for pod-related triggers.
Conclusion
This blog delved into the workings of robusta custom playbook action, which forms an integral part of the infrastructure-as-code solution for monitoring and maintaining K8s applications, along with alert management. Just as Docker is a platform for deploying applications using infrastructure-as-code principles, Robusta applies the same approach to Kubernetes observability, enabling easier analysis of events and enabling actions to be taken more efficiently. With its capability to correlate events, Robusta simplifies the process of enhancing Kubernetes observability, reliability and streamlines the overall management of K8s applications.
We welcome your insightful comments and suggestions. Please share your thoughts in the section provided below if you found the blog useful. Furthermore, we’d like to know how useful Robusta was for you. More tutorials that explore Robust further will be released in the future!
Related Articles
Related Articles
Established in 2012, Xgrid has a history of delivering a wide range of intelligent and secure cloud infrastructure, user interface and user experience solutions. Our strength lies in our team and its ability to deliver end-to-end solutions using cutting edge technologies.
OFFICE ADDRESS
US Address:
Plug and Play Tech Center, 440 N Wolfe Rd, Sunnyvale, CA 94085
Pakistan Address:
Xgrid Solutions (Private) Limited, Bldg 96, GCC-11, Civic Center, Gulberg Greens, Islamabad
Xgrid Solutions (Pvt) Ltd, Daftarkhwan (One), Building #254/1, Sector G, Phase 5, DHA, Lahore
Xgrid © 2024. All rights reserved.