The handshake
Four properties fall out of this shape, and they are the reason it looks like this:- No session to maintain. The Sidecar loads its configuration into memory and keeps running. A Control Plane that goes down does not take running Sidecars with it.
- The token is the authentication. There is no second credential and no certificate exchange.
- Ordinary HTTP. A plain request and a plain response. Nothing is tunnelled and nothing bidirectional stays open.
- Neither side knows the other’s physical address. The Sidecar dials out; the Control Plane never dials in. No inbound firewall rule, no NAT traversal.
Steps
1
Issue a token in the Control Plane
Create a Sidecar registration and copy the token it returns. The token identifies this Sidecar and authenticates it — treat it as a credential.
2
Point the Sidecar at the Control Plane
Add the server host and token to the Sidecar’s config file:Or supply them through the environment, which is the shape a Kubernetes deployment wants — mount the secret, set the variables, pass no arguments:
config.yaml
3
Start it
4
Confirm what it resolved
The admin API reports the merged, live configuration. This is the only place you can see what the Sidecar actually ended up running:The Sidecar should also appear in the Control Plane’s list, with a recent check-in.
Troubleshooting
Next
Control Plane
What it manages and why the protocol is this simple.
Install the Control Plane
Docker Compose, Kubernetes and AWS.