Mirrors/coredns
1
0
Fork 0
mirror of https://github.com/coredns/coredns.git synced 2025-10-28 08:44:17 -04:00
Code Issues Packages Projects Releases Wiki Activity

Update and specificy metadata and locality

Browse Source 
Signed-off-by: Miek Gieben <miek@miek.nl>
This commit is contained in:
Miek Gieben
2020-01-23 15:36:09 +01:00
parent 39f6ca5d5a
commit 6a9dc85c10
1 changed files with 26 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

31
plugin/traffic/README.md
View File

@@ -34,10 +34,6 @@ enough to select the best one. When SRV records are returned, the endpoint DNS n
`endpoint-<N>.<cluster>.<zone>` that carries the IP address. Querying for these synthesized names `endpoint-<N>.<cluster>.<zone>` that carries the IP address. Querying for these synthesized names
works as well. works as well.
The *traffic* plugin has no notion of draining, drop overload and anything that advanced, *it just
acts upon assignments*. This is means that if a endpoint goes down and *traffic* has not seen a new
assignment yet, it will still include this endpoint address in responses.
Load reporting is not supported for the following reason. A DNS query is done by a resolver. Load reporting is not supported for the following reason. A DNS query is done by a resolver.
Behind this resolver (which can also cache) there may be many clients that will use this reply. The Behind this resolver (which can also cache) there may be many clients that will use this reply. The
responding server (CoreDNS) has no idea how many clients use this resolver. So reporting a load of responding server (CoreDNS) has no idea how many clients use this resolver. So reporting a load of
@@ -70,7 +66,7 @@ traffic TO... {
* `node` **ID** is how *traffic* identifies itself to the control plane. This defaults to `coredns`. * `node` **ID** is how *traffic* identifies itself to the control plane. This defaults to `coredns`.
* `locality` has a list of **REGION,ZONE,SUBZONE**s. These tell *traffic* where its running and what should be * `locality` has a list of **REGION,ZONE,SUBZONE**s. These tell *traffic* where its running and what should be
considered local traffic. Each **REGION,ZONE,SUBZONE** will be used to match clusters again while generating considered local traffic. Each **REGION,ZONE,SUBZONE** will be used to match clusters again while generating
responses. The list should descend in proximity. A `*` describes a wildcard match. I.e. when responses. The list should descend in proximity. A `*` describes a wild card match. I.e. when
there are 3 regions, US, EU, ASIA, and this CoreDNS is running in EU, you can use: there are 3 regions, US, EU, ASIA, and this CoreDNS is running in EU, you can use:
`locality EU,*,* US,*,*, ASIA,*,*`. Only when the cluster's locality isn't UNKNOWN will this `locality EU,*,* US,*,*, ASIA,*,*`. Only when the cluster's locality isn't UNKNOWN will this
matching happen. matching happen.
@@ -96,6 +92,31 @@ domain names. For example if the Server Block specifies `lb.example.org` as one
and "cluster-v0" is one of the load balanced cluster, *traffic* will respond to query asking for and "cluster-v0" is one of the load balanced cluster, *traffic* will respond to query asking for
`cluster-v0.lb.example.org.` and the same goes for `web`; `web.lb.example.org`. `cluster-v0.lb.example.org.` and the same goes for `web`; `web.lb.example.org`.
## Localized Endpoints
Endpoints can be grouped by location, this location information is used if the `locality` property
is used in the configuration.
## Matching Algorithm
How are clients match against the data we receive from xDS endpoint? Ignoring `locality` for now,
it will go through the following steps:
1. Does the cluster exist? If not return NXDOMAIN, otherwise continue.
2. Check the cluster's metadata, if available and set to DRAINING, return a NODATA response,
otherwise continue.
3. Run through the endpoints, discard any endpoints that are not HEALTHY. If we are left with no
endpoint return a NODATA response, otherwise continue.
4. If weights are assigned use those to pick an endpoint, otherwise randomly pick one and return a
response to the client.
If `locality` *has* been specified there is an extra step between 3 and 4.
3a. Match the endpoints using the locality that groups several of them, it's the most specific match
from left to right in the `locality` list; if no **REGION,ZONE,SUBZONE** matches then try
**REGION,ZONE** and then **REGION**. If still not match, move on the to next one. If we found
none, we continue with step 4 above, ignoring any locality.
## Metrics ## Metrics
If monitoring is enabled (via the *prometheus* plugin) then the following metric are exported: If monitoring is enabled (via the *prometheus* plugin) then the following metric are exported: