Gremlin can inject fault into targets running on any infrastructure environment whether it be an EC2 instance on Amazon Web Services, a droplet in DigitalOcean, or a bare metal server in your own data center.

With your hosts registered to the Gremlin Control Plane, users can create attacks targeting either hosts or containers in your environment.

Hosts

Clients (hosts or cluster nodes) registered to the Gremlin Control Plane will show as active targets available for attacks. In the Web UI, users can filter selected hosts based on their tags, and select individual hosts by their Identifier, in order to run attacks and inject fault into targeted hosts.

In a container environment, when users select hosts as targets to run attacks, the resulting attack is scoped at the host level with the potential to affect anything (processes, containers, etc.) on the host. Users are encouraged to minimize the blast radius of their attacks via attack parameters (network device, port, etc.).

Cloud Tagging

As of version 2.11.6 the Gremlin client supports automatic tagging of all hosts running in the three major cloud providers. If the Gremlin client is able to detect and parse cloud metadata it will automatically append specific attributes to the host in the form of tags. This allows users to easily utilize cloud metadata to target particular sections of their infrastructure out of the box.

AWS

The following AWS metadata attributes are supported for automatic tagging.

• image-id
• instance-id
• instance-type
• local-hostname
• local-ip
• public-hostname
• public-ip
• region
• zone

Azure

The following Azure metadata attributes are supported for automatic tagging.

• azEnvironment
• location
• name
• osType
• privateIpAddress
• publicIpAddress
• sku
• vmId
• vmScaleSetName
• zone

GCP

The following GCP metadata attributes are supported for automatic tagging.

• hostname
• id
• image
• local-ip
• name
• public-ip
• zone

Containers

Container and pod labels are exposed in the Web UI. Users can individually select the container they wish to attack. By definition, containers of a Kubernetes Pod all share a namespace and cgroup. This means when Gremlin applies a network impact to one container within a Kubernetes pod, the impact will be observed for all containers in the Pod. Note that this does not apply to containers in Pod replicas. If you attack a specific Pod replica, the effect applies to containers within that replica only, and does not apply to the rest of the replicas.

It is always recommended to target only a single container of a Pod. If you wish to exclude some containers from the network impact, reduce your blast radius by specifying ports relevant to the containers you wish to see impact.

Exact vs Random

There are two ways to select targets when you create an attack, choosing the exact targets, or to randomly select some or all of the targets filtered by the supplied tags.

Exact selection offers a more deterministic behavior, knowing exactly which target host or container will be impacted.

Random selection helps introduce entropy, and produces a more realistic scenario of potential partial and probablistic failure on some targets. Random targets can be selected by count (M of N targets), or by percentage of fleet (X percent of total applicable targets).

Exact target selection uses Identifier as selection method while Random target selection takes advantage of tags. For automated scheduling of attacks in a dynamic environment, Random selection is preferred.