This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Installation

Install krkn-operator using Helm

This guide walks you through installing krkn-operator using Helm, the recommended installation method.

Prerequisites

Kubernetes 1.19+ or OpenShift 4.x
Helm 3.0+
A Kubernetes cluster (kind, minikube, or production cluster)

Quick Start (kind/minikube)

Perfect for testing and local development, this minimal installation gets krkn-operator running quickly on kind or minikube.

Latest Version: loading…

The version number is automatically updated in the commands below. For other available versions, see the releases page.

1. Install krkn-operator

helm install krkn-operator oci://quay.io/krkn-chaos/charts/krkn-operator --version <VERSION>

This installs krkn-operator with default settings in the current namespace.

3. Verify Installation

kubectl get pods -l app.kubernetes.io/name=krkn-operator

Expected output:

NAME                              READY   STATUS    RESTARTS   AGE
krkn-operator-xxxxxxxxx-xxxxx     2/2     Running   0          1m

4. Access the Console (Optional)

For local testing, use port-forwarding to access the web console:

kubectl port-forward svc/krkn-operator-console 3000:3000

Then open http://localhost:3000 in your browser.

Production Installation

For production deployments, you’ll want to customize the installation with a values.yaml file to ensure high availability, proper resource limits, monitoring integration, and secure external access.

When to Use Each Installation Method

Choose the installation method that matches your environment and requirements:

Method	Use When	Key Features
Quick Start	Testing on kind/minikube, local development, POC	Minimal configuration, port-forward access, no HA
Production (Kubernetes)	Running on standard Kubernetes (EKS, GKE, AKS, self-managed)	Ingress for external access, HA setup, resource limits, monitoring
Production (OpenShift)	Running on OpenShift/OKD clusters	OpenShift Routes instead of Ingress, enhanced security contexts, HA setup

The main differences between production installations are:

Kubernetes can use either:
- Gateway API (recommended) - Modern routing standard with powerful features
- Ingress (legacy) - Traditional method, still widely supported
OpenShift uses Routes for external access (native OpenShift feature, no additional controller needed)
Production configurations add replica counts, resource limits, pod disruption budgets, and monitoring compared to Quick Start

All production methods support the same chaos scenarios and core functionality—the choice depends on your platform and infrastructure preferences.

Installation on Kubernetes

Kubernetes clusters can expose the web console using either Gateway API (recommended) or Ingress (legacy).

Option 1: Using Gateway API (Recommended)

Gateway API is the modern successor to Ingress and provides more powerful and flexible routing capabilities.

Prerequisites:

Gateway API CRDs installed in your cluster (installation guide)
A Gateway resource already deployed (usually managed by cluster admins)

Create a values.yaml file:

# Production values for Kubernetes with Gateway API

# Enable web console with Gateway API
console:
  enabled: true
  gateway:
    enabled: true
    gatewayName: krkn-gateway  # Name of your existing Gateway
    gatewayNamespace: ""  # Optional: if Gateway is in a different namespace
    hostname: krkn.example.com
    path: /
    pathType: PathPrefix

# Operator configuration
operator:
  replicaCount: 2
  resources:
    requests:
      cpu: 100m
      memory: 128Mi
    limits:
      cpu: 500m
      memory: 512Mi
  logging:
    level: info
    format: json

# High availability
podDisruptionBudget:
  enabled: true
  minAvailable: 1

# Monitoring (if using Prometheus)
monitoring:
  enabled: true
  serviceMonitor:
    enabled: true
    interval: 30s

Note: Gateway API assumes you have a Gateway resource already configured in your cluster. The chart creates only the HTTPRoute that attaches to that Gateway.

Option 2: Using Ingress (Legacy)

If your cluster doesn’t support Gateway API yet, you can use traditional Ingress:

# Production values for Kubernetes with Ingress

# Enable web console with Ingress
console:
  enabled: true
  ingress:
    enabled: true
    className: nginx  # or your ingress controller
    hostname: krkn.example.com
    annotations:
      cert-manager.io/cluster-issuer: letsencrypt-prod
    tls:
      - secretName: krkn-tls
        hosts:
          - krkn.example.com

# Operator configuration
operator:
  replicaCount: 2
  resources:
    requests:
      cpu: 100m
      memory: 128Mi
    limits:
      cpu: 500m
      memory: 512Mi
  logging:
    level: info
    format: json

# High availability
podDisruptionBudget:
  enabled: true
  minAvailable: 1

# Monitoring (if using Prometheus)
monitoring:
  enabled: true
  serviceMonitor:
    enabled: true
    interval: 30s

