что такое etcd kubernetes
Основы Kubernetes
В этой публикации я хотел рассказать об интересной, но незаслуженно мало описанной на Хабре, системе управления контейнерами Kubernetes.
Что такое Kubernetes?
Kubernetes является проектом с открытым исходным кодом, предназначенным для управления кластером контейнеров Linux как единой системой. Kubernetes управляет и запускает контейнеры Docker на большом количестве хостов, а так же обеспечивает совместное размещение и репликацию большого количества контейнеров. Проект был начат Google и теперь поддерживается многими компаниями, среди которых Microsoft, RedHat, IBM и Docker.
Компания Google пользуется контейнерной технологией уже более десяти лет. Она начинала с запуска более 2 млрд контейнеров в течение одной недели. С помощью проекта Kubernetes компания делится своим опытом создания открытой платформы, предназначенной для масштабируемого запуска контейнеров.
Проект преследует две цели. Если вы пользуетесь контейнерами Docker, возникает следующий вопрос о том, как масштабировать и запускать контейнеры сразу на большом количестве хостов Docker, а также как выполнять их балансировку. В проекте предлагается высокоуровневый API, определяющее логическое группирование контейнеров, позволяющее определять пулы контейнеров, балансировать нагрузку, а также задавать их размещение.
Концепции Kubernetes
Nodes (node.md): Нода это машина в кластере Kubernetes.
Pods (pods.md): Pod это группа контейнеров с общими разделами, запускаемых как единое целое.
Replication Controllers (replication-controller.md): replication controller гарантирует, что определенное количество «реплик» pod’ы будут запущены в любой момент времени.
Services (services.md): Сервис в Kubernetes это абстракция которая определяет логический объединённый набор pod и политику доступа к ним.
Volumes (volumes.md): Volume(раздел) это директория, возможно, с данными в ней, которая доступна в контейнере.
Labels (labels.md): Label’ы это пары ключ/значение которые прикрепляются к объектам, например pod’ам. Label’ы могут быть использованы для создания и выбора наборов объектов.
Kubectl Command Line Interface (kubectl.md): kubectl интерфейс командной строки для управления Kubernetes.
Архитектура Kubernetes
Работающий кластер Kubernetes включает в себя агента, запущенного на нодах (kubelet) и компоненты мастера (APIs, scheduler, etc), поверх решения с распределённым хранилищем. Приведённая схема показывает желаемое, в конечном итоге, состояние, хотя все ещё ведётся работа над некоторыми вещами, например: как сделать так, чтобы kubelet (все компоненты, на самом деле) самостоятельно запускался в контейнере, что сделает планировщик на 100% подключаемым.
Нода Kubernetes
При взгляде на архитектуру системы мы можем разбить его на сервисы, которые работают на каждой ноде и сервисы уровня управления кластера. На каждой ноде Kubernetes запускаются сервисы, необходимые для управления нодой со стороны мастера и для запуска приложений. Конечно, на каждой ноде запускается Docker. Docker обеспечивает загрузку образов и запуск контейнеров.
Kubelet
Kubelet управляет pod’ами их контейнерами, образами, разделами, etc.
Kube-Proxy
Также на каждой ноде запускается простой proxy-балансировщик. Этот сервис запускается на каждой ноде и настраивается в Kubernetes API. Kube-Proxy может выполнять простейшее перенаправление потоков TCP и UDP (round robin) между набором бэкендов.
Компоненты управления Kubernetes
Система управления Kubernetes разделена на несколько компонентов. В данный момент все они запускаются на мастер-ноде, но в скором времени это будет изменено для возможности создания отказоустойчивого кластера. Эти компоненты работают вместе, чтобы обеспечить единое представление кластера.
Состояние мастера хранится в экземпляре etcd. Это обеспечивает надёжное хранение конфигурационных данных и своевременное оповещение прочих компонентов об изменении состояния.
Kubernetes API Server
Kubernetes API обеспечивает работу api-сервера. Он предназначен для того, чтобы быть CRUD сервером со встроенной бизнес-логикой, реализованной в отдельных компонентах или в плагинах. Он, в основном, обрабатывает REST операции, проверяя их и обновляя соответствующие объекты в etcd (и событийно в других хранилищах).
Scheduler
Scheduler привязывает незапущенные pod’ы к нодам через вызов /binding API. Scheduler подключаем; планируется поддержка множественных scheduler’ов и пользовательских scheduler’ов.
Kubernetes Controller Manager Server
Все остальные функции уровня кластера представлены в Controller Manager. Например, ноды обнаруживаются, управляются и контролируются средствами node controller. Эта сущность в итоге может быть разделена на отдельные компоненты, чтобы сделать их независимо подключаемыми.
ReplicationController — это механизм, основывающийся на pod API. В конечном счете планируется перевести её на общий механизм plug-in, когда он будет реализован.
Пример настройки кластера
В качестве платформы для примера настройки была выбрана Ubuntu-server 14.10 как наиболее простая для примера и, в то же время, позволяющая продемонстрировать основные параметры настройки кластера.
Для создания тестового кластера будут использованы три машины для создания нод и отдельная машина для проведения удалённой установки. Можно не выделять отдельную машину и производить установку с одной из нод.
Подготовка нод
Требования для запуска:
Установка ПО на ноды
Установку Docker можно произвести по статье в официальных источниках:
Дополнительная настройка Docker после установки не нужна, т.к. будет произведена скриптом установки Kubernetes.
Установка bridge-utils:
Добавление ssh-ключей
Выполняем на машине, с которой будет запущен скрипт установки.
Если ключи ещё не созданы, создаём их:
Копируем ключи на удалённые машины, предварительно убедившись в наличии на них необходимого пользователя, в нашем случае core.
Установка Kubernetes
Далее мы займёмся установкой непосредственно Kubernetes. Для этого в первую очередь скачаем и распакуем последний доступный релиз с GitHub:
Настройка
Для того, чтобы использовать последний, на момент написания статьи, релиз 0.17.0 необходимо заменить:
На этом настройка заканчивается и можно переходить к установке.
Установка
Первым делом необходимо сообщить системе про наш ssh-agent и используемый ssh-ключ для этого выполняем:
В процессе установки скрипт потребует пароль sudo для каждой ноды. По окончанию установки проверит состояние кластера и выведет список нод и адреса Kubernetes api.
Посмотрим, какие ноды и сервисы присутствуют в новом кластере:
Видим список из установленных нод в состоянии Ready и два предустановленных сервиса kubernetes и kubernetes-ro — это прокси для непосредственного доступа к Kubernetes API. Как и к любому сервису Kubernetes к kubernetes и kubernetes-ro можно обратиться непосредственно по IP адресу с любой из нод.
Запуск тестового сервиса
Для запуска сервиса необходимо подготовить docker контейнер, на основе которого будет создан сервис. Дабы не усложнять, в примере будет использован общедоступный контейнер nginx. Обязательными составляющими сервиса являются Replication Controller, обеспечивающий запущенность необходимого набора контейнеров (точнее pod) и service, который определяет, на каких IP адресе и портах будет слушать сервис и правила распределения запросов между pod’ами.
Любой сервис можно запустить 2-я способами: вручную и с помощью конфиг-файла. Рассмотрим оба.
Запуск сервиса вручную
Начнём с создания Replication Controller’а:
Далее создаём service который будет использовать наш Replication Controller как бекенд.
Для http:
Для проверки запущенности можно зайти на любую из нод и выполнить в консоли:
В выводе curl увидим стандартную приветственную страницу nginx. Готово, сервис запущен и доступен.
Запуск сервиса с помощью конфигов
Для этого способа запуска необходимо создать конфиги для Replication Controller’а и service’а. Kubernetes принимает конфиги в форматах yaml и json. Мне ближе yaml поэтому будем использовать его.
Предварительно очистим наш кластер от предыдущего эксперимента:
Был создан Replication Controller с именем nginx и количеством реплик равным 6. Реплики в произвольном порядке запущены на нодах, местоположения каждой pod’ы указано в столбце HOST.
Можно заметить, что при использовании конфига за одним сервисом могут быть закреплены несколько портов.
Применяем конфиг:
Для проверки запущенности можно зайти на любую из нод и выполнить в консоли:
В выводе curl увидим стандартную приветственную страницу nginx.
Заметки на полях
В качестве заключения хочу описать пару важных моментов, о которые уже пришлось запнуться при проектировании системы. Связаны они были с работой kube-proxy, того самого модуля, который позволяет превратить разрозненный набор элементов в сервис.
PORTAL_NET. Сущность сама по себе интересная, предлагаю ознакомиться с тем, как же это реализовано.
Недолгие раскопки привели меня к осознанию простой, но эффективной модели, заглянем в вывод iptables-save:
На этом всё, спасибо за внимание
К сожалению, всю информацию, которую хочется передать, не получается уместить в одну статью.
Внутреннее устройство Kubernetes-кластера простым языком
Прим. перев.: как многим хорошо известно, Kubernetes — это всего лишь пять бинарников. Об их назначении и рассказывает в этой статье Vedashree Patil, консультант из Deloitte Digital. Когда ей потребовалось изучить Kubernetes, она столкнулась с большим количеством новой информации, осознать которую за короткое время было непросто. Так она пришла к идее уменьшить порог вхождения в K8s другим специалистам, создав цикл публикаций «Kubernetes 101». Все статьи сопровождаются простыми и наглядными комиксами. Представляем вниманию перевод материала под названием «Внутри кластера» из этого цикла.
Из известного набора стикеров для Telegram
Как выглядит кластер Kubernetes? Как работают узлы? Из этой статьи вы узнаете обо всех основных компонентах системы Kubernetes.
Предисловие
Мы уже говорили о концепции master-slave в Kubernetes. Один узел контролирует все остальные. В Kubernetes все устроено именно таким образом. Но мы ещё не рассматривали, КАК работает связка master-slave. Что именно делает мастер-узел (master node)? Итак, начнём.
Общая картина
Примерно так выглядит типичный мастер-узел:
Мастер-узел (слева) и рабочий узел (справа)
Если вам интересно, что означают все эти причудливые термины, они будут подробно рассмотрены далее. Сначала давайте разберёмся с мастер-узлом…
«Команда» Control Plane
На мастер-узле, также известном как Control Plane (иногда его переводят как «управляющий слой» — прим. перев.), выполняется большинство важных задач по управлению и администрированию кластера. Он включает в себя четыре основных компонента:
API server (API-сервер);
controller manager (менеджер контроллеров);
Команда представителей Control Plane
Давайте подробнее остановимся на каждом из них.
API server
Самый первый, и, пожалуй, самый важный — API-сервер. Это «лицо» Kubernetes. Чтобы взаимодействовать с кластером Kubernetes, вам наверняка придется познакомиться с API-сервером:
А этот парень — API-сервер… И у него Kubernetes API… Знаете, что это значит. Он тот самый супергерой, который выполнит все ваши запросы… — Эй, API-сервер, покажи-ка мне логи недавно задеплоенного веб-сервиса! — Логи уже на подходе.
Для любых манипуляций с кластером приходится обращаться к API-серверу с помощью Kubernetes API. Используете kubectl, REST или любую из клиентских библиотек Kubernetes? Все они завязаны на API Kubernetes’а и взаимодействуют с API-сервером.
Но когда становится реально жарко… — Эй, мне нужно то. — Эй, удали это! — Эй, API-сервер, ты там жив? — Покажи логи! — А как же моя работа? — Создай-ка вон то! Этот парень с лёгкостью масштабируется… горизонтально. — Вперёд, ребятки! Ещё полно работы.
Примечательная особенность API-сервера состоит в том, что он умеет масштабироваться по горизонтали. Другими словами, при резком увеличении количества поступающих запросов API-сервер может создавать «клоны» или реплики самого себя, чтобы справиться с нагрузкой.
Scheduler
Следующий компонент — планировщик. Как вы думаете, что он делает? Правильно, планирует.
А этот занятой парень — планировщик. Именно он назначает узлы новым Pod’ам. — То есть ты утверждаешь, что тебе нужны все эти ресурсы? — Ага!
Новый Pod остается в статусе Pending до тех пор, пока ему не будет выделен узел для работы (рекомендую обратиться к соответствующей статье о Pod’ах). Именно за это отвечает планировщик:
Узел 1 — загружен по полной. Узел 2 — то, что надо. Узел 3 — сидит без работы. — С первым узлом всё понятно. Итак, остались 2 и 3… У 2-го ещё есть чуток ресурсов, а 3-й вообще свободен. Думаю, ему надо чем-то заняться. Ок, тогда 3-й!
Каждому Pod’у требуются определенные ресурсы: память, CPU, железо… в общем, стандартный набор. Планировщик должен решить, какой узел соответствует требованиям Pod’а. Поэтому планировщик выполняет два действия:
Подбирает узлы-кандидаты для Pod’а;
Останавливает свой выбор на одном из них.
Controller manager
Прежде всего стоит узнать, что такое Контроллер.
Я люблю называть его компонентом, который «всё исправляет». Почему? Потому что работа у него такая — приводить в норму. Поясню. Он наблюдает за кластером — словно хищная птица за добычей, без устали и покоя. Если что-то идёт не так, контроллер предпринимает соответствующие действия для исправления ситуации.
Иными словами, у кластера есть состояние, называемое желаемым (англ. desired state). Именно в таком состоянии должен находиться кластер. Контроллер считает его единственно верным. С другой стороны, в каждый момент времени кластер находится в состоянии, называемом текущим (current state). Контроллеры будут делать всё, чтобы привести текущее состояние к желаемому.
Как работает контроллер: текущее состояние (бумага) → требуемое действие (вырезать из бумаги) → желаемое состояние (человечек из бумаги).
Или другой пример: вам требуется двадцать секунд, чтобы пробежать стометровку. Чтобы уменьшить это время до пятнадцати, придется каждый день тренироваться, чтобы достичь цели. Это и есть переход из текущего состояния в желаемое.
На самом деле контроллер — это просто бесконечный цикл, который постоянно следит за неким ресурсом в кластере (например, за Pod’ом). Если что-то идет не так, он исправляет возникшую проблему.
Теперь вернёмся к нашему менеджеру.
Менеджер контроллеров (Controller Manager) — это набор различных контроллеров. Например, может быть один контроллер, который наблюдает за узлами, другой — за задачами (Jobs), и так далее.
Но такой менеджер — это инструмент «всё в одном». По сути, он отслеживает сразу все ресурсы. За это отвечает ОДИН процесс, но благодаря многозадачности складывается впечатление, что одновременно работают несколько контроллеров. Вот некоторые из самых популярных:
Контроллер узлов: «О нет! Похоже, второй узел не работает. Нужно с этим что-то делать». Контроллер репликации: «Pod’у XX нужны три реплики, а там только две. Надо создать ещё одну». Контроллер учётных записей и токенов: «Хм-м, новое пространство имён. Нужны новые токены доступа».
Etcd — это личный журнал Kubernetes. Скажите, зачем люди ведут личные дневники и журналы? Все просто: чтобы сохранить в памяти мимолетные моменты (увы, мозг не способен хранить все события каждого дня нашей жизни).
То же самое и с Kubernetes. Всё, что происходит в кластере, должно быть записано и сохранено. Вообще всё! И тут на сцену выходит etcd. Эта база данных типа ключ-значение выступает резервным хранилищем для Kubernetes.
Переходим к рабочим узлам (worker nodes).
«Команда» рабочих узлов
Мы уже рассмотрели, что такое мастер-узел. Но настоящая работа происходит именно на рабочих узлах. А всё потому, что на каждом узле есть компоненты, отвечающие за его бесперебойное функционирование. Они включают в себя:
Команда представителей рабочих узлов
kubelet
Этот парень, пожалуй, самый важный. kubelet — это агент, который следит за тем, чтобы на узле всё работало должным образом. Подобная работа подразумевает ряд задач.
Первая — взаимодействие с мастер-узлом. Обычно мастер-узел отправляет задачу в форме манифеста или спецификации (Podspec). Манифест определяет, какие работы необходимо провести и какие Pod’ы нужно создать.
Обычный день из жизни kubelet: «Та-а-ак, новый манифест от мастера. Посмотрим… Два Pod’а с образом xxx».
Вторая — взаимодействие с исполняемой средой контейнера (container runtime) на узле. Исполняемая среда скачивает нужные образы, после чего вступает в действие kubelet, мониторя Pod’ы, созданные с использованием этих образов.
— Скачай-ка образ xxx. Нам нужны новые Pod’ы. — Ок!
Третья — проверки (probes) состояния Pod’ов. Кто отвечает за них? Конечно же, kubelet! Потому что следить за здоровьем Pod’а — его обязанность!
— Просто звоню узнать, как ты там. Обычная проверка, как всегда… Всё в порядке? — Лучше не бывает!
kube-proxy
Следующий неотъемлемый элемент — работа с сетью, и kube-proxy готов позаботиться об этом. Он работает как балансировщик нагрузки, распределяя трафик между Pod’ами, а также следит за соблюдением сетевых правил. Можно сказать, что kube-proxy полностью отвечает за коммуникации внутри кластера.
kube-proxy следит за соблюдением сетевых правил. Появился сетевой пакет с IP: 123.456.789.100. — Стой! Твоего IP-адреса нет в списке. Вход запрещён!
Заключение
В статье рассмотрены основные компоненты кластера Kubernetes. Но процесс познания далек от завершения — ещё необходимо освоить множество важных понятий. Например, мы лишь упомянули работу с сетью, ничего не сказали о рабочих нагрузках и конфигурациях в Kubernetes. Не переживайте: обо всём этом вы сможете узнать из будущих статей (в оригинале они публикуются здесь — прим. перев.).
Запускаем 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.
Недавно мы создали распределенную систему планирования задач (cron jobs) на базе Kubernetes — новой, захватывающей платформы для оркестрации контейнеров. Kubernetes становится все популярней и дает много обещаний: например, инженерам не придется переживать, на каком устройстве запущено их приложение.
Распределенные системы сложны сами по себе, а управление сервисами на распределенных системах — одна из сложнейших проблем, с которыми сталкиваются команды управления. Мы очень серьезно относимся к вводу нового программного обеспечения в производство и обучению его надежному управлению. В качестве примера важности управления Kubernetes (и почему это так сложно!), почитайте отличный постмортем часового перебоя в работе, вызванного багом в Kubernetes.
В этом посте мы объясним, почему выбрали именно Kubernetes. Изучим процесс его интегрирования в существующую инфраструктуру, метод укрепления доверия (и улучшения) надежности нашего Kubernetes кластера и абстракцию созданную на основе Kubernetes.
Что такое Kubernetes?
Kubernetes — распределенная система планирования программ для запуска в кластере. Вы можете сказать Kubernetes запустить пять копий программы, и он динамически запланирует их в ваших рабочих нодах. Контейнеры должны увеличить утилизацию, тем самым экономят средства, мощные примитивы развертывания позволяют постепенно выкатывать новый код, а Security Contexts и Network Policies позволяют безопасно запускать multi-tenant рабочие нагрузки.
В Kubernetes встроено множество различных возможностей планирования. Можно планировать длительные службы HTTP, daemonsets, запущенные на всех машинах вашего кластера, задачи, запускающиеся каждый час, и другое. Kubernetes представляет собой даже больше. И если вы хотите это узнать, посмотрите отличные выступления Kelsey Hightower: можно начать с Kubernetes для сисадминов и healthz: Перестаньте заниматься реверс-инженерингом приложений и начните наблюдать их изнутри. Не стоит забывать и про хорошее сообщество в Slack.
Почему именно Kubernetes?
Каждый инфраструктурный проект (я надеюсь!) начинается с потребности бизнеса, и наша задача — улучшить надежность и безопасность существующей системы планирования cron job, которая уже есть. Наши требования следующие:
Если вы рассматриваете Kubernetes, имейте в виду: не используйте Kubernetes просто потому что, так делают другие компании. Создание надежного кластера требует огромного количества времени, а способ его использования в бизнесе не всегда очевиден. Инвестируйте ваше время с умом.
Что значит “надежный”?
Когда дело доходит до управления сервисами, слово “надежный” не имеет смысла само по себе. Чтобы говорить о надежности, сначала нужно установить SLO (service level objective, то есть целевой уровень сервиса).
У нас было три основных задачи:
Создание Kubernetes кластера
Базовый подход к созданию первого Kubernetes кластера заключался в создании кластера с нуля, без использования инструментов вроде kubeadm или kops. Мы создали конфигурацию с помощью Puppet, нашего стандартного инструмента управления настройкой. Создание с нуля привлекало по двум причинам: мы могли глубоко интегрировать Kubernetes в нашу архитектуру, и мы приобрели широкие знания его внутреннего устройства.
Построение с нуля позволило нам интегрировать Kubernetes в существующую инфраструктуру. Мы хотели цельную интеграцию с нашими существующими системами логирования, управления сертификатами, секретов, сетевой безопасности, мониторинга, управления инстансами AWS, развертывания, прокси баз данных, внутренних DNS серверов, управления настройками, и многими другими. Интеграция всех этих систем иногда требовала творческого подхода, но, в целом, оказалась проще потенциальных попыток заставить kubeadm/kops делать то, что нам от них нужно.
Мы уже доверяем и знаем, как управлять существующими системами, поэтому хотели продолжить их использовать в новом Kubernetes кластере. Например, надежное управление сертификатами — очень сложная проблема, но у нас уже сейчас есть способ ее решения. Нам удалось избежать создания нового CA для Kubernetes благодаря грамотной интеграции.
Мы были вынуждены понять, как именно настраиваемые параметры влияют на нашу установку Kubernetes. Например, было использовано более дюжины параметров для настройки сертификатов/CA аутентификации. Понимание всех этих параметров облегчило отладку нашей установки при нахождении проблем с аутентификацией.
Укрепление уверенности в Kubernetes
В самом начале работы с Kubernetes ни у кого в команде не было опыта его использования (только для домашних проектов). Как же прийти от “Никто из нас никогда не использовал Kubernetes” к “Мы уверены в использовании Kubernetes на продакшне”?
Стратегия 0: Поговорить с другими компаниями
Мы спросили несколько человек из других компаний об их опыте с Kubernetes. Все они использовали его по-разному и в разных окружениях (для запуска HTTP сервисов, на голом железе, на Google Kubernetes Engine и т.д.).
Когда речь идет о больших и сложных системах как Kubernetes, особенно важно думать именно о ваших кейсах применения, экспериментировать, находить уверенность в вашем окружении и решать за себя. Например, не стоит после чтения этого поста решать “Ну, в Stripe успешно пользуются Kubernetes, значит и мы сможем!”.
Вот что мы узнали из бесед с различными компаниями, управляющих кластерами Kubernetes:
Стратегия 1: Прочитать код
Мы планировали сильно зависеть от одного компонента Kubernetes — контроллера cron job. В то время он находился в альфе, что стало небольшим поводом для волнения. Мы проверили его на тестовом кластере, но как можно сказать наверняка, будет ли он нас устраивать на продакшне? К счастью, весь код функционала контроллера состоит из 400 строк Go. Чтение исходного кода быстро показало, что:
Стратегия 2: Провести нагрузочное тестирование
Перед тем как начать строить наш кластер, мы провели нагрузочное тестирование. Нас не беспокоило количество нодов, с которыми мог справиться кластер Kubernetes (планировали разворачивать около 20 нодов), было важно убедиться, что Kubernetes способен выдерживать столько задач, сколько нам нужно (около 20 в минуту).
Тестовый кластер не смог выдержать 1000 задач в минуту. Мы выяснили, что каждый нод запускает максимум один под в секунду, и кластер мог без проблем запустить 200 задач в минуту. Учитывая, что нам нужно примерно 50 задач в минуту, было решено, что такое ограничение нас не блокировало (и что при необходимости мы могли их решить позже). Вперед!
Стратегия 3: Приоритезировать создание и тестирование отказоустойчивого etcd кластера
Очень важно при настройке Kubernetes — правильно запустить etcd. Etcd — сердце вашего Kubernetes кластера, именно там хранятся все данным о нем. Все кроме etcd не имеет состояний. Если etcd не запущен, вы не можете внести изменения в ваш Kubernetes кластер (хотя существующие сервисы продолжат работать!).
При запуске стоит держать в голове два важных момента:
Вот некоторые задачи, которые мы выполнили для настройки etcd кластера:
Стратегия 4: Постепенно перенести задачи в Kubernetes
Одной из наших основных целей было перенести задачи в Kubernetes, не вызвав перебоев в работе. Секрет успешного производственного переноса заключается не в безошибочном процессе (это невозможно), а в проектировании процесса таким образом, чтобы снизить вред от ошибок.
Мы были счастливыми обладателями большого разнообразия задач, требующих миграции в новый кластер, поэтому среди них оказались те, что обладали низким уровнем влияния — пара-тройка ошибок в их переносе была приемлемой.
Перед началом миграции мы создали простой в использовании инструмент, позволяющий перемещать задачи между старой и новой системами, менее, чем за пять минут. Этот инструмент снизил ущерб от ошибок — если мы перенесли задачу, обладающую зависимостью, которую мы не планировали, не проблема! Можно просто вернуть ее обратно, исправить проблему и попробовать снова.
Мы придерживались такой стратегии миграции:
Стратегия 5: Исследовать баги Kubernetes (и исправить их)
В самом начале проекта мы установили правило: если Kubernetes делает что-то неожиданное, нужно понять почему и предложить исправление.
Разбор каждого бага занимает много времени, но очень важен. Если бы мы просто отмахнулись от странного поведения Kubernetes, решив, что виновата сложность работы распределенной системы, то каждый новый баг заставлял бы думать, что только мы в нем виноваты.
После принятия этого подхода, мы нашли (и пофиксили!) несколько багов в Kubernetes.
Вот несколько проблем, которые мы нашли во время этих тестов:
Kubernetes полон багов, как и любой софт. К примеру, мы усиленно используем планировщик (потому что наши задачи постоянно создают новые поды), а использование планировщиком кэширования иногда оборачивается багами, регрессией и падениями. Кэширование — это сложно! Но codebase доступный и мы смогли справиться со всеми багами, с которыми столкнулись.
Еще одна достойная упоминания проблема — логика переноса подов в Kubernetes. В Kubernetes есть компонент под названием контроллер нодов, который отвечает за ликвидацию подов и их перенос в другие ноды в случае неотзывчивости. Возможен случай отсутствия ответа от всех нодов (например, при проблеме с сетью и настройкой), тогда Kubernetes может уничтожить все поды в кластере. Мы с этим сталкивались уже в начале тестирования.
Стратегия 6: намеренно создавайте проблемы для Kubernets кластера
Мы и раньше обсуждали запуск упражнений игрового дня в Stripe, и продолжаем это делать сейчас. Идея заключается в том, чтобы придумать ситуации, которые могут произойти в производстве (например, потеря сервера Kubernetes API), а затем специально создать их (во время рабочего дня, с предупреждением), чтобы убедиться в возможности их исправить.
Проведение нескольких упражнений на нашем кластере выявило некоторые проблемы вроде пробелов в мониторинге и ошибок конфигурации. Мы были очень рады найти эти проблемы заранее и в контролируемой среде, а не случайно шесть месяцев спустя.
Некоторые игровые упражнения, которые мы провели:
Если любой из корневых компонентов Kubernetes (сервер API, управление контроллеров, планировщик) прерван и перезапущен, то сразу после восстановления он читает состояние из etcd и продолжает работать. Это одна из тех вещей, которая привлекла в теории, и на практике показала себя не хуже.
Вот некоторые проблемы, которые мы нашли во время тестов:
Делаем cron jobs легкими в использовании
Кратко ознакомимся, как мы сделали нашу систему на базе Kubernetes простой в использовании.
Нашей изначальной целью было проектирование системы для запуска задач, которыми наша команда могла с уверенностью управлять. Когда мы стали уверены в Kubernetes, возникла необходимость в простой настройке и добавлении новых cron jobs нашими инженерами. Мы разработали конфигурационный YAML формат, чтобы наши пользователи не нуждались в понимании внутреннего строения Kubernetes для использования нашей системы. Вот этот формат:
Ничего сложного — просто написали программу, которая берет этот формат и переводит его в конфигурацию cron job Kubernetes, который мы применяем с kubectl.
Также мы написали тестовый набор для проверки длины (названия задач Kubernetes не может превышать 52 символа) и уникальности названий задач. Сейчас мы не используем cgroups для ограничения объемов памяти в большинстве наших задач, но это есть в планах на будущее.
Наш формат был прост в использовании, а, учитывая, что мы автоматически сгенерировали и cron job’ы Chronos, и cron job’ы Kubernetes, переместить задачи между двумя системами было легко. Это было ключевым элементом в хорошей работе нашей постепенной миграции. Как только перенос задачи в Kubernetes вызывал ошибку, мы могли перенести его обратно простым трехстрочным изменением в конфигурации, менее чем за 10 минут.
Мониторинг Kubernetes
Мониторинг внутренних состояний нашего Kubernetes кластера оказался приятным. Мы используем пакет kube-state-metrics для мониторинга и небольшую программу на Go под названием veneur-prometheus для сбора метрик Prometheus, которые выдает kube-state-metrics и их публикации в виде statsd метрики в нашей системе мониторинга.
Вот, например, график количества Pending подов в нашем кластере за последний час. Pending означает, что они ждут назначения рабочему ноду для запуска. Можно увидеть пик значения в 11 утра, потому что многие задачи запускаются в нулевую минуту часа.
Кроме этого, мы следим, что нет подов, застрявших в состоянии Pending — проверяем, что каждый под запускается в рабочем ноде в течение 5 минут, а иначе получаем предупреждение.
Будущие планы для Kubernetes
Настройка Kubernetes, достижение момента готовности запустить продакшн код и миграция наших cron jobs в новый кластер, заняли у трёх программистов на full-time пять месяцев. Одна из значимых причин, по которой мы вложились в изучение Kubernetes — ожидание более широкого использования Kubernetes в Stripe.
Вот некоторые принципы управления Kubernetes (и любой другой сложной распределенной системой):