mirror of
https://github.com/coredns/coredns.git
synced 2025-11-28 14:44:12 -05:00
@@ -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.
|
||||
@@ -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).
|
||||
|
||||
Reference in New Issue
Block a user