Sunday, October 25, 2026 4,350 lists 78,100 records on file
List your app or device

  1. Home
  2. Chaos Engineering Platforms
  3. Krkn

Krkn

What it is

Krkn injects deliberate failures into Kubernetes clusters so teams can assess how systems respond to disruption. Its more than 20 scenarios cover areas such as pods, containers, nodes, networks, applications, storage, resources, and time. The recommended krknctl command-line tool discovers, runs, and orchestrates scenarios; other options include pre-built containers, a browser dashboard, and a standalone Python program. Krkn can evaluate Prometheus metrics against SLO pass/fail criteria and review measurements during and after a scenario. The dashboard supports Elasticsearch and Grafana, while telemetry can be sent to S3 or Elasticsearch. Cerberus monitors Kubernetes and OpenShift health and provides a go/no-go signal, reports, and a metrics API, with Slack failure reporting. Krkn-AI uses evolutionary algorithms and user-defined objectives to identify experiments. The project says it saves recovery state and can restore a cluster automatically, but some disruptive scenarios may leave a target unrecoverable. Krkn is intended for resilience testing, not security provision, and says it does not currently adhere to compliance standards. Requirements include Kubernetes or OpenShift 1.21+, cluster-admin kubeconfig access, and Docker 20.10+ or Podman 4.0+. Krkn is free.

For and against

For

  • More than 20 disruption scenarios are available
  • Can check Prometheus metrics against SLO criteria
  • Offers CLI, container, dashboard, and Python installation options
  • Free to use

Against

  • Some disruptive scenarios may leave systems unrecoverable
  • krkn-hub runs one scenario type per execution
  • Standalone Python setup requires Python 3.9 and manual dependencies
  • Requires cluster-admin kubeconfig access

The verdict

Krkn offers several ways to run cluster resilience experiments and evaluate their effects against metrics. It is not a security provider, and its disruption scenarios require careful attention to recovery risk.

Who it suits

Krkn is suited to first-time chaos engineers and teams building resilience-testing workflows for Kubernetes or OpenShift. Users should be prepared to meet its cluster access and runtime requirements.

Plans and prices

Krkn

Free

No pricing or usage limits stated on the opened pages

Every plan, in full

On the record

CLI
krknctl discovers, runs, and orchestrates chaos scenarios, and is the recommended way to run Krkn.krkn-chaos.dev · read 5 Oct 2026
Deployment options
Krkn offers a CLI, pre-built container images, a browser-based dashboard, and a standalone Python program.krkn-chaos.dev · read 5 Oct 2026
Install options
Installation options include a CLI, pre-built containers, a browser-based dashboard, and a standalone Python program.krkn-chaos.dev · read 7 Oct 2026
Integrations
The documentation describes integrations with Prometheus, Elasticsearch, Grafana, Slack, S3, and CI/CD systems such as Jenkins and GitHub Actions.krkn-chaos.dev · read 7 Oct 2026
Krkn AI
Krkn-AI uses evolutionary algorithms and user-defined objectives such as SLOs and application health checks to identify impactful chaos experiments.krkn-chaos.dev · read 5 Oct 2026
Metrics and SLOs
Krkn can validate SLO pass/fail criteria with Prometheus PromQL queries and review metrics during and after chaos scenarios.krkn-chaos.dev · read 5 Oct 2026
Monitoring
Cerberus monitors Kubernetes and OpenShift health and exposes a go/no-go signal, reports, and a metrics API.krkn-chaos.dev · read 7 Oct 2026
Notable limits
krkn-hub runs one scenario type per execution; running multiple scenario types in one execution requires the standalone Krkn installation.krkn-chaos.dev · read 5 Oct 2026
Operating guidance
The installation guide recommends running Krkn outside the cluster against the Kubernetes or OpenShift API.krkn-chaos.dev · read 7 Oct 2026
Project status
The site identifies Krkn as a Cloud Native Computing Foundation Sandbox project.krkn-chaos.dev · read 7 Oct 2026
Purpose
Krkn injects deliberate failures into Kubernetes clusters to test their resilience.krkn-chaos.dev · read 7 Oct 2026
Requirements
The getting-started guide lists Kubernetes or OpenShift 1.21+, cluster-admin kubeconfig access, and Docker 20.10+ or Podman 4.0+ as requirements.krkn-chaos.dev · read 7 Oct 2026
Rollback
Krkn’s rollback system persists changes to the filesystem before a scenario so it can restore targeted Kubernetes objects or subsystems.krkn-chaos.dev · read 7 Oct 2026
Rollback limitation
The security self-assessment says some disruptive scenarios may leave the target system in a non-recoverable condition.krkn-chaos.dev · read 7 Oct 2026
Runtime requirement
The standalone Python installation requires a Python 3.9 environment and manual dependency management.krkn-chaos.dev · read 5 Oct 2026
Scenario coverage
The site lists 20+ chaos scenarios spanning pods, nodes, networks, applications, storage, and time.krkn-chaos.dev · read 7 Oct 2026
Scenarios
The site lists more than 20 chaos scenarios covering pods, containers, nodes, networks, applications, resources, storage, and time.krkn-chaos.dev · read 5 Oct 2026
Security documentation
The security self-assessment lists a software bill of materials for Krkn, krkn-lib, and krknctl, and says a security-insights.yml should be added to the roadmap.krkn-chaos.dev · read 5 Oct 2026

The review

Krkn is a free, self-hosted toolkit for injecting failures into Kubernetes clusters and assessing their effects. It is best suited to platform teams and chaos engineers who need to run controlled resilience experiments and judge results against service objectives. Its scenario range and SLO checks are useful, though the recovery risks call for careful targeting and operational judgment.

