Grey Matter Control
The Control server performs service discovery in the mesh and acts as the Envoy xDS server to which all proxies connect. Service discovery can be performed through a variety of mechanisms.
Usage
The Control server runs on a number of different platforms and supports a variety of discovery mechanisms. Each one has its own configuration options, the details of which are outlined in the usage documentation.
For all commands, both CLI flags and environment variables are supported. If both are used, then CLI flags take precedence. Each flag listed in the docs (or gm-control <command> --help), will also be accepted as en environment variable of the form GM_CONTROL_<COMMAND>_<FLAG>. E.g.: the --namespace flag on the kubernetes command would be set in the environment as GM_CONTROL_KUBERNETES_NAMESPACE
Additional Features
Deployment Patterns
Grey Matter Control is a stateless microservice, and supports scaling to whatever size cluster is required. If a Control server goes offline, the data plane (connected mesh of Sidecars) will continue to function, but without any updates from new configuration or changed instances. When a new Control instance is brought up it will read the current state of Sidecar instances through service discovery and the current configuration for the mesh from gm-control-api to get back to the original state (or new state, if either has progressed since).
\Memory Utilization Requirements
Each Control server requires ~1.25MB of memory per connected sidecar. This should be reflected in any enforced memory limits to prevent server restart due to OOM errors.
Single-Node Deployment
In a single-node deployment, the one gm-control instance will do service discovery, read mesh configuration from gm-control-api, and serve data plane configuration to all Sidecars in the mesh.
N-Node Deployment
When multiple Control servers are deployed, they should be provisioned behind a Load Balancer. This will distribute the load of connected Sidecars across all instances of the service, making each one responsible for serving configs out to only a fraction of the data plane.
Even with multiple Control servers, each one still independently performs service discovery and reading mesh configuration from gm-control-api. This allows each gm-control node to see the mesh in it's entirety, and to take over control of additional sidecars should a node go down. If this does happen, existing sidecars will shift their connection to a live instance and continue to receive data plane updates.
Multiple server deployment for mixed service discovery
Multiple Control servers can also be deployed to use multiple different service discovery mechanisms for a single mesh. This allows services from different environments to be discovered and interact with each other.
In this use case, no load balancer will be used, because each Control server will operate independently of any other(s), connecting to the same Grey Matter Control API.
Dependencies and Requirements
Version
Dependency Name
Dependency Version
1.x
gm-control-api
1.x
gm-control can stream valid instructions to envoy-compatible proxies of v1.x
Last updated
Was this helpful?