> For the complete documentation index, see [llms.txt](https://developer.harness.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.harness.io/resilience-testing/chaos-engineering/use-chaos-engineering/gke-autopilot.md).
# Chaos on GKE Autopilot
This guide explains how to set up and run chaos engineering experiments using Harness Chaos Engineering on Google Kubernetes Engine (GKE) Autopilot clusters.
### Overview
[GKE Autopilot](https://cloud.google.com/blog/products/containers-kubernetes/introducing-gke-autopilot) is Google's fully managed Kubernetes service that provides a hands-off experience while maintaining security and compliance. However, Autopilot has specific restrictions compared to standard GKE clusters, including limited permissions and no direct access to nodes.
For additional information about running privileged workloads on GKE Autopilot, see [Google Partner Docs](https://cloud.google.com/kubernetes-engine/docs/resources/autopilot-partners) and [Run privileged workloads from GKE Autopilot partners](https://cloud.google.com/kubernetes-engine/docs/how-to/run-autopilot-partner-workloads).
### Prerequisites
Before you begin, ensure you have:
* A running GKE Autopilot cluster
* `kubectl` access to the cluster with appropriate permissions
* A Harness account with Chaos Engineering module enabled
* Cluster admin permissions to create allowlist synchronizers
### Step-by-Step Setup Guide
#### Step 1: Configure GKE Autopilot Allowlist
GKE Autopilot requires an allowlist that defines exemptions from security restrictions for specific workloads. Harness maintains an allowlist for chaos engineering operations that you need to apply to your cluster.
**Required permissions:** You need cluster admin permissions and `kubectl` access to apply the allowlist synchronizer.
Apply the allowlist synchronizer to your GKE Autopilot cluster:
```yaml
kubectl apply -f - <<'EOF'
apiVersion: auto.gke.io/v1
kind: AllowlistSynchronizer
metadata:
name: harness-chaos-allowlist-synchronizer
spec:
allowlistPaths:
- Harness/chaos/v1.66/*
- Harness/service-discovery/v0.46/*
EOF
```
Wait for the allowlist synchronizer to be ready:
```bash
kubectl wait --for=condition=Ready allowlistsynchronizer/harness-chaos-allowlist-synchronizer --timeout=60s
```
{% hint style="info" %}
**VERSION UPDATES**
The allowlist paths include version numbers (e.g., `v1.66`, `v0.46`) that may change with Harness updates. If you encounter issues:
1. Check the [Harness release notes](/release-notes/chaos-engineering.md) for the latest supported versions
2. Update the allowlist paths accordingly
3. Contact Harness support for the most current allowlist versions
{% endhint %}
#### Step 2: Enable GKE Autopilot Compatibility
After applying the allowlist synchronizer, you need to enable GKE Autopilot compatibility in your existing Harness infrastructure:
{% hint style="info" %}
**ALTERNATIVE SETUP OPTIONS**
You can also configure the **"Use static name for configmap and secret"** option for GKE Autopilot compatibility during:
* [1-click chaos setup](/resilience-testing/chaos-engineering/new-to-chaos-engineering/quickstart.md#automated-onboarding)
* New discovery agent creation
* For existing discovery agents
{% endhint %}
**Configure Infrastructure for GKE Autopilot**
1. Navigate to **Chaos Engineering** → **Environments** and select your environment.
2. Click the **options menu (⋮)** next to your infrastructure and select **Edit Infrastructure**
3. Toggle on **"Use static name for configmap and secret"** and click **Save**
**Configure Service Discovery**
1. Navigate to **Project Settings** → **Discovery**
2. Click the **options menu (⋮)** next to your discovery agent and select **Edit**
3. Toggle on **"Use static name for configmap and secret"** and click **Update Discovery Agent**
#### Step 3: Start Running Chaos Experiments
Your GKE Autopilot cluster is now ready for chaos engineering. To create and run your first experiment, follow the [Create Experiments](/resilience-testing/chaos-engineering/chaos-experiments/create-experiments.md) guide and choose from any of the supported experiments listed below.
### Supported Chaos Experiments
Harness Chaos Engineering provides comprehensive Kubernetes fault coverage. On GKE Autopilot, experiments are categorized based on compatibility with Autopilot's security model.
#### Supported Pod-Level Experiments
These experiments work seamlessly on GKE Autopilot as they operate within container boundaries:
**Container Resource Stress**
* [**Pod CPU Hog**](/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-cpu-hog.md): Consumes excess CPU resources of application containers
* [**Pod Memory Hog**](/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-memory-hog.md): Consumes memory resources causing significant memory usage spikes
* [**Pod IO Stress**](/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-io-stress.md): Causes I/O stress by spiking input/output requests
**Container Storage Operations**
* [**Disk Fill**](/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/disk-fill.md): Fills the pod's ephemeral storage
* [**FS Fill**](/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/fs-fill.md): Applies filesystem stress by filling pod's ephemeral storage
**Container Lifecycle Management**
* [**Container Kill**](/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/container-kill.md): Causes container failure on specific or random replicas
* [**Pod Delete**](/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-delete.md): Causes specific or random replicas to fail forcibly or gracefully
* [**Pod Autoscaler**](/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-autoscaler.md): Tests whether nodes can accommodate multiple replicas
**Network Chaos (Container-Level)**
* [**Pod Network Latency**](/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-network-latency.md): Introduces network delays using traffic control
* [**Pod Network Loss**](/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-network-loss.md): Causes packet loss using netem rules
* [**Pod Network Corruption**](/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-network-corruption.md): Injects corrupted packets into containers
* [**Pod Network Duplication**](/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-network-duplication.md): Duplicates network packets to disrupt connectivity
* [**Pod Network Partition**](/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-network-partition.md): Blocks 100% ingress/egress traffic using network policies
* [**Pod Network Rate Limit**](/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-network-rate-limit.md): Limits network bandwidth using Token Bucket Filter
**DNS Manipulation**
* [**Pod DNS Error**](/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-dns-error.md): Injects chaos to disrupt DNS resolution in pods
* [**Pod DNS Spoof**](/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-dns-spoof.md): Mimics DNS resolution to redirect traffic
**HTTP/API Fault Injection**
* [**Pod HTTP Latency**](/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-http-latency.md): Injects HTTP response latency via proxy server
* [**Pod HTTP Modify Body**](/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-http-modify-body.md): Modifies HTTP request/response body content
* [**Pod HTTP Modify Header**](/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-http-modify-header.md): Overrides HTTP header values
* [**Pod HTTP Reset Peer**](/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-http-reset-peer.md): Stops outgoing HTTP requests by resetting TCP connections
* [**Pod HTTP Status Code**](/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-http-status-code.md): Modifies HTTP response status codes
**API Gateway/Service Mesh Faults**
* [**Pod API Block**](/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-api-block.md): Blocks API requests through path filtering
* [**Pod API Latency**](/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-api-latency.md): Injects API request/response latency via proxy
* [**Pod API Modify Body**](/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-api-modify-body.md): Modifies API request/response body using regex
* [**Pod API Modify Header**](/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-api-modify-header.md): Overrides API header values
* [**Pod API Status Code**](/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-api-status-code.md): Changes API response status codes with path filtering
* [**Pod API Modify Response Custom**](/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-api-modify-response-custom.md): Comprehensive API response modification
**File System I/O Manipulation**
* [**Pod IO Attribute Override**](/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-io-attribute-override.md): Modifies properties of files in mounted volumes
* [**Pod IO Error**](/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-io-error.md): Returns errors on system calls for mounted volume files
* [**Pod IO Latency**](/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-io-latency.md): Delays system calls for files in mounted volumes
* [**Pod IO Mistake**](/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-io-mistake.md): Causes incorrect read/write values in mounted volumes
**JVM-Specific Chaos (Java Applications)**
* [**Pod JVM CPU Stress**](/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-jvm-cpu-stress.md): Consumes excessive CPU threads in Java applications
* [**Pod JVM Memory Stress**](/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-jvm-memory-stress.md): Consumes excessive heap or stack memory in Java applications
* [**Pod JVM Method Exception**](/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-jvm-method-exception.md): Invokes exceptions in Java method calls
* [**Pod JVM Method Latency**](/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-jvm-method-latency.md): Introduces delays in Java method execution
* [**Pod JVM Modify Return**](/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-jvm-modify-return.md): Modifies return values of Java methods
* [**Pod JVM Trigger GC**](/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-jvm-trigger-gc.md): Forces garbage collection in Java applications
**Database Integration Chaos**
* [**Pod JVM SQL Exception**](/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-jvm-sql-exception.md): Injects exceptions in SQL queries (Java apps)
* [**Pod JVM SQL Latency**](/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-jvm-sql-latency.md): Introduces latency in SQL queries (Java apps)
* [**Pod JVM Mongo Exception**](/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-jvm-mongo-exception.md): Injects exceptions in MongoDB calls (Java apps)
* [**Pod JVM Mongo Latency**](/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-jvm-mongo-latency.md): Introduces latency in MongoDB calls (Java apps)
* [**Pod JVM Solace Exception**](/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-jvm-solace-exception.md): Injects exceptions in Solace queries (Java apps)
* [**Pod JVM Solace Latency**](/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-jvm-solace-latency.md): Introduces latency in Solace queries (Java apps)
**Cache and Data Store Chaos**
* [**Redis Cache Expire**](/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/redis-cache-expire.md): Expires Redis keys for specified duration
* [**Redis Cache Limit**](/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/redis-cache-limit.md): Limits memory used by Redis cache
* [**Redis Cache Penetration**](/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/redis-cache-penetration.md): Sends continuous requests for non-existent keys
**System Time Manipulation**
* [**Time Chaos**](/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/time-chaos.md): Introduces controlled time offsets to disrupt system time
#### Node-Level Chaos Experiments
Harness Chaos now supports select node-level chaos experiments on GKE Autopilot that operate within the security constraints of the managed environment:
**Node Network Chaos**
* [**Node Network Loss**](/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/node/node-network-loss.md): Injects network packet loss at the node level
* [**Node Network Latency**](/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/node/node-network-latency.md): Introduces network latency for node-level traffic
### Next Steps
Now that you have Harness Chaos Engineering set up on your GKE Autopilot cluster:
1. **Create Your First Experiment**: Start with a simple [Pod CPU Hog](/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-cpu-hog.md) experiment with low intensity to test your setup
2. **Set Up Application Discovery**: Enable **Service Discovery** in your infrastructure settings and explore **Application Maps** to visualize your services
3. **Add Monitoring**: Configure [probes](/resilience-testing/chaos-engineering/use-chaos-engineering/probes/index.md) to validate your application's resilience during experiments
4. **Explore More Experiments**: Try network chaos like [Pod Network Latency](/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-network-latency.md) or JVM faults for Java applications