Sayan MondalHave you ever had the need to execute, monitor and manage all your services in one place with minimal effort! Sounds like a dream isn't it! Well not for long. With the upcoming Litmus 2.0 we're excited to try out some groundbreaking features like GitOps, Enhanced Teaming, Workflow Visualization, Workflow Sequence Editing, adding custom templates and so much more.
Before starting this blog, do check out the previous blog on running Chaos Engineering Tests with LitmusChaos on Civo: https://www.civo.com/learn/chaos-engineering-kubernetes-litmus
In this blog, we’re going to explore how to use Civo’s amazingly fast managed k3s clusters to pick LitmusChaos app from the Civo Marketplace and set it up with no more than two clicks.
Find the technical demo with Litmus 2.0 on Civo here:
What is CIVO Cloud?
Civo is a cloud hosting platform powered by k3s which helps cloud-native developers manage and build their Kubernetes-native applications easily. The powerful k3s distribution helps you bring up a cluster in just a couple of minutes. Developers can now sign-up for Civo’s Early Launch Access as Civo comes out of their beta program, #KUBE100.
Loaded with features and with considerable focus on simplicity, speed & value for money, Civo allows agile Kubernetes development and hosts various Open Source Cloud-Native projects in its marketplace to induce various functionalities according to your needs.
One of them is LitmusChaos which can be found in the CI/CD section of the marketplace.
LitmusChaos 2.0 Advanced Beta is out!
Litmus is a toolset to do cloud-native chaos engineering. Litmus provides tools to orchestrate chaos on Kubernetes to help SREs find weaknesses in their deployments. SREs use Litmus to run chaos experiments initially in the staging environment and eventually in production to find bugs, vulnerabilities. Fixing the weaknesses leads to increased resilience of the system. Litmus takes a cloud-native approach to create, manage and monitor chaos.
With the launch of Litmus Chaos 2.0 Advanced Beta, a new way of chaos engineering can be performed by the users, capturing a few high-level features. A detailed list can be found on the release page
- Chaos experiments become building blocks of a ChaosWorkflow, to allow users to create a larger chaos scenario using sequential or parallel experiment execution.
- A cross-cloud control plane has been built which can be used to
- Predefined workflow for easy onboarding.
- Construct a custom workflow from a UI interface for both parallel and sequential workflow from both public or private hub.
- Orchestrate chaos workflow across K8S agents(clusters) from a single control plane.
- Centrally visualize the chaos workflows, get chaos analytics and compare the same.
- Get the teaming in place for collaboration of chaos workflows.
- Agents can work in namespace scope or cluster scope.
- Chaos workflow can be stored in Git
- Chaos GitOps for highly scalable automation of chaos workflows. Chaos can now be triggered as a result of a change to an application. This integrates with other CD tools like ArgoCD and FluxCD
- Chaos Interleaved dashboards. A step toward open observability that is interleaved with chaos incident details.
Litmus itself is composed of microservices. And we made sure that by adding the above features for 2.0, seamlessly integrates the additional microservices in conjunction with the existing one. Litmus 2.0 is completely backwards compatible. No features are deprecated. The migration path is about constructing new artifacts such as ChaosWorkflows that include the current chaos experiments in use by the users.
Prerequisites
- A Kubernetes cluster you control. We'll take advantage of Civo's super-fast managed k3s service to experiment with this quickly. If you don't yet have an account, sign up to join Civo Cloud now as it is production ready & open for business. Join Civo as its early access launch comes out on the 4th of May!
Alternatively, you could also use any other Kubernetes cluster.
-
kubectl installed, and thekubeconfigfile for your cluster downloaded.
Installing Litmus 2.0 Beta on Civo
To ensure Litmus runs perfectly in sync with your cluster, make sure you have installed Helm from the Civo marketplace along with Litmus since Litmus 2.0 is dependent on Helm for pulling the updated chaos charts.
Once you click on Create all you have to do is sit back and relax for 80 seconds while Civo creates the cluster at jet speed. Once installed and you can verify if litmus is up and running in your system by viewing the pods.
$kubectl get pods -n litmus
NAME READY STATUS RESTARTS AGE
chaos-litmus-2-0-0-beta-frontend-7b76655b6b-s9989 1/1 Running 0 72m
chaos-litmus-2-0-0-beta-mongo-0 1/1 Running 0 72m
chaos-litmus-2-0-0-beta-server-bc884dcc7-v6bwj 2/2 Running 1 72m
You should be able to view the front end, server as well as mongo pod successfully running in your cluster.
Accessing the Litmus Control Plane
To set up and log in to Litmus Portal expand the available services just created and copy the PORT of the frontend service.
$kubectl get svc -n litmus
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
litmusportal-frontend-service NodePort 10.43.24.252 <none> 9091:31054/TCP 81m
chaos-litmus-2-0-0-beta-mongo ClusterIP 10.43.223.208 <none> 27017/TCP 81m
litmusportal-server-service NodePort 10.43.167.201 <none> 9002:32678/TCP,9003:31672/TCP 81m
From this example, we can note that the frontend port is 31054 but it’s dynamic and will be different in your case.
Once you have the PORT copied in your clipboard, simply use your NodeIP and PORT in this manner <NodeIP>:<PORT> to access the portal. To get the NodeIP of the Civo cluster in this case, visit the UI and pick up the IP of the master node from the Nodes section.
So in this case, since my master node is 212.2.240.142 and PORT is 31054. I’ll be able to access the Litmus Control Plane by visiting http://212.2.240.142:31054
You should be able to see the Login Page of Litmus. The default credentials are
Username: admin
Password: litmus
Deploying our target application
Just like an application is incomplete without Chaos Engineering, a chaos injection is incomplete without selecting a target application to inject the chaos on. In this demo, we’ll target Nginx as the target application on which we’ll apply pod-delete to terminate the application pod and check if it's resilient enough to come back up by itself.
The hypothesis of this demo experiment is to kill the application pod of Nginx and wait to see if it spawns back up by itself. To deploy Nginx on the cluster do the following.
$kubectl create deploy nginx --image nginx
This would install the Nginx deployment in the default namespace, you can also create the same in the namespace of your choice.
Creating the Pod Delete experiment through the Litmus Control Plane
Once we are able to successfully launch the Control Plane we can select the respective agent that we want to use to run the Chaos on. By default, you’ll have a Self Agent connected and we’re also going to use the same to move forward in this demo.
Since this is a custom workflow that involves adding pod-delete as an experiment, we’d focus on adding it as a part of the custom workflow and not a pre-defined one. We have two options for custom workflows -
- Choosing from MyHub
- Uploading a YAML
We’ve selected MyHub to ease the flow of the demo and added pod-delete from the list of generic experiments present in ChaosHub.
Once we’ve added the same in the workflow table we can click on the experiment to reveal the metadata which is tunable.
If you have installed the Nginx deployment in any other namespace or if you want to tune your experiment to set annotations to true, then this is the right place to do so. For our application, we just need to set the app label to app=nginx so that it can target the right application.
Post-editing we can schedule the workflow by verifying the information in the Verify and Commit page.
Analysing the Workflow
Post creation our workflow would be available to us where we can see the live visualization of the chaos injection. The UI would map and visualize the steps in a sequential fashion and display all the metadata and logs along with Chaos Results of the workflow nodes.
If you want more granular control over the nodes, you can switch over to Table View to get a better view of the same. Upon workflow completion, the Chaos Result of the Chaos Engine would return the verdict of the workflow which specify the score of probe success percentage, the overall verdict of the experiment, phase, and other vital information.
Conclusion
Thank you for reading it to the very end and trying out Litmus Beta on Civo! Civo is a great platform to build your Kubernetes applications! With a community of 4000+ members, the community initiative is taking centre stage while Civo comes out of Beta and gears up for the Early Access Launch!
Apply for Early Access for Civo here: https://www.civo.com/
LitmusChaos 2.0 beta is out now and we await the launch of 2.0 GA within the next few months. Are you an SRE or a Kubernetes enthusiast? Does Chaos Engineering excite you?
Contribute to LitmusChaos and share your feedback on Github. If you like LitmusChaos, become one of the many stargazers here.
Join the LitmusChaos slack community following these simple steps!
Step 1: Join the Kubernetes slack using the following link: https://slack.k8s.io/
Step 2: Join the #litmus channel on the Kubernetes slack or use this link after joining the Kubernetes slack: https://slack.litmuschaos.io/
Looking forward to having you in our community and learning together!
