doc updates

Signed-off-by: Miek Gieben <miek@miek.nl>
This commit is contained in:
Miek Gieben
2020-02-07 13:28:10 +01:00
parent 72dac14b48
commit 885514b670
2 changed files with 7 additions and 55 deletions

View File

@@ -1,54 +0,0 @@
# Hacking on *traffic*
Repos used:
<https://github.com/envoyproxy/go-control-plane>
: implements control plane, has testing stuff in pkg/test/main (iirc).
<https://github.com/grpc/grpc-go/tree/master/xds/internal/client>
: implements client for xDS - much of this code has been reused here.
I found these website useful while working on this.
* https://github.com/envoyproxy/envoy/blob/master/api/API_OVERVIEW.md
* https://github.com/envoyproxy/learnenvoy/blob/master/_articles/service-discovery.md
* This was *really* helpful: https://www.envoyproxy.io/docs/envoy/v1.11.2/api-docs/xds_protocol to
show the flow of the protocol.
# Testing
Assuming you have envoyproxy/go-control-plane checked out somewhere, then:
~~~ sh
% cd ~/src/github.com/envoyproxy/go-control-plane/pkg/test/main
% go build
% ./main --xds=ads --runtimes=2 -debug
~~~
This runs a binary from pkg/test/main. Now we're testing aDS. Everything is using gRPC with TLS
disabled: `grpc.WithInsecure()`. The test binary runs on port 18000 on localhost; all these things
are currently hardcoded in the *traffic* plugin. This will be factored out into config as some
point. Another thing that is hardcoded is the use of the "example.org" domain.
Then for CoreDNS, check out the `traffic` branch, create a Corefile:
~~~ Corefile
example.org {
traffic grpc://127.0.0.1:18000 {
id test-id
ignore_health
}
debug
}
~~~
You'll need `ignore_health` because the test binary sets the health status to UNKNOWN and this would
mean CoreDNS doesn't return any (useful) data.
Start CoreDNS (`coredns -conf Corefile -dns.port=1053`), and see logging/debugging flow by; the
test binary should also spew out a bunch of things. CoreDNS willl build up a list of cluster and
endpoints. Next you can query it. Note none of the endpoints are HEALTHY so you'll mostly get NODATA
responses, instead of actual records.
Note: the xds/test binary is a go-control-plane binary with added debugging that I'm using for
testing.

View File

@@ -41,7 +41,8 @@ responding server (CoreDNS) has no idea how many clients use this resolver. So r
+1 on the CoreDNS side can results in anything from 1 to 1000+ of queries on the endpoint, making
the load reporting from *traffic* highly inaccurate.
*Traffic* implements version 3 of the xDS API.
*Traffic* implements version 3 of the xDS API. It works with the management server as written in
<https://github.com/miekg/xds>.
## Syntax
@@ -162,3 +163,8 @@ localhost on port 18000. The node ID will be `test-id` and no TLS will be used.
Priority and locality information from ClusterLoadAssignments is not used. Multiple **TO** addresses
is not implemented. Credentials are not implemented.
## Also See
A Envoy management server and command line interface can be found on
[GitHub](https://github.com/miekg/xds).