Krkn

Overview

Krkn is a free tool for introducing controlled failures into Kubernetes clusters and assessing resilience. It is best suited to platform teams and chaos engineers who need cluster-level experiments tied to service objectives. Its scenario range and SLO checks are compelling; the risk of disruptions that cannot be reversed calls for deliberate targeting and operational safeguards.

Key features

Krkn offers more than 20 scenarios across pods, containers, nodes, networks, applications, resources, storage, and time. That breadth helps teams probe different failure points within a Kubernetes environment rather than relying on one kind of disruption. The recommended krknctl CLI discovers, runs, and orchestrates scenarios. Pre-built container images, a browser-based dashboard, and a standalone Python program provide other ways to run it.

For teams with defined reliability targets, Krkn can evaluate Prometheus PromQL queries and pass or fail a run against SLO criteria. It can also review metrics during and after experiments. The dashboard supports Elasticsearch and Grafana integration, while telemetry can be sent to S3 or Elasticsearch.

Cerberus monitors Kubernetes and OpenShift cluster health, providing a go/no-go signal, reports, and a metrics API; it can report failures in Slack. Krkn-AI uses evolutionary algorithms and user-defined goals, including SLOs and application health checks, to identify impactful experiments. These features support a more structured resilience workflow, though they do not remove the need to assess risk before a run.

Krkn saves recovery state before changes and can automatically restore a cluster if an experiment goes wrong. That is a useful safeguard, not a guarantee: some disruptive scenarios can leave the target system in a non-recoverable condition. The project identifies as a CNCF Sandbox project. Its security self-assessment says it is not a security provider and does not currently adhere to compliance standards; it lists software bills of materials for Krkn, krkn-lib, and krknctl, and accepts vulnerability reports through GitHub.

Pricing

Krkn is free: its published plan is free. No pricing or usage limits are stated for the plan, so it is an option for teams that want to run self-hosted chaos experiments without a software charge. The cost advantage does not change the infrastructure and access requirements or the operational risk of disruptive scenarios.

Platforms

Krkn supports API, Linux, self-hosted, and web use. The getting-started guide requires Kubernetes or OpenShift 1.21+, cluster-admin kubeconfig access, and Docker 20.10+ or Podman 4.0+. The installation guide recommends running Krkn outside the cluster against the Kubernetes or OpenShift API. This setup suits teams able to provide administrative cluster access; it is not a lightweight test environment for users without that access.

Teams choosing the standalone Python installation need a Python 3.9 environment and must manage dependencies manually. Also, krkn-hub runs only one scenario type per execution; running multiple types together requires the standalone Krkn installation. That distinction matters for teams building multi-scenario workflows.

Who it's for

Krkn fits first-time chaos engineers as well as teams developing resilience-testing workflows, particularly when Kubernetes or OpenShift and Prometheus-based SLO checks are central to the work. Its varied run options accommodate different operating preferences, while the prerequisites make it a poor fit for teams unable to provide cluster-admin access or manage the required runtime. Use it with careful blast-radius planning, especially where automatic recovery cannot be assumed.

Pros and cons

• Pros: More than 20 scenarios across several cluster and application layers give teams broad disruption coverage.
• Pros: PromQL-based SLO pass/fail checks connect experiments to explicit reliability objectives.
• Pros: CLI, containers, dashboard, and standalone Python installation offer several execution paths.
• Cons: Cluster-admin kubeconfig access and compatible Kubernetes or OpenShift, Docker, or Podman versions are required.
• Cons: Some disruptions may not be recoverable, despite the saved recovery state and automatic restoration capability.
• Cons: krkn-hub limits each execution to one scenario type, and standalone Python use requires manual dependency management.
• Cons: Krkn is not a security provider and does not currently adhere to compliance standards.

Alternatives

Chaos Engineering Platforms is a category guide for comparing options.

• Chaos Toolkit is a free, open-source CLI under Apache License 2.0, with API, Linux, macOS, self-hosted, web, and Windows platforms. Choose it if those platform options and the CLI are a closer fit.
• ChaosBlade is a free open-source tool with 200+ experiment scenarios and support for three system platforms and four programming-language applications. Choose it if that stated scenario and application coverage better suits your experiments.
• Reliably is freemium and open source, with a free plan for one team member; it says its approach avoids lock-in. Choose it if that open-source approach or its stated team-member allowance is a priority.
• Toxiproxy is a free, open-source TCP proxy under the MIT license. Choose it if a TCP-proxy tool is what your work calls for.
• Chaos Mesh is a free, open-source, cloud-native chaos engineering platform that runs on Kubernetes. Choose it if that Kubernetes-native platform is a better match.
• chaosd is a free Apache-2.0-licensed Linux binary that requires glibc v2.17 or later. Choose it if a Linux binary is the right deployment form for your environment.
• FaultMesh has a free Starter plan for up to three services, core fault types, basic resilience scoring, and community support, alongside a paid Growth plan. Choose it if those stated service limits and scoring fit your needs.
• Krkn-AI is free under Apache License 2.0 and runs on Linux and self-hosted environments. Choose it if you want that narrower platform footprint.

Verdict

Choose Krkn if your team needs broad Kubernetes disruption scenarios, Prometheus-based SLO validation, and flexible self-hosted execution without a software charge. Its main advantage is the ability to connect varied experiments to explicit reliability criteria; its main drawback is that cluster-admin access and careful recovery planning are essential, since some disruptions may not be recoverable. Look elsewhere if those operational risks or prerequisites are not acceptable.