Merge pull request #6193 from xiang90/gw

docs: add gateway

Documentation/docs.md

@@ -21,7 +21,8 @@ The easiest way to get started using etcd as a distributed key-value store is to
 
 Administrators who need to create reliable and scalable key-value stores for the developers they support should begin with a [cluster on multiple machines][clustering].
 
- - [Setting up clusters][clustering]
+ - [Setting up etcd clusters][clustering]
+ - [Setting up etcd gateways][gateway]
  - [Run etcd clusters inside containers][container]
  - [Configuration][conf]
  - [Security][security]
@@ -59,6 +60,7 @@ To learn more about the concepts and internals behind etcd, read the following p
 [download_build]: dl_build.md
 [embed_etcd]: https://godoc.org/github.com/coreos/etcd/embed
 [failures]: op-guide/failures.md
+[gateway]: op-guide/gateway.md
 [glossary]: learning/glossary.md
 [interacting]: dev-guide/interacting_v3.md
 [local_cluster]: dev-guide/local_cluster.md

Documentation/op-guide/clustering.md

@@ -456,6 +456,10 @@ $ etcd --name infra2 \
 --listen-peer-urls http://10.0.1.12:2380
 ```
 
+### Gateway
+
+etcd gateway is a simple TCP proxy that forwards network data to the etcd cluster. Please read [gateway guide] for more information.
+
 ### Proxy
 
 When the `--proxy` flag is set, etcd runs in [proxy mode][proxy]. This proxy mode only supports the etcd v2 API; there are no plans to support the v3 API. Instead, for v3 API support, there will be a new proxy with enhanced features following the etcd 3.0 release.
@@ -472,3 +476,4 @@ To setup an etcd cluster with proxies of v2 API, please read the the [clustering
 [clustering_etcd2]: https://github.com/coreos/etcd/blob/release-2.3/Documentation/clustering.md
 [security-guide]: security.md
 [tls-setup]: /hack/tls-setup
+[gateway]: gateway.md

Documentation/op-guide/gateway.md

@@ -0,0 +1,66 @@
+# etcd gateway
+
+## What is etcd gateway
+
+etcd gateway is a simple TCP proxy that forwards network data to the etcd cluster. The gateway is stateless and transparent; it neither inspects client requests nor interferes with cluster responses.
+
+The gateway supports multiple etcd server endpoints. When the gateway starts, it randomly picks one etcd server endpoint and forwards all requests to that endpoint. This endpoint serves all requests until the gateway detects a network failure. If the gateway detects an endpoint failure, it will switch to a different endpoint, if available, to hide failures from its clients. Other retry policies, such as weighted round-robin, may be supported in the future.
+
+## When to use etcd gateway
+
+Every application that accesses etcd must first have the address of an etcd cluster client endpoint. If multiple applications on the same server access the same etcd cluster, every application still needs to know the advertised client endpoints of the etcd cluster. If the etcd cluster is reconfigured to have different endpoints, every application may also need to update its endpoint list. This wide-scale reconfiguration is both tedious and error prone.
+
+etcd gateway solves this problem by serving as a stable local endpoint. A typical etcd gateway configuration has 
+each machine running a gateway listening on a local address and every etcd application connecting to its local gateway. The upshot is only the gateway needs to update its endpoints instead of updating each and every application.
+
+In summary, to automatically propagate cluster endpoint changes, the etcd gateway runs on every machine serving multiple applications accessing same etcd cluster.
+
+## When not to use etcd gateway
+
+- Improving performance
+
+The gateway is not designed for improving etcd cluster performance. It does not provide caching, watch coalescing or batching. The etcd team is developing a caching proxy designed for improving cluster scalability. 
+
+- Running on a cluster management system
+
+Advanced cluster management systems like Kubernetes natively support service discovery. Applications can access an etcd cluster with a DNS name or a virtual IP address managed by the system. For example, kube-proxy is equivalent to etcd gateway.
+
+## Start etcd gateway
+
+Consider an etcd cluster with the following static endpoints:
+
+|Name|Address|Hostname|
+|------|---------|------------------|
+|infra0|10.0.1.10|infra0.example.com|
+|infra1|10.0.1.11|infra1.example.com|
+|infra2|10.0.1.12|infra2.example.com|
+
+Start the etcd gateway to use these static endpoints with the command:
+
+```bash
+$ etcd gateway start --endpoints=infra0.example.com,infra1.example.com,infra2.example.com
+2016-08-16 11:21:18.867350 I | tcpproxy: ready to proxy client requests to [...]
+```
+
+Alternatively, if using DNS for service discovery, consider the DNS SRV entries:
+
+```bash
+$ dig +noall +answer SRV _etcd-client._tcp.example.com
+_etcd-client._tcp.example.com. 300 IN SRV 0 0 2379 infra0.example.com.
+_etcd-client._tcp.example.com. 300 IN SRV 0 0 2379 infra1.example.com.
+_etcd-client._tcp.example.com. 300 IN SRV 0 0 2379 infra2.example.com.
+```
+
+```bash
+$ dig +noall +answer infra0.example.com infra1.example.com infra2.example.com
+infra0.example.com.  300  IN  A  10.0.1.10
+infra1.example.com.  300  IN  A  10.0.1.11
+infra2.example.com.  300  IN  A  10.0.1.12
+```
+
+Start the etcd gateway to fetch the endpoints from the DNS SRV entries with the command:
+
+```bash
+$ etcd gateway --discovery-srv=example.com
+2016-08-16 11:21:18.867350 I | tcpproxy: ready to proxy client requests to [...]
+```