Выделенный сервер для Kubernetes: один control-plane и воркеры без иллюзии отказоустойчивости

MAATRIX · Выделенные серверы · Статья 10 из 48

На схеме три прямоугольника: управляющий узел и два рабочих. Между ними аккуратные стрелки, под ними слово «кластер». Выглядит убедительно, пока не выясняется, что все три виртуальные машины живут на одном физическом сервере. Один отказ питания способен перечеркнуть всю красоту одним движением.

Это не делает схему бесполезной. Выделенный сервер для Kubernetes может стать удобной учебной площадкой, средой тестирования или осознанным началом небольшого проекта. Важно честно назвать её свойства. Один control-plane с воркерами помогает освоить и организовать работу приложений, но сам по себе не обещает высокой доступности.

Три роли, которые стоит различать с самого начала

Управляющая часть Kubernetes принимает описания желаемого состояния, хранит сведения о кластере и организует размещение нагрузки. Рабочие узлы запускают приложения. Хранилище обеспечивает сохранение нужных данных за пределами жизни отдельного контейнера. Эти роли могут находиться на разных машинах или делить одну, но обязанности от этого не исчезают.

Если единственный управляющий узел недоступен, уже запущенные приложения на исправных воркерах могут продолжать работу. Однако управление и согласование изменений нарушаются: нельзя рассчитывать на обычное создание новых нагрузок, восстановление размещения и обслуживание кластера. Поэтому «страница всё ещё открывается» не означает, что отказ control-plane безвреден.

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

Для устойчивой управляющей части обычно проектируют несколько независимых узлов и кворумное хранилище состояния, а также доступную точку входа в API. Официальная инструкция kubeadm по высокой доступности рассматривает соответствующие топологии. Это уже другой бюджет и другой набор эксплуатационных задач.

Когда один физический сервер — разумное начало

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

Для staging важна воспроизводимость поведения приложения перед выпуском. Здесь несколько виртуальных воркеров помогают проверить размещение и взаимодействие служб. Однако тест высокой доступности на общем хосте остаётся неполным: физические отказовые сценарии такой стенд не воспроизводит.

Небольшой рабочий проект тоже может принять ограничение одного сервера, если допустимый перерыв, восстановление и бюджет явно согласованы. В этом случае нужны внешние резервные копии и понятный порядок замены узла. Слово Kubernetes не должно прятать тот факт, что обслуживание хоста потребует окна или другого места для работы приложений.

Если же простой неприемлем, начинать расчёт следует с независимых узлов и резервов мощности. Одна дорогая машина не заменяет эту архитектуру. Иногда более управляемым решением окажется услуга Kubernetes с готовой управляющей частью; сравнивать нужно весь объём обязанностей, а не только цену процессора.

ANKH, PYLON и NECROPOLIS: куда исчезает память

ANKH в США предлагает шесть ядер Ryzen 7600X, 64 ГБ DDR5 и один NVMe на 1 ТБ за $329 в месяц. PYLON за $429 имеет шестнадцать ядер Ryzen 7950X, но те же 64 ГБ памяти и заявленный объём диска. NECROPOLIS за $529 — 48 ядер EPYC 7642, 128 ГБ DDR4 и два NVMe по 1 ТБ.

Для умеренного стенда ANKH можно включить в начальные испытания. Если приложения выполняют много независимых вычислений, PYLON даст больше процессорных ресурсов. При большом числе служб, баз и тестовых окружений ограничение нередко находится в памяти; тогда важнее рассмотреть 128 ГБ NECROPOLIS, чем просто прибавить ядра при прежней RAM.

Сначала составьте бюджет ресурсов. Память нужна операционной системе или гипервизору, управляющей части, сетевым компонентам, DNS, сбору метрик и самим приложениям. Если поверх bare metal работают виртуальные узлы, у каждого будет собственная гостевая система. Нельзя раздать воркерам все 64 ГБ, а затем удивиться, что место для управления тоже понадобилось.

На воркере также есть разница между физической ёмкостью и ресурсами, доступными контейнерам. Часть следует оставить системным процессам. Планируйте приложение по измеренному потреблению и учитывайте пики запуска. Служба, которой мало памяти только во время обновления, всё равно способна сорвать это обновление.

CARTOUCHE в России с 128 ГБ, 28 суммарными ядрами двух Xeon E5-2680 v4 и двумя SSD по 600 ГБ за $295 можно рассматривать для локального стенда. Здесь другая процессорная платформа и меньшая дисковая ёмкость. Сравнивать его с Ryzen по числу ядер без испытаний нельзя, но для набора умеренных сред объём памяти может быть полезен.

Requests и limits — язык договорённостей с планировщиком

