Access Sidecar Admin Interface in Grey Matter on Kubernetes
Because the Sidecar admin interface can contain sensitive information and allows users to manipulate the sidecar, access is not routed through the mesh. In a Grey Matter deployment, access is locked down and only accessible by admin users who have direct access to the pod.
This guide is a step by step walkthrough on how to access a Sidecar's admin interface. This interface is used to both inspect and operate on the running server; doing tasks like inspecting stats or performing a hard shut-down. In this walkthrough, we'll perform the following common tasks:
Prerequisites
An existing Grey Matter deployment running on Kubernetes (tutorial)
kubectlorocsetup with access to the cluster
NOTE, the operations on the admin server do not depend on the platform in use. Since this guide is focused on Kubernetes, we'll use
kubectlfor access to the server. On other platforms, tools likesshsessions can be used instead.
Steps
For all examples shown here, the Sidecar's admin server has been started on port 8001. This is the default for Grey Matter deployments.
1. Establish a Session
The first step is to establish a session inside the pod we need to examine. For this walkthrough, lets look at the edge service. To do this, we'll need the POD ID for any edge nodes in the deployment:
$ kubectl get pods | grep edge
edge-7d7bf848b9-xjs5l 1/1 Running 0 114mWe can see we have one edge pod with an ID of edge-7d7bf848b9-xjs5l. We'll now use the kubectl tool to start a shell inside that pod. After running the command below, you'll be left off with a shell inside the container.
Now that we're in the pod, we can run commands against the admin interface. Here we'll use the curl to send commands since it's widely available and installed by default on Grey Matter docker images.
2. General Admin Commands
To see the full list of endpoints available, send a GET request to the /help endpoint. Full descriptions of each can be found in the Envoy docs.
In the next 3 sections, we'll show sample usage of the /stats and /config_dump endpoints.
2. Stats
The /stats endpoint is used to output all of the collected statistics. The first ~30 lines are shown below, but the full output is much larger and is dependent on the exact configuration of the sidecar being examined. For each new filter, listener, or cluster that is configured, new stats will be output. The stats will also be different depending on each connection type, e.g. http or MongoDB.
To query just a subset of the stats, use the filter query parameter:
or
3. Configuration Dump
Next we'll dump out the entire configuration of the Sidecar. The output of this command is routinely many thousands of lines long, but is very useful to inspect the exact state of a sidecar at any given moment. This config is mostly useful for verifying the exact behavior of the sidecar against what was intended.
5. Exit
Type exit in the terminal to return to drop the connection to the pod and return to your local shell.
Last updated
Was this helpful?