etcd gateway

Що таке etcd gateway

etcd gateway — це простий TCP-проксі, який пересилає мережеві дані до кластера etcd. Шлюз є stateless та прозорим; він не перевіряє запити клієнтів і не втручається у відповіді кластера. Він не термінує TLS-зʼєднання, не виконує TLS-рукостискання від імені своїх клієнтів і не перевіряє, чи є зʼєднання захищеним.

Шлюз підтримує кілька точок доступу сервера etcd і працює за простою політикою обходу по колу. Він маршрутизує лише до доступних точок доступу і приховує збої від своїх клієнтів. Інші політики повторних спроб, такі як зважений обхід по колу, можуть бути підтримані в майбутньому.

Коли використовувати etcd gateway

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

etcd gateway розвʼязує цю проблему, виступаючи як стабільна локальна точка доступу. Типова конфігурація шлюзу etcd передбачає запуск шлюзу на кожній машині, що слухає на локальній адресі, і кожен застосунок etcd підключається до свого локального шлюзу. Перевага полягає в тому, що лише шлюз потребує оновлення своїх точок доступу замість оновлення кожного застосунку.

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

Коли не використовувати etcd gateway

• Поліпшення продуктивності

  Шлюз не призначений для поліпшення продуктивності кластера etcd. Він не забезпечує кешування, обʼєднання спостережень або пакетування. Команда etcd розробляє кешуючий проксі, призначений для поліпшення масштабованості кластера.

• Запуск у системі управління кластером

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

Запуск etcd gateway

Розглянемо кластер etcd з наступними статичними точками доступу:

Запустіть шлюз etcd для використання цих статичних точок доступу за допомогою команди:

$ 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:

$ 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.

$ 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 за допомогою команди:

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

Прапорці конфігурації

Кластер etcd

--endpoints

• Список точок доступу сервера etcd, розділених комами, для пересилання клієнтських зʼєднань.
• Стандартно: 127.0.0.1:2379
• Порт повинен бути включений.
• Неправильний приклад: https://127.0.0.1:2379 (шлюз не термінує TLS). Зверніть увагу, що шлюз не перевіряє схему HTTP або запити, він лише пересилає запити до вказаних точок доступу.

--discovery-srv

• Домен DNS, що використовується для завантаження точок доступу кластера через записи SRV.
• Стандартно: (не встановлено)

Мережа

--listen-addr

• Інтерфейс і порт для приймання клієнтських запитів.
• Стандартно: 127.0.0.1:23790

--retry-delay

• Тривалість затримки перед повторною спробою підключення до невдалих точок доступу.
• Стандартно: 1m0s
• Неправильний приклад: “123” (очікується одиниця часу у форматі)

Безпека

--insecure-discovery

• Приймати записи SRV, які є небезпечними або вразливими до атак типу “особа посередині”.
• Стандартно: false

--trusted-ca-file

• Шлях до файлу TLS CA клієнта для кластера etcd для перевірки точок доступу, повернутих з виявлення SRV. Зверніть увагу, що він використовується ТІЛЬКИ для автентифікації виявлених точок доступу, а не для створення зʼєднань для передачі даних. Шлюз ніколи не завершує TLS-зʼєднання або не створює TLS-зʼєднання від імені своїх клієнтів.
• Стандартно: (не встановлено)