Running Gremlin on GKE (Cilium / Dataplane V2)

Known interactions between Gremlin and GKE clusters running Dataplane V2.

1. Bandwidth Manager and tc conflicts

Cilium's Bandwidth Manager configures qdisc stacks (EDT egress shaping) on the physical eth0 of each node. Gremlin never modifies or clears qdiscs that it didn't create.

In most cases, reliability management can be gauged meaningfully by using Kubernetes Object Targeting rather than host/container. Because the interface in the pod's network namespace does not inherit the qdisc rules from the node, network attacks work normally. This may not apply if qdisc stacks also exist in the pod's network namespace, such as those annotated with Bandwidth Manager constructs such as:

kubernetes.io/egress-bandwidth
kubernetes.io/ingress-bandwidth

If you encounter the following error, your attack target is currently in-scope for Cilium Bandwidth Manager. Not all pods are, and targets will have varying support for network attacks while Bandwidth Manager is enabled:

2026-08-17 20:30:09 UTC - Gremlin experiment terminated with an error: GREMLIN: setup: egress: eth0: Existing tc rules detected

2. AppArmor is on by default on every GKE node

In order to function properly in environments with AppArmor enabled, Gremlin needs to be run unconfined.
You can set this with the following argument via the official Helm chart:

--set gremlin.apparmor=unconfined

3. Qdisc handle parsing on high-churn nodes

Agent version 2.70.6+ is recommended to avoid a bug in reporting conflicts with existing Cilium rules.

Please note that GKE Autopilot has additional installation considerations, including the application of an allowlist to allow Gremlin the Linux capabilities it requires to function effectively.