Overview

Krkn focuses on deliberate disruption of Kubernetes clusters, with support for Kubernetes and OpenShift environments. It is a Cloud Native Computing Foundation Sandbox project. The installation guide recommends running it outside the cluster and connecting through the Kubernetes or OpenShift API, a sensible fit for teams that want to keep the experiment runner separate from the system under test.

Getting started requires Kubernetes or OpenShift 1.21+, cluster-admin kubeconfig access, and Docker 20.10+ or Podman 4.0+. That access requirement gives Krkn the reach needed for cluster-level experiments, but means it belongs in a carefully controlled environment rather than a casually provisioned developer setup.

Key features

Krkn offers more than 20 chaos scenarios across pods, containers, nodes, networks, applications, resources, storage, and time. That breadth lets teams examine several failure layers using one project. The recommended krknctl CLI discovers, runs, and orchestrates scenarios, while pre-built containers, a browser dashboard, and a standalone Python program provide other ways to deploy it.

There is a meaningful execution limitation: krkn-hub runs one scenario type per execution. Teams that need to combine multiple scenario types in a single run must use the standalone Krkn installation. That option brings more flexibility, but requires a Python 3.9 environment and manual dependency management, adding setup work for teams that want a composed experiment.

Krkn can evaluate Prometheus PromQL queries against SLO pass/fail criteria and review metrics during and after a scenario. This gives teams a way to connect disruption to service objectives instead of treating an experiment as successful merely because it ran. The dashboard supports Elasticsearch and Grafana integration, and telemetry can also be sent to S3 or Elasticsearch.

Cerberus adds monitoring for Kubernetes and OpenShift health, exposing a go/no-go signal, reports, and a metrics API; it can also report failures in Slack. Krkn-AI uses evolutionary algorithms with user-defined objectives such as SLOs and application health checks to identify impactful experiments. These capabilities extend Krkn from scenario execution into observing and selecting experiments, though teams still need to define useful objectives and interpret results.

Krkn says it saves recovery state before making changes and can automatically restore a cluster if an experiment goes wrong. That is a helpful safeguard, not a guarantee: some disruptive scenarios may leave the target system unrecoverable. Krkn also explicitly says it is not a security provider and does not currently adhere to compliance standards. Its security self-assessment lists software bills of materials for Krkn, krkn-lib, and krknctl, and says security-insights.yml should be added to the roadmap; vulnerability reports are accepted through GitHub's vulnerability reporting tool.

Pricing

Krkn is free, with a listed plan price of free. The plan has no published usage limits on the product pages, so there is no stated quota or seat cap to weigh against its capabilities. Its cost advantage is clear for teams that can operate the tooling themselves; the tradeoff is that installation, access management, scenario selection, and recovery planning remain operational responsibilities.

Platforms

Krkn supports API access, Linux, self-hosted deployment, and a web dashboard. Kubernetes support, cloud fault injection, network fault injection, and blast-radius controls are included. The available deployment choices cover command-line, container, browser, and standalone Python workflows, but the Python route carries the environment and dependency burden described above.

Who it's for

Krkn suits teams from first-time chaos engineers to experienced groups building repeatable resilience-testing workflows, provided they have Kubernetes or OpenShift access and can manage cluster-admin credentials responsibly. It is a strong fit when teams want varied cluster disruptions, Prometheus-based SLO evaluation, and self-hosted operation without a software charge. It is a poor fit for organizations seeking a security product, compliance adherence, or an experiment runner that removes the possibility of serious recovery impact.

Pros and cons

  • Pros: More than 20 scenarios cover multiple cluster and application layers, giving teams broad ground for resilience exercises.
  • Pros: Prometheus-based SLO pass/fail evaluation and metric review connect experiments to service objectives.
  • Pros: CLI, container, dashboard, and Python installation options support different deployment workflows.
  • Pros: Free self-hosted use, with no stated usage caps, makes it accessible for teams able to operate it themselves.
  • Cons: Some scenarios can leave a target system unrecoverable, so rollback support cannot remove the need for careful scope and recovery planning.
  • Cons: krkn-hub runs one scenario type at a time; combining types requires standalone installation with Python 3.9 and manual dependency management.
  • Cons: Cluster-admin kubeconfig access is required, and Krkn does not claim security-provider status or compliance adherence.

Alternatives

Chaos Mesh is another free, open-source, cloud-native chaos engineering platform that runs on Kubernetes; consider it when that Kubernetes-centered platform is the closer fit. Krkn-AI is a free, open-source option for Linux and self-hosted use if that narrower tool is what you are evaluating.

Reliably describes itself as open source and says its approach avoids lock-in; its free plan allows one team member, which may suit an individual evaluating that option. Toxiproxy is a free, open-source TCP proxy under the MIT license, making it the alternative to consider for a TCP-proxy-focused need.

Chaos Toolkit is a free, open-source CLI under Apache License 2.0. ChaosBlade is a free open-source option with support for three system platforms, four programming-language applications, and more than 200 experiment scenarios. chaosd offers a free Apache-2.0-licensed Linux binary and requires glibc v2.17 or later.

FaultMesh has a free Starter plan covering up to three services, core fault types, basic resilience scoring, and community support; choose it when those stated service and scoring terms match your needs.

For a broader comparison, see Chaos Engineering Platforms.

Verdict

Krkn is a strong choice for Kubernetes and OpenShift teams that want a free, self-hosted way to run varied failure scenarios and measure them against Prometheus SLO criteria. Its operational breadth is the main reason to choose it; the possibility of unrecoverable disruption, the cluster-admin requirement, and the extra setup for multi-type runs are the main reasons to look elsewhere.

Alternatives to Krkn

Every alternative, ranked