Kubernetes должен знать, сколько ресурсов нужно нагрузке для размещения. Для этого используют requests. Limits задают ограничения потребления, но их действие различается для процессора и памяти. Ограничение CPU может приводить к сдерживанию выполнения, а нехватка разрешённой памяти — к завершению процесса. Подробности изложены в документации по ресурсам контейнеров.

Слишком маленькие запросы ресурсов создают красивую картину заполнения: на узле как будто помещается многое. Затем приложения одновременно начинают настоящую работу и обнаруживают, что на физической машине не появились обещанные гигабайты. Завышенные запросы дают обратный результат — свободные ресурсы остаются недоступными для размещения.

Начинайте с измерений и постепенно уточняйте значения. Разделяйте обычное потребление, пик и потребность во время старта. Особенно внимательно относитесь к Java-приложениям, обработке крупных файлов и задачам, которые создают много дочерних процессов. Одно среднее число не описывает весь жизненный цикл службы.

Для команд и сред задайте квоты, чтобы одна экспериментальная ветка не занимала весь кластер. Это организационная функция с вполне техническими последствиями. Если никто не знает, кому принадлежат оставшиеся после демонстрации окружения, планировщик не сможет восстановить справедливость самостоятельно.

При обновлениях нужен временный запас. Новая версия может запускаться до остановки старой; соответствующие настройки развёртывания должны помещаться в доступные ресурсы. Кластер, рассчитанный до последнего мегабайта, часто становится очень экономным ровно до первой попытки что-либо изменить.

Сеть и хранилище требуют отдельного проекта

На выделенном сервере нет оснований предполагать готовый облачный балансировщик. Выбранная среда должна объяснять, как внешний трафик приходит к приложению, кто управляет адресами и сертификатами и что произойдёт при изменении узла. Ingress-контроллер тоже нужно установить, настроить и обслуживать.

Сетевой плагин определяет взаимодействие подов и поддержку политик. Само наличие объекта NetworkPolicy не гарантирует, что используемый сетевой компонент действительно применяет правила. Проверьте это тестом из разрешённой и запрещённой среды. Для базы данных запрет лишних путей полезнее предположения, что внутренний адрес автоматически делает её недоступной посторонним.

Административный API не следует открывать без ограничений всему интернету. Нужны контролируемый доступ, индивидуальные полномочия и защищённое хранение учётных данных. Секреты приложения требуют собственной политики: где находится исходный материал, кто может его прочитать и как происходит замена.

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

Два диска NECROPOLIS можно включить в выбранную схему хранения, но два устройства на одном хосте не становятся распределённым хранилищем. Даже локальное зеркало не решает задачу отказа всего сервера. А единственный NVMe у ANKH или PYLON требует особенно внимательного плана восстановления.

Развёртывание лучше начинать с возможности повторить его

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

Сначала поднимите минимальную рабочую среду: управляющий узел, воркер, сеть, DNS и простое тестовое приложение. Затем проверьте внешний вход и постоянный том. Только после этого добавляйте наблюдение, реальные службы и дополнительные рабочие узлы. Такой порядок помогает понимать, на каком этапе возникла проблема.

Для нескольких виртуальных узлов определите границы CPU, RAM и диска. Не нужно механически делить машину на равные части: управляющей части и базе приложения могут требоваться разные ресурсы. Но произвольное изменение размеров без учёта соседей тоже быстро разрушает предсказуемость стенда.

Не устанавливайте все доступные операторы в первый вечер. Каждый из них добавляет процессы, права и обязанности обновления. Сначала убедитесь, что команда понимает базовую систему и умеет восстанавливать её. Для небольшого приложения простая среда иногда полезнее сложной; критерии перехода разобраны в статье о миграции из Docker Compose в Kubernetes.

Восстановление важнее количества зелёных значков

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

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

Проверьте остановку одного воркера, перезапуск приложения и потерю единственного control-plane в тестовой среде. Запишите, какие службы продолжают работать, какие операции управления недоступны и сколько занимает возвращение системы. Если все виртуальные узлы расположены на одном физическом хосте, отдельно проговорите сценарий потери этого хоста — он останется общим риском.

Будущий рост проектируйте по причине ограничения. Если не хватает CPU, добавляют вычислительные ресурсы. Если памяти — меняют соответствующий бюджет. Если нужна доступность — добавляют независимые узлы и проверяют переключение. Эти задачи нельзя решить одной универсальной покупкой «сервера помощнее».

Один control-plane и несколько воркеров — хороший старт, когда его ограничения приняты осознанно. Тогда ANKH, PYLON или NECROPOLIS выбирают под измеренную работу, а не под желание нарисовать побольше прямоугольников. Настоящая зрелость кластера начинается с момента, когда команда умеет объяснить, что произойдёт, если один из них погаснет.

Все материалы о выделенных серверах