Etcd ubuntu что это
Как установить etcd на Ubuntu 18.04 / Ubuntu 16.04
Etcd что это такое
Etcd – это простое, надежное, быстрое и безопасное хранилище ключей с открытым исходным кодом, написанное на Go.
Он использует алгоритм консенсуса Raft для управления реплицируемым журналом высокой доступности.
В этом руководстве мы установим один узел (один член) и т. д. В Ubuntu 18.04 / Ubuntu 16.04.
Установка etcd на Ubuntu 18.04 / Ubuntu 16.04
Etcd распространяется как бинарный пакет, хотя вы можете собрать его из исходного кода.
В этом руководстве мы собираемся скачать готовый двоичный пакет.
Проверьте предварительно собранные двоичные файлы выпуска, прежде чем продолжить, чтобы получить последний тег выпуска.
Загрузите последнюю версию etcd на Ubuntu 18.04 / Ubuntu 16.04:
Распакуйте скачанный архивный файл.
Перейдите в новый каталог файлов
Переместите двоичные файлы etcd и etcdctl в каталог /usr/local/bin.
Создайте конфигурационный файл Etcd и каталог данных.
Создайте системного пользователя etcd
Установите для /var/lib/etcd/ владельца пользователя etcd.
Настройте Systemd и запустите службу etcd
Создайте новый файл службы systemd для etcd.
Вставьте данные в файл.
Перезагрузите сервис systemd и запустите etcd на Ubuntu 18,04 / Ubuntu 16,04
Проверьте его статус
Служба запустится на локальный порт 2379
В нашем следующем уроке я расскажу о настройке кластера Etcd в Ubuntu 18.04 / Ubuntu 16.04.
Краткое введение в etcd
Во время моего романа с распределёнными приложениями etcd всегда был где-то неподалёку. То он был альтернативой Consul, когда я разбирался с сервис-дискавери и управлением конфигурациями. То etcd всплыл как основное хранилище настроек кластера в Kubernetes. В общем, он везде. Так что я думаю, стоит разобраться, на что же это за зверь такой.
Что такое etcd
etcd — это примитивное но при этом высоконадёжное распределённое хранилище для пар ключ-значение. «Примитивное» не значит, что тупое. Это просто значит что etcd фокусируется только на хранении и связанными с этим задачами. Ну и «высоконадёжный» и «распределённый» подразумевает, что если даже одна из кластера машин с etcd упадёт, то данными и кластером всё будет в порядке. По сравнению с тем же Consul фич тут будет поменьше, но в реальных задачах для того, чтобы забить гвоздь, отбойный молоток и не нужен.
Правда, то, что etcd просто хранит пары ключ-значение, не означает, что там всего три команды (get/set/remove) и на этом всё. Данные можно хранить по-разному, и etcd поддерживает и транзакции для работы с данными, и возможность отслеживать изменения, и настраивать пользователей с ролями, и всякие примитивы для синхронизации использовать, и даже даёт возможность установить время жизни значений (TTL).
В общем, будем смотреть.
Установка
Etcd поддерживает лучший из способов для установки — скачай-и-готово, и это прекрасно. Как всегда, я очень ленивый и параноидальный, поэтому вместо того, чтобы запускать временное и непонятно что на своей машине, я лучше напишу Vagrantfile с инструкциями для закачки и развёртывания, и получу готовую к надругиванию виртуальную с etcd внутри в одну команду.
По итогу, вот какой Vagrantfile у меня получился.
Как обслуживать etcd: несколько замечаний и советов
Если вы администрируете кластеры Kubernetes в своей инфраструктуре, а не используете версии, управляемые облачными провайдерами, то, скорее всего, уже управляете кластером etcd. Для тех, кому это внове, команда Kubernetes aaS от Mail.ru перевела статью о том, как обслуживать etcd.
Что такое etcd
Сначала разберемся с основами и определимся, что же такое etcd.
Итак, etcd — это простое распределенное хранилище вида ключ-значение, которое использует алгоритм консенсуса raft, чтобы обеспечить полную репликацию и высокую степень доступности.
Отличительная черта его стабильности — Kubernetes (сервер API) использует etcd в качестве хранилища ключ-значение для хранения состояния всего кластера. Kubernetes использует функцию etcd watch для мониторинга этих данных и для перенастройки кластера при возникновении изменений. Функция watch сравнивает значения, представляющие фактическое и желаемое состояние кластера, и может инициировать запрос, когда эти состояния различаются.
Что касается сравнения etcd с другими базами данных, такими как Redis, ZooKeeper или Consul, то это сравнение выходит за рамки этого поста. Здесь мы попытаемся перечислить несколько действий по обслуживанию производственных баз данных etcd, позволяющих сохранить их работоспособность.
Мониторинг
Первое, что необходимо сделать — добавить в мониторинг оповещения о работе etcd.
Вот конфигурационный файл для Alertmanager для оповещения о базовых событиях etcd:
Здесь мы будем описывать только те оповещения, которых нет в официальной документации etcd, где упоминается большинство важных оповещений. Единственное правило, на которое следует обратить внимание, помимо выбора лидера и процесса, — это размер базы данных. Оно не упоминается в официальном документе, так как настраивается индивидуально.
Хранилище etcd передает метрики в формате Prometheus. Мы добавим к метрикам свои метки, такие как окружение (environment), в котором работает виртуальная машина, как видно в настройках выше. Вы можете убрать эту метку, когда будете пробовать конфиг в Alertmanager.
Чтобы не закончилось место для записи, нужно сжимать историю ключей. Если место закончится, вы поймете это из ошибок, полученных из etcd.
Метрику etcd_debugging_mvcc_db_total_size_in_bytes_gauge отслеживать смысла нет, так как ее могут удалить в следующих выпусках etcd. Неплохо вообще не отслеживать метрики с *debugging* в имени метрики.
Сжатие
Поскольку доступное дисковое пространство ограничено, нужно освобождать место, занятое под историю пространства ключей, чего можно добиться с помощью сжатия.
Сжатие урезает журналы изменений для каждого ключа.
Обычно рекомендуется использовать один из следующих режимов автоматического сжатия:
Дефрагментация
Одного сжатия данных недостаточно для высвобождения дискового пространства, так как внутренняя база данных фрагментирована после сжатия. При сжатии устаревшие данные просто удаляются, оставляя пробелы в серверной базе данных, которые по-прежнему приводят к использованию дискового пространства. Для исправления этой ситуации запускается дефрагментация в базе данных etcd.
Дефрагментация удаляет незаполненные места в базе данных.
Сжатие + дефрагментация + правильный мониторинг — основа обслуживания вашего кластера etcd.
Следует отметить, что дефрагментация должна выполняться относительно нечасто, поскольку она всегда вызывает простой. Дефрагментация на работающем инстансе кластера блокирует чтение и запись в кластер, пока состояние кластера не будет перестроено.
Рекомендуется поддерживать небольшой размер базы данных — по умолчанию снова 2 ГБ. Чем больше размер базы данных, тем больше времени потребуется для дефрагментации. В зависимости от того, насколько критична работа etcd для вашего приложения, время выполнения дефрагментации необходимо учитывать.
Поможет ли настройка HA (High Availability, то есть высокой доступности)
Настройка HA etcd не поможет уменьшить паузу при дефрагментации, поскольку переизбрание лидера etcd произойдет только тогда, когда дефрагментация займет больше времени, чем тайм-аут выбора лидера. А этого не должно быть, если ваша база данных меньше 2 ГБ и если сжатие производится регулярно.
Запуск операций дефрагментации
Лично я предпочитаю использовать systemd.timer для запуска операций дефрагментации, а не традиционный cronjob. При использовании systemd можно получать логи по умолчанию для каждого триггера, передавая информацию о них в journalctl, который гораздо понятнее, чем логи cron.
Пример файла etcd-defrag.service:
Пример файла etcd-defrag.timer:
Используя две вышеупомянутые службы systemd, вы можете запускать операции дефрагментации в зависимости от того, когда вы хотите, чтобы они выполнялись.
Логи сервиса etcd-defrag.service:
Запуск Etcd
Мы используем etcd community cookbook, где описан пример запуска.
Пример службы systemd предназначен для базы данных etcd на одном узле. В зависимости от того, требуется ли вам кластер etcd или вы не хотите, чтобы API etcdv2 был доступен — параметры вашего ExecStart изменятся. Это хорошо задокументировано в репозитории etcd community cookbook.
Мы не пробовали запускать etcd на Kubernetes, несмотря на то, что StatefulSets — это вещь, постепенно набирающая обороты. Мы делаем автоматизацию при помощи Proctor в сочетании со сценариями Chef, с несколькими дополнениями для создания связанных с дефрагментацией системных сервисов.
Несколько оптимизаций
Запускаем etcd-кластер для Kubernetes
Материал подготовлен совместно с Containerum
В Kubernetes etcd является основным хранилищем информации о состоянии кластера. В этой статье мы расскажем основы работы etcd в Kubernetes и покажем, как настроить etcd-кластер.
Дополнительно мы покажем, как задействовать SSL/TLS-шифрование для сообщения между нодами кластера и etcd, чтобы повысить безопасность и надежность использования etcd.
etcd — это распределенное хранилище типа «ключ-значение» c открытым исходным кодом. Изначально etcd создавался для работы с CoreOS, но сейчас оно доступно для OS X, Linux и BSD.
Как и Kubernetes, etcd написан на языке Go и использует алгоритм консенсуса Raft для обеспечения высокодоступной репликации данных. Благодаря поддержке распределенных систем он активно применяется в Kubernetes, Cloud Foundry, Fleet и других проектах.
Зачем нужен кластер etcd в Kubernetes?
etcd — база данных для Kubernetes, критически важный компонент любого кластера. Он хранит в себе всю информацию, нужную для его стабильной работы.
etcd можно запускать 1) на тех же нодах, что и кластер Kubernetes, 2) на отдельных машинах либо 3) как под в кластере Kubernetes. Вне зависимости от выбранной конфигурации основная задача — обеспечить консистентность данных и отказоустойчивость кластера. Если etcd запущен в нескольких репликах, будь то на отдельных машинах или машинах с Kubernetes, это обеспечит непрерывность работы кластера Kubernetes в случае сбоя отдельных нод etcd.
Кластер etcd из трех нод
Каким должен быть кластер etcd?
Количество нод в кластере etcd теоретически неограничено. И чем больше нод, тем выше надежность etcd, однако при увеличении размера кластера растет задержка при записи информации, так как данные реплицируются на большем числе нод. Оптимальны etcd-кластеры не более чем из 7 нод, а в большинстве случаев достаточно 5 нод — в похожем на etcd внутреннем сервисе Google использует именно такие кластеры.
Чтобы застраховаться от поломки двух нод сразу, нужен кластер из 5 нод, в котором против против двух упавших будут три работающие ноды. От поломки трех нод нужен кластер из 7 нод, и так далее.
Как вы видите, в кластере рекомендуется использовать нечётное количество нод. Это связано с механизмом согласования данных на нодах в кластере через кворум, и в конечном итоге — его устойчивости. Например, в кластере из 5 нод кворум составляет 3 ноды (то есть, кластер может потерять 2 ноды и при этом сохранить работоспособность). Казалось бы, чем больше нод, чем надёжнее, и добавление 6 ноды будет полезно, но в кластере из 6 нод кворум составляют 4 узла, поэтому такой кластер устойчив к потере тех же двух узлов, что и кластер из 5 нод. При этом в кластере больше нод, которые могут упасть. Подробнее об оптимальном числе нод в кластере здесь.
Еще несколько важных моментов:
Эффективность и стабильность работы кластеров во многом зависят от дискового I/O. Для обеспечения стабильности etcd записывает все метаданные в лог и постоянно проверяет свое состояние (health checks), чтобы извлечь уже неактуальную информацию из этого лога. При высокой задержке записи/чтения возникает риск рассинхронизации данных о состоянии кластера, что приведет к его нестабильной работе и переизбранию мастера etcd. Кроме того, недостаток ресурсов может привести к рассинхронизации компонентов кластера etcd, невозможности записи информации в etcd и запуска новых подов в кластерах Kubernetes. Поэтому рекомендуется запускать etcd на SSD-дисках.
Минимально жизнеспособный Kubernetes
Перевод статьи подготовлен в преддверии старта курса «DevOps практики и инструменты».
Если вы это читаете, вероятно, вы что-то слышали о Kubernetes (а если нет, то как вы здесь оказались?) Но что же на самом деле представляет собой Kubernetes? Это “Оркестрация контейнеров промышленного уровня”? Или «Cloud-Native Operating System»? Что вообще это значит?
Честно говоря, я не уверен на 100%. Но думаю интересно покопаться во внутренностях и посмотреть, что на самом деле происходит в Kubernetes под его многими слоями абстракций. Так что ради интереса, давайте посмотрим, как на самом деле выглядит минимальный “кластер Kubernetes”. (Это будет намного проще, чем Kubernetes The Hard Way.)
Я полагаю, что у вас есть базовые знания Kubernetes, Linux и контейнеров. Все, о чем мы здесь будем говорить предназначено только для исследования/изучения, не запускайте ничего из этого в продакшене!
Обзор
Kubernetes содержит много компонент. Согласно википедии, архитектура выглядит следующим образом:
Здесь показано, по крайней мере, восемь компонент, но большинство из них мы проигнорируем. Я хочу заявить, что минимальная вещь, которую можно обоснованно назвать Kubernetes, состоит из трех основных компонент:
Агент, работающий на каждом узле в кластере. Он следит за тем, чтобы контейнеры были запущены в поде.
Звучит достаточно просто. Что насчет среды выполнения контейнеров (container runtime)?
Среда выполнения контейнера — это программа, предназначенная для выполнения контейнеров.
Очень информативно. Но если вы знакомы с Docker, то у вас должно быть общее представление о том, что он делает. (Детали разделения ответственностей между средой выполнения контейнеров и kubelet на самом деле довольно тонкие и здесь я не буду в них углубляться.)
Сервер API — компонент Kubernetes панели управления, который представляет API Kubernetes. API-сервер — это клиентская часть панели управления Kubernetes
Любому, кто когда-либо что-либо делал с Kubernetes, приходилось взаимодействовать с API либо напрямую, либо через kubectl. Это сердце того, что делает Kubernetes Kubernetes’ом — мозг, превращающий горы YAML, который мы все знаем и любим (?), в работающую инфраструктуру. Кажется очевидным, что API должен присутствовать в нашей минимальной конфигурации.
Предварительные условия
Скучная установка
На машину, которую мы будем использовать необходимо установить Docker. (Я не собираюсь подробно рассказывать как работает Docker и контейнеры; если вам интересно, есть замечательные статьи). Давайте просто установим его с помощью apt :
kubelet должен работать от root. Достаточно логично, так как ему надо управлять всем узлом. Давайте посмотрим на его параметры:
Ого, как много опций! К счастью, нам понадобится только пара из них. Вот один из параметров, который нам интересен:
Этот параметр позволяет нам запускать статические поды — поды, которые не управляются через Kubernetes API. Статические поды используются редко, но они очень удобны для быстрого поднятия кластера, а это именно то, что нам нужно. Мы проигнорируем это громкое предупреждение (опять же, не запускайте это в проде!) и посмотрим, сможем ли мы запустить под.
Сначала мы создадим каталог для статических подов и запустим kubelet :
Затем в другом терминале/окне tmux/еще где-то, мы создадим манифест пода:
kubelet начинает писать какие-то предупреждения и кажется, что ничего не происходит. Но это не так! Давайте посмотрим на Docker:
kubelet прочитал манифест пода и дал Docker’у команду запустить пару контейнеров в соответствии с нашей спецификацией. (Если вам интересно узнать про контейнер “pause”, то это хакерство Kubernetes — подробности смотрите в этом блоге.) Kubelet запустит наш контейнер busybox с указанной командой и будет перезапускать его бесконечно, пока статический под не будет удален.
Поздравьте себя. Мы только что придумали один из самых запутанных способов вывода текста в терминал!
Запускаем etcd
Нашей конечной целью является запуск Kubernetes API, но для этого нам сначала нужно запустить etcd. Давайте запустим минимальный кластер etcd, поместив его настройки в каталог pods (например, pods/etcd.yaml ):
Если вы когда-либо работали с Kubernetes, то подобные YAML-файлы должны быть вам знакомы. Здесь стоит отметить только два момента:
Мы смонтировали папку хоста /var/lib/etcd в под, чтобы данные etcd сохранялись после перезапуска (если этого не сделать, то состояние кластера будет стираться при каждом перезапуске пода, что будет нехорошо даже для минимальной установки Kubernetes).
Простая проверка показывает, что etcd действительно запущен на localhost и сохраняет данные на диск:
Запуск API-сервера
(Опять же, не запускайте это в продакшене! Я был немного удивлен, что настройка по умолчанию настолько небезопасна. Но я предполагаю, что это сделано для облегчения разработки и тестирования.)
И, приятный сюрприз, kubectl работает из коробки без каких-либо дополнительных настроек!
Проблема
Но если копнуть немного глубже, то кажется, что что-то идет не так:
Статические поды, которые мы создали, пропали! На самом деле, наш kubelet-узел вообще не обнаруживается:
В чем же дело? Если вы помните, то несколько абзацев назад мы запускали kubelet с чрезвычайно простым набором параметров командной строки, поэтому kubelet не знает, как связаться с сервером API и уведомлять его о своем состоянии. Изучив документацию, мы находим соответствующий флаг:
Все это время, сами того не зная, мы запускали kubelet в «автономном режиме». (Если бы мы были педантичны, то можно было считать автономный режим kubelet как «минимально жизнеспособный Kubernetes», но это было бы очень скучно). Чтобы заработала «настоящая» конфигурация, нам нужно передать файл kubeconfig в kubelet, чтобы он знал, как общаться с API-сервером. К счастью, это довольно просто (так как у нас нет проблем с аутентификацией или сертификатами):
(Кстати, если вы попытаетесь обратиться к API через curl, когда kubelet не работает, то вы обнаружите, что он все еще работает! Kubelet не является «родителем» своих подов, подобно Docker’у, он больше похож на “управляющего демона”. Контейнеры, управляемые kubelet, будут работать, пока kubelet не остановит их.)
Через несколько минут kubectl должен показать нам поды и узлы, как мы и ожидаем:
Давайте на этот раз поздравим себя по-настоящему (я знаю, что уже поздравлял) — у нас получился минимальный «кластер» Kubernetes, работающий с полнофункциональным API!
Запускаем под
Теперь посмотрим на что способен API. Начнем с пода nginx:
Здесь мы получим довольно интересную ошибку:
Здесь мы видим насколько ужасающе неполна наша среда Kubernetes — у нас нет учетных записей для служб. Давайте попробуем еще раз, создав учетную запись службы вручную, и посмотрим, что произойдет:
Даже когда мы создали учетную запись службы вручную, токен аутентификации не создается. Продолжая экспериментировать с нашим минималистичным «кластером», мы обнаружим, что большинство полезных вещей, которые обычно происходят автоматически, будут отсутствовать. Сервер Kubernetes API довольно минималистичен, большая часть тяжелых автоматических настроек происходит в различных контроллерах и фоновых заданиях, которые еще не выполняются.
Мы можем обойти эту проблему, установив опцию automountServiceAccountToken для учетной записи службы (так как нам все равно не придется ее использовать):
Наконец, под появился! Но на самом деле он не запустится, так как у нас нет планировщика (scheduler) — еще одного важного компонента Kubernetes. Опять же, мы видим, что API Kubernetes на удивление «глупый» — когда вы создаете под в API, он его регистрирует, но не пытается выяснить, на каком узле его запускать.
На самом деле для запуска пода планировщик не нужен. Можно вручную добавить узел в манифест в параметре nodeName :
(Замените mink8s на название узла.) После delete и apply мы видим, что nginx запустился и слушает внутренний IP-адрес:
Чтобы убедиться, что сеть между подами работает корректно, мы можем запустить curl из другого пода:
Довольно интересно покопаться в этом окружении и посмотреть, что работает, а что нет. Я обнаружил, что ConfigMap и Secret работают так, как и ожидается, а Service и Deployment нет.
Успех!
Этот пост становится большим, поэтому я собираюсь объявить о победе и заявить, что это жизнеспособная конфигурация, которую можно назвать “Kubernetes». Резюмируя: четыре бинарных файла, пять параметров командной строки и “всего лишь” 45 строк YAML (не так много по стандартам Kubernetes) и у нас работает немало вещей: