etcd官方文档中文版
  • Introduction
  • 官方文档
    • 开发指南
      • 搭建本地集群
      • 和 etcd 交互
      • 核心 API 参考文档
      • 并发 API 参考文档
      • gRPC 网关
      • gRPC 命名和发现
      • 试验性的 API 和特性
      • 系统限制
    • 运维指南
      • 搭建 etcd 集群
        • 运行时重配置
        • 运行时重配置的设计
      • 搭建 etcd 网关
      • 在容器内运行 etcd 集群
      • 配置
      • gRPC代理(TBD)
      • L4 网关
      • 支持平台
      • 硬件推荐(TBD)
      • 性能评测
      • 调优(TBD)
      • 安全模式
      • 基于角色的访问控制(TBD)
      • 常见问题(TBD)
      • 监控(TBD)
      • 维护
      • 理解失败
      • 灾难恢复
      • 版本
    • 学习
      • 为什么是etcd
      • 理解数据模型
      • 理解API
      • 术语
      • API保证
      • 认证子系统(TBD)
  • 核心 API 参考文档
    • KV service
      • Range方法
      • Put方法
      • DeleteRange方法
      • Txn方法
      • Compact方法
    • Watch service
      • Watch方法
    • Lease service
      • LeaseGrant方法
      • LeaseRevoke方法
      • LeaseKeepAlive方法
      • LeaseTimeToLive方法
  • 并发 API 参考文档
    • Lock service
      • Lock方法
      • Unlock方法
    • Election service
      • Campaign方法
      • Proclaim方法
      • Leader方法
      • Observe方法
      • Resign方法
  • 全文标签总览
Powered by GitBook
On this page
  • Scalable watch API
  • Limitations
  • Scalable lease API
  • Abusive clients protection
  • Start etcd gRPC proxy
  1. 官方文档
  2. 运维指南

gRPC代理(TBD)

TBD!

This is a pre-alpha feature, we are looking for early feedback.

The gRPC proxy is a stateless etcd reverse proxy operating at the gRPC layer (L7). The proxy is designed to reduce the total processing load on the core etcd cluster. For horizontal scalability, it coalesces watch and lease API requests. To protect the cluster against abusive clients, it caches key range requests.

The gRPC proxy supports multiple etcd server endpoints. When the proxy starts, it randomly picks one etcd server endpoint to use. This endpoint serves all requests until the proxy detects an endpoint failure. If the gRPC proxy detects an endpoint failure, it switches 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.

Scalable watch API

The gRPC proxy coalesces multiple client watchers (c-watchers) on the same key or range into a single watcher (s-watcher) connected to an etcd server. The proxy broadcasts all events from the s-watcher to its c-watchers.

Assuming N clients watch the same key, one gRPC proxy can reduce the watch load on the etcd server from N to 1. Users can deploy multiple gRPC proxies to further distribute server load.

In the following example, three clients watch on key A. The gRPC proxy coalesces the three watchers, creating a single watcher attached to the etcd server.

            +-------------+
            | etcd server |
            +------+------+
                   ^ watch key A (s-watcher)
                   |
           +-------+-----+
           | gRPC proxy  | <-------+
           |             |         |
           ++-----+------+         |watch key A (c-watcher)
watch key A ^     ^ watch key A    |
(c-watcher) |     | (c-watcher)    |
    +-------+-+  ++--------+  +----+----+
    |  client |  |  client |  |  client |
    |         |  |         |  |         |
    +---------+  +---------+  +---------+

Limitations

To effectively coalesce multiple client watchers into a single watcher, the gRPC proxy coalesces new c-watchers into an existing s-watcher when possible. This coalesced s-watcher may be out of sync with the etcd server due to network delays or buffered undelivered events. When the watch revision is unspecified, the gRPC proxy will not guarantee the c-watcher will start watching from the most recent store revision. For example, if a client watches from an etcd server with revision 1000, that watcher will begin at revision 1000. If a client watches from the gRPC proxy, may begin watching from revision 990.

Similar limitations apply to cancellation. When the watcher is cancelled, the etcd server’s revision may be greater than the cancellation response revision.

These two limitations should not cause problems for most use cases. In the future, there may be additional options to force the watcher to bypass the gRPC proxy for more accurate revision responses.

Scalable lease API

TODO

Abusive clients protection

The gRPC proxy caches responses for requests when it does not break consistency requirements. This can protect the etcd server from abusive clients in tight for loops.

Start etcd gRPC proxy

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 gRPC proxy to use these static endpoints with the command:

$ etcd grpc-proxy start --endpoints=infra0.example.com,infra1.example.com,infra2.example.com --listen-addr=127.0.0.1:2379

The etcd gRPC proxy starts and listens on port 8080. It forwards client requests to one of the three endpoints provided above.

Sending requests through the proxy:

$ ETCDCTL_API=3 ./etcdctl --endpoints=127.0.0.1:2379 put foo bar
OK
$ ETCDCTL_API=3 ./etcdctl --endpoints=127.0.0.1:2379 get foo
foo
bar
Previous配置NextL4 网关

Last updated 6 years ago