Network Tags

What are tags?

Tags are metadata or labels attached to an object, such as a host, container, or Kubernetes resource. Each tag has a key and an optional value. This can make it easier to manage, search for, and filter resources by specific criteria.

Tags are commonly used to identify applications, environments (staging or production), owners, and so on. For example, you could tag all API services with an API tag, or tag all services where Terraform automation is used with a Terraform tag. Tags are especially important for today's ephemeral environments, where resources (like hosts and containers) live for a short time and have dynamic IP addresses. The IP address of a host may change, but any tags associated with it will persist.

‍

How does Gremlin use tags?

Gremlin recognizes host, cloud, and Kubernetes tags to define the scope of what to evaluate during reliability testing. For example, you might want to test the reliability of a Service running on a certain operating system or in a specific zone.

In Kubernetes, tags are known as labels. Using labels will help you match deployments with Services in Gremlin. For more information on Kubernetes labels, see Labels and Selectors.

Cloud providers generally have a set of default tags. Be aware that some cloud providers have a limit on the number of tags you can apply. For more information on cloud tags, see:

• AWS: Tagging AWS resources
• Azure: Use tags to organize your Azure resources and management hierarchy
• Google Cloud: Google Tags

If you are not using a cloud provider, you will need to define custom tags and be familiar with them when you create a Service in Gremlin. You will also need to assign your custom tags to the Gremlin Agent.

Examples of tags in Gremlin

In the following example for a host Service, the scope of testing will cover the following zones: us-east-1a , us-east-1b , and us-east-1c.

In this example for a Kubernetes Service, the accounts-db StatefulSet will be used to define the scope of testing.

Using tags to define network arguments

For network experiments, you can also supply tag key-value pairs as arguments, which are translated to IP address values that are included in the network experiment. Gremlin finds all agents matching the supplied tags, and pulls the IP addresses associated with those agents into the network experiment. This is a powerful way to dynamically supply IP addresses to network experiments.

The zone tag

When used as a network tag argument, the zone tag provides additional IP addresses to a given experiment to facilitate a complete availability-zone impact:

• The IP address ranges specified by automatic tags of agents that match the supplied zone tag value: zone-cidrs-ipv4 , zone-cidrs-ipv6 , pod-cidrs-ipv4 , pod-cidrs-ipv6
• Custom IP address ranges defined in Company > Options > Zone Definitions that match the supplied zone tag value

The zone tag is used as a primary targeting mechanism of Gremlin's Redundancy: Zone reliability test.

Automatic IP address ranges for the zone network tag

Since Linux version 2.65.0 and Windows version 1.27.0, the gremlind process sends up the following tag values when they are detected:

• zone-cidrs-ipv4: IPv4 address ranges (e.g. 10.0.2.0/24) associated with the network device on which Gremlin is installed
  
• zone-cidrs-ipv6: IPv6 address ranges (e.g. 2001:db8::/128) associated with the network device on which Gremlin is installed
• ‍pod-cidrs-ipv4: IPv4 address ranges (e.g. 10.0.2.0/24) associated with the pod network of the Node on which Gremlin is installed‍
  
• pod-cidrs-ipv6: IPv6 address ranges (e.g. 2001:db8::/128) associated with the pod network of the Node on which Gremlin is installed

Gremlin will automatically detect these IP address ranges on the following platforms:

• Amazon Web Services
• Google Cloud
• Kubernetes installations using podCIDR definitions in their NodeSpec
• Kubernetes installations using the OVN Kubernetes CNI
• Kubernetes installations using the Cilium CNI

For unsupported platforms, you may set these tag values like you would a custom tag, or request support for your platform.

Disabling automatic IP address ranges for the zone network tag

Gremlin does not recommend disabling automatic IP address ranges, as it can lead to incomplete network impacts for tests involving the zone network tag, such as Gremlin's Redundancy: Zone reliability test. However, omitting this behavior can be done by disabling the publishing of the IP address ranges.

For Helm users (chart version 0.24.3)

Install the Gremlin Helm chart, setting the value: gremlin.features.pushCIDRTags.enabled=false

For all other container users (Kubernetes non-Helm, ECS, etc.)

Pass environment variables to the gremlin container:

- name: GREMLIN_PUSH_POD_CIDR_TAGS
  value: "false"
- name: GREMLIN_PUSH_ZONE_CIDR_TAGS
  value: "false"

For all non-container users

Set the following two attributes in Gremlin's config.yaml file

push_pod_cidr_tags: false
push_zone_cidr_tags: false

Assigning custom tags

Gremlin automatically pulls in Kubernetes, cloud tags, and common host tags such as <span class="code-class-custom">operating system</span>. For custom tags, you will need to assign them to the Gremlin Agent. There are 2 ways to assign your custom tags to the Gremlin Agent:

• Use the Gremlin configuration file (config.yaml)
• Use an environment variable

Using the Gremlin configuration file

Use the <span class="code-class-custom">tags</span> variable in config.yaml. For example:

tags:
  service: pet-store
  interface: http

‍

See Configuring the Gremlin agent for more information.

Using an environment variable

Use the GREMLIN_CLIENT_TAGS variable to assign custom tags, separated by comma, to the Gremlin Agent.

For example:

GREMLIN_CLIENT_TAGS="zone=us-east1,role=mysql,foo=bar"

See Using environment variables for more information.