‍

Until now, any Gremlin experiment against a container or Kubernetes object target required that <span class="code-class-custom">api.gremlin.com</span> 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 <span class="code-class-custom">GREMLIN_TRANSPORT=domain-socket</span> is supplied to the <span class="code-class-custom">gremlind</span> agent process.

Try it out

To enable this behavior on an existing Kubernetes cluster, ensure you have at least version <span class="code-class-custom">2.30.3</span> installed, then enable the behavior by setting the environment variable:

# Command assumes Gremlin is installed in the `gremlin` namespace
kubectl 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:

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

‍

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

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