Until now, any Gremlin experiment against a container or Kubernetes object target required that api.gremlin.com be accessible to that target (via proxy or otherwise). This made Gremlin installations challenging for environments where the network is restricted. For example, administrators of OpenShift environments will use a NetworkPolicy to restrict egress traffic from application pods that do not need any network access.

With Linux version 2.30.3, Gremlin no longer requires this network access from its targets when the environment variable GREMLIN_TRANSPORT=domain-socket is supplied to the gremlind agent process.

Try it out

To enable this behavior on an existing Kubernetes cluster, ensure you have at least version 2.30.3 installed, then enable the behavior by setting the environment variable:

1# Command assumes Gremlin is installed in the `gremlin` namespace
2kubectl set env daemonset/gremlin -n gremlin GREMLIN_TRANSPORT=domain-socket

To disable this behavior, simply remove the environment variable, or clear its value.

How it works

Prior to this change, you can visualize Gremlin's network activity as two parallel TCP streams:

1gremlin  <--HTTP/TCP--> control plane
2gremlind <--HTTP/TCP--> control plane

With GREMLIN_TRANSPORT=domain-socket, the gremlin experiment sidecar now routes its traffic to the gremlind agent process via a unix domain socket (unix(7)), before it is ultimately sent to api.gremlin.com.

1gremlin  <--HTTP/UNIX--> gremlind <--HTTP/TCP--> control plane