# Шлюз etcd

> Назначение, сценарии применения и настройка шлюза etcd

---

Индекс LLMS: [llms.txt](/ru/llms.txt)

---

## Что такое шлюз etcd {#what-is-etcd-gateway}

Шлюз etcd — простой TCP-прокси, пересылающий сетевые данные кластеру etcd. Шлюз не хранит состояния и работает прозрачно: он не анализирует клиентские запросы и не вмешивается в ответы кластера. Он не завершает TLS-соединения, не выполняет TLS-рукопожатия от имени клиентов и не проверяет защищённость соединения.

Шлюз поддерживает несколько конечных точек серверов etcd и использует простую циклическую политику. Он направляет трафик только доступным конечным точкам и скрывает от клиентов отказы. В будущем могут появиться другие политики повторных попыток, например взвешенная циклическая.

## Когда следует использовать шлюз etcd {#when-to-use-etcd-gateway}

Каждому приложению для доступа к etcd сначала требуется адрес клиентской конечной точки кластера. Если несколько приложений на одном сервере обращаются к одному кластеру etcd, каждое из них всё равно должно знать объявленные клиентские конечные точки. При изменении конечных точек кластера списки, возможно, придётся обновить во всех приложениях. Такая массовая перенастройка трудоёмка и подвержена ошибкам.

Шлюз etcd решает эту проблему, предоставляя стабильную локальную конечную точку. В типичной конфигурации на каждой машине работает шлюз, слушающий локальный адрес, а все приложения etcd подключаются к нему. Поэтому при изменении кластера достаточно обновить конечные точки шлюза, а не каждого приложения.

Итак, для автоматического распространения изменений конечных точек кластера шлюз etcd запускается на каждой машине, где несколько приложений обращаются к одному кластеру etcd.

## Когда не следует использовать шлюз etcd {#when-not-to-use-etcd-gateway}

- Повышение производительности

Шлюз не предназначен для повышения производительности кластера etcd. Он не кэширует данные, не объединяет наблюдения и не пакетирует запросы. Команда etcd разрабатывает кэширующий прокси для улучшения масштабируемости кластера.

- Работа в системе управления кластером

Развитые системы управления кластерами, такие как Kubernetes, изначально поддерживают обнаружение служб. Приложения могут обращаться к кластеру etcd по DNS-имени или виртуальному IP-адресу, управляемому системой. Например, kube-proxy выполняет ту же роль, что и шлюз etcd.

## Запуск шлюза etcd {#start-etcd-gateway}

Рассмотрим кластер etcd со следующими статическими конечными точками:

|Имя|Адрес|Имя узла|Порт|
|------|---------|------------------|----|
|infra0|10.0.1.10|infra0.example.com|2379|
|infra1|10.0.1.11|infra1.example.com|2379|
|infra2|10.0.1.12|infra2.example.com|2379|

Запустите шлюз etcd с этими статическими конечными точками:

```bash
$ etcd gateway start --endpoints=infra0.example.com:2379,infra1.example.com:2379,infra2.example.com:2379
2016-08-16 11:21:18.867350 I | tcpproxy: ready to proxy client requests to [...]
```

При обнаружении служб через DNS рассмотрим следующие записи DNS SRV:

```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
```

Запустите шлюз etcd, чтобы получить конечные точки из записей DNS SRV:

```bash
$ etcd gateway start --discovery-srv=example.com
2016-08-16 11:21:18.867350 I | tcpproxy: ready to proxy client requests to [...]
```

## Флаги конфигурации {#configuration-flags}

### Кластер etcd {#etcd-cluster}

#### --endpoints {#endpoints}

 * Разделённый запятыми список целевых серверов etcd, которым пересылаются клиентские соединения.
 * По умолчанию: `127.0.0.1:2379`
 * Порт обязателен.
 * Недопустимый пример: `https://127.0.0.1:2379` (шлюз не завершает TLS). Шлюз не проверяет схему HTTP и не анализирует запросы, а только пересылает их заданным конечным точкам.

#### --discovery-srv {#discovery-srv}

 * Домен DNS для начальной загрузки конечных точек кластера через записи SRV.
 * По умолчанию: не задано

### Сеть {#network}

#### --listen-addr {#listen-addr}

 * Интерфейс и порт для привязки и приёма клиентских запросов.
 * По умолчанию: `127.0.0.1:23790`

#### --retry-delay {#retry-delay}

 * Задержка перед повторной попыткой подключения к недоступным конечным точкам.
 * По умолчанию: 1m0s
 * Недопустимый пример: "123" (ожидается единица времени)

### Безопасность {#security}

#### --insecure-discovery {#insecure-discovery}

 * Принимать небезопасные или уязвимые для атак посредника записи SRV.
 * По умолчанию: `false`

#### --trusted-ca-file {#trusted-ca-file}

 * Путь к клиентскому файлу центра сертификации TLS, с помощью которого кластер etcd проверяет конечные точки, полученные при обнаружении SRV. Он используется ТОЛЬКО для аутентификации обнаруженных конечных точек, а не для создания соединений передачи данных. Шлюз никогда не завершает TLS-соединения и не создаёт их от имени клиентов.
 * По умолчанию: не задано