Install with your custom values:

helm install krkn-operator oci://quay.io/krkn-chaos/charts/krkn-operator \
  --version <VERSION> \
  --namespace krkn-operator-system \
  --create-namespace \
  -f values.yaml

Installation on OpenShift

OpenShift uses Routes instead of Ingress. The Helm chart automatically handles OpenShift-specific security requirements (SCC configuration, RBAC permissions).

Create an OpenShift-specific values.yaml:

# Production values for OpenShift

# Enable web console with Route
console:
  enabled: true
  route:
    enabled: true
    hostname: krkn.apps.cluster.example.com  # Change to your cluster's app domain
    tls:
      enabled: true
      termination: edge
      insecureEdgeTerminationPolicy: Redirect

# Operator configuration
operator:
  replicaCount: 2
  resources:
    requests:
      cpu: 100m
      memory: 128Mi
    limits:
      cpu: 500m
      memory: 512Mi
  logging:
    level: info
    format: json

# High availability
podDisruptionBudget:
  enabled: true
  minAvailable: 1

# Monitoring (if Prometheus Operator is installed)
monitoring:
  enabled: true
  serviceMonitor:
    enabled: true
    interval: 30s

Install on OpenShift:

helm install krkn-operator oci://quay.io/krkn-chaos/charts/krkn-operator \
  --version <VERSION> \
  --namespace krkn-operator-system \
  --create-namespace \
  -f values-openshift.yaml

INFO

OpenShift Security: The chart automatically detects OpenShift and configures the required Security Context Constraints (SCC) for scenario runner pods. No manual SCC configuration is needed.

Advanced Configuration Options

Enable ACM Integration

To enable Red Hat Advanced Cluster Management (ACM) / Open Cluster Management (OCM) integration:

acm:
  enabled: true
  replicaCount: 1
  config:
    secretName: "application-manager"  # ACM managed clusters secret (auto-created by ACM)
  resources:
    requests:
      cpu: 100m
      memory: 128Mi
    limits:
      cpu: 500m
      memory: 512Mi
  logging:
    level: info
    format: json

Install with ACM enabled (Kubernetes):

helm install krkn-operator oci://quay.io/krkn-chaos/charts/krkn-operator \
  --version <VERSION> \
  --namespace krkn-operator-system \
  --create-namespace \
  --set acm.enabled=true

Install with ACM enabled (OpenShift with Route):

helm install krkn-operator oci://quay.io/krkn-chaos/charts/krkn-operator \
  --version <VERSION> \
  --namespace krkn-operator-system \
  --create-namespace \
  --set acm.enabled=true \
  --set console.route.enabled=true \
  --set console.route.hostname=krkn.apps.cluster.example.com

INFO

ACM Integration: When ACM is enabled, krkn-operator-acm will automatically discover and manage ACM-controlled clusters (ManagedCluster resources). The ACM component requires:

ACM/OCM installed on the cluster
ManagedCluster resources present
The application-manager secret (auto-created by ACM)

See the ACM Integration section in Configuration for more details.

</div>

Custom Namespace

Install in a custom namespace:

helm install krkn-operator oci://quay.io/krkn-chaos/charts/krkn-operator \
  --version <VERSION> \
  --namespace my-chaos-platform \
  --create-namespace \
  --set namespaceOverride=my-chaos-platform

Image Registry Override

If you’re using a private registry or mirror:

operator:
  image: myregistry.io/krkn-chaos/krkn-operator:<VERSION>
  pullPolicy: IfNotPresent

dataProvider:
  image: myregistry.io/krkn-chaos/data-provider:<VERSION>

pullSecrets:
  - name: my-registry-secret

JWT Configuration

Customize JWT token settings for authentication:

auth:
  jwtSecret: bXktc2VjdXJlLWp3dC1rZXktYmFzZTY0LWVuY29kZWQ=  # Base64 encoded
  jwtExpiryHours: 72  # 3 days

INFO

Security: Always generate a secure, random JWT secret for production. Do not use default or predictable values. If not provided, the chart automatically generates a random secret on installation.

Complete values.yaml Reference

Here’s a comprehensive values.yaml with all available options:

# Namespace configuration
namespaceOverride: ""

# Image configuration
operator:
  image: quay.io/krkn-chaos/krkn-operator:latest
  pullPolicy: IfNotPresent
  enabled: true
  replicaCount: 1

  resources:
    requests:
      cpu: 100m
      memory: 128Mi
    limits:
      cpu: 500m
      memory: 512Mi

  dataProvider:
    resources:
      requests:
        cpu: 50m
        memory: 64Mi
      limits:
        cpu: 200m
        memory: 256Mi

  service:
    type: ClusterIP
    port: 8080
    grpcPort: 50051

  logging:
    level: info  # debug, info, warn, error
    format: json  # json or text

  # Security context - auto-detects platform (OpenShift vs Kubernetes)
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
    # Note: runAsUser and fsGroup omitted - allows OpenShift to auto-assign valid UIDs

  nodeSelector: {}
  tolerations: []
  affinity: {}
  extraEnv: []

dataProvider:
  image: quay.io/krkn-chaos/data-provider:latest

# ACM Integration (Optional)
acm:
  enabled: false
  image: quay.io/krkn-chaos/krkn-operator-acm:latest
  replicaCount: 1

  config:
    secretName: "application-manager"  # ACM managed clusters secret (auto-created by ACM)

  service:
    port: 8080
    grpcPort: 50051

  logging:
    level: info
    format: json

  # Security context - auto-detects platform (OpenShift vs Kubernetes)
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
    # Note: runAsUser and fsGroup omitted - allows OpenShift to auto-assign valid UIDs

  resources:
    requests:
      cpu: 100m
      memory: 128Mi
    limits:
      cpu: 200m
      memory: 256Mi

  nodeSelector: {}
  tolerations: []
  affinity: {}

# Web Console (Optional)
console:
  enabled: true
  image: quay.io/krkn-chaos/console:latest
  replicaCount: 1

  service:
    type: ClusterIP
    port: 3000
    nodePort: null  # Only for NodePort service type

  # Kubernetes Ingress (legacy)
  ingress:
    enabled: false
    className: nginx
    hostname: krkn.example.com
    annotations: {}
    tls: []

  # Gateway API (recommended for Kubernetes)
  gateway:
    enabled: false
    gatewayName: krkn-gateway
    gatewayNamespace: ""
    sectionName: ""
    hostname: krkn.example.com
    path: /
    pathType: PathPrefix
    annotations: {}

  # OpenShift Route
  route:
    enabled: false
    hostname: ""
    tls:
      termination: edge  # edge, passthrough, or reencrypt

  resources:
    requests:
      cpu: 50m
      memory: 64Mi
    limits:
      cpu: 200m
      memory: 256Mi

  # Security context - auto-detects platform (OpenShift vs Kubernetes)
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
    # Note: runAsUser and fsGroup omitted - allows OpenShift to auto-assign valid UIDs

  nodeSelector: {}
  tolerations: []
  affinity: {}

# Image pull secrets
pullSecrets: []

# JWT Authentication
auth:
  jwtSecret: ""  # Base64 encoded; auto-generated if empty
  jwtExpiryHours: 24  # Token expiry in hours

# RBAC
rbac:
  create: true

# Service Account
serviceAccount:
  create: true
  name: ""
  annotations: {}

# CRDs
crds:
  keep: true  # Keep CRDs after uninstall

# Monitoring
monitoring:
  enabled: false
  service:
    port: 8443
  serviceMonitor:
    enabled: false
    interval: 30s

# Network Policy
networkPolicy:
  enabled: false
  ingress: []
  egress: []

# Update Strategy
updateStrategy:
  type: RollingUpdate

# Pod Disruption Budget
podDisruptionBudget:
  enabled: false
  minAvailable: 1

# Common labels and annotations
commonLabels: {}
commonAnnotations: {}

# Naming
nameOverride: ""
fullnameOverride: ""

Verification

After installation, verify all components are running:

# Check operator pods
kubectl get pods -n krkn-operator-system

# Check services
kubectl get svc -n krkn-operator-system

# Check CRDs
kubectl get crds | grep krkn

# View operator logs
kubectl logs -n krkn-operator-system -l app.kubernetes.io/name=krkn-operator -c manager

Upgrading

To upgrade to a newer version:

helm upgrade krkn-operator oci://quay.io/krkn-chaos/charts/krkn-operator \
  --version <VERSION> \
  --namespace krkn-operator-system \
  -f values.yaml

Uninstalling

To remove krkn-operator:

helm uninstall krkn-operator --namespace krkn-operator-system

INFO

CRDs Persistence: By default, Custom Resource Definitions (CRDs) are preserved after uninstallation to prevent data loss. To remove them manually:

kubectl delete crds -l app.kubernetes.io/name=krkn-operator

Next Steps

Configure Target Clusters - Set up target clusters for chaos testing
ACM Integration - Enable Advanced Cluster Management integration
Run Your First Scenario - Start running chaos experiments