Кластер kubernetes что это
Внутреннее устройство 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. Не переживайте: обо всём этом вы сможете узнать из будущих статей (в оригинале они публикуются здесь — прим. перев.).
K8S для начинающих. Первая часть
Предисловие
Что такое Kubernetes?
Kubernetes делает следующее:
Управляет и запускает контейнеры
Балансирует сетевой трафик между узлами кластера Kubernetes и количеством реплик контейнеров
Осуществляет контроль состояния, автоматические развертывания и откаты реплик контейнеров внутри узлов кластера Kubernetes
Осуществляет распределение нагрузки между узлами кластера Kubernetes
Предоставляет автоматическое монтирование систем хранения для контейнеров
Предоставляет декларативный API и CLI для управления
И еще множество полезных, и не очень, модулей и сервисов, которые можно развернуть для управления автоматизацией, инфраструктурой и контейнерами
Kubernetes не делает следующее:
Не собирает контейнеры с исходным кодом вашего приложения или сервиса
Не предоставляет процессы и решения непрерывной интеграции (CI)
Не включает в себя решения и системы сбора журналов и метрик
Не включает в себя решения и системы хранения данных
Не включает в себя решения и системы хранения контейнеров (registry)
Не включает в себя решения и системы от всех бед и болячек инфраструктуры
Kubernetes или K8S — это не просто система оркестрации. Техническое определение оркестрации — это выполнение определенного рабочего процесса: сначала сделай A, затем B, затем C. Напротив, Kubernetes содержит набор независимых, компонуемых процессов управления, которые непрерывно переводят текущее состояние к предполагаемому состоянию. Неважно, как добраться от А до С. Не требуется также и централизованный контроль. Это делает систему более простой в использовании, более мощной, надежной, устойчивой и расширяемой.
Но что если у нас таких сервисов тысячи, каждый за что-то отвечает и работает сам по себе? А если еще развернуты несколько реплик для отказоустойчивости? Как управлять всем и уделить внимание каждому из них? Как понять, что сервис правильно работает и взаимодействует с другими? Для этого есть специальные системы, оркестраторы в своем роде, такие как HashiCorp Nomad, Docker Swarm и Kubernetes. Последний используется активнее всего, так как предоставляет более гибкий функционал в контексте управления всей конструкцией приложения.
На самом деле бизнесу нужен не Kubernetes, а система, которая позволит более быстрее подходить к изменению рынка и подстраиваться под его запросы предоставления набора новых услуг или вывода старых. В НАТ.Тех мы давно используем этот инструмент и чувствуем большую разницу, как для нас, так и для наших клиентов. Исходя из нашего опыта, бизнес чаще всего ценит такие возможности К8S как собирать и тестировать только часть приложения, с которой мы работаем, что в разы уменьшает объем необходимых ресурсов; добавлять и убирать сервисы «на лету», тестировать новый функционал в разных регионах и смотреть, как он себя показывает.
Именно для этого нам и нужен Kubernetes, который дает унификацию и гибкость в способе обслуживания и содержания сервисов приложения. Kubernetes предоставляет:
Быструю и автоматическую масштабируемость. При росте нагрузки можно быстро добавить необходимые узлы приложения, а также быстро их вывести, чтобы не тратить драгоценные ресурсы
Гибкий подход в управлении. Kubernetes не потребует перестройки инфраструктуры и прочего, если вы захотели провести тестирование, внедрить новый сервис или сделать деплой по методологии blue-green
Универсальность. С помощью манифестов легко переехать, если вы захотели поменять провайдера или переезжали в свой собственный кластер
Низкий порог вхождения в использование. Kubernetes довольно легок в освоении манифестов, потому что большую часть работы он делает за вас
Если вы задумываетесь о преимуществах, описанных выше, и можете точно сказать, что вам нужна гибкость в разработке и быстрое внедрение сервисов, адаптируемый подход и универсальность в управлении большим количеством сервисов и их реплик, то думаю, что пора попробовать Kubernetes и у себя.
Однако, если ваш проект имеет постоянную нагрузку и не требует высокой степени гибкости и быстрого масштабирования, новый функционал появляется редко и у вас есть команда, уверенно работающая с существующим окружением, то на данный момент возможности K8S для бизнеса избыточны, но «посмотреть» на технологию в фоновом режиме все же стоит, так как те или иные условия могут и поменяться.
Внедрение Kubernetes
Kubernetes, так как он был реализован как облачное решение, предпочтительнее разворачивать именно в облаке.
Если вы решились ставить Kubernetes внутри, на своих собственных ресурсах, то вам придется позаботиться о развёртывании и обслуживании такой инфраструктуры вокруг кластера как: репозиторий для контейнеров, внешние или внутренние балансировщики, сетевые хранилища, хранилище секретов, решения для сбора логов и метрик. Также важна и внутренняя инфраструктура “кубера”: CertManager, Ingress, Istio и другие.
При этом существует много компаний, которые предоставляют Kubernetes как IaaS-решение, где не требуется поднимать и обслуживать окружение для кластера и процессов, которые будут на нем. Или, например, в NUT.Tech, где я сейчас работаю, разрабатываются решения “под ключ” индивидуально под запрос заказчика.
Компоненты и архитектура
Давайте поверхностно коснемся архитектуры самого K8S и его важных компонентов.
Сам кластер K8S состоит из, барабанная дробь, рабочих узлов. В узлах или нодах (Nodes, Worker nodes), помимо контейнеров компонентов самого кластера, размещаются контейнеры наших проектов и сервисов.
Worker nodes состоит из компонентов:
Плоскость управления (Master nodes) управляет рабочими узлами и подами в кластере. Там располагаются компоненты, которые управляют узлами кластера и предоставляют доступ к API.
Control plane состоит из компонентов:
Виды контроллеров
Тестовые кластеры, где потренироваться
Kubectl: как пользоваться, основные команды
При работе с кластером нам потребуется инструмент командной строки kubectl. https://Kubernetes.io/ru/docs/tasks/tools/install-kubectl/
Его можно установить на локальную машину и управлять несколькими кластерами с одной точки.
Основные команды, которые мы часто будем использовать:
Тестовый кластер
Давайте развернем свой k8s кластер на примере kind https://kind.sigs.k8s.io/
После выполнения команды посмотрим и убедимся, что все хорошо и наш кластер появился в списке.
Убедимся, что в kubectl добавился context нашего кластера
Что такое Pods
Pods или поды — это абстрактный объект в кластере K8S, который состоит из одного или нескольких контейнеров с общим хранилищем и сетевыми ресурсами, а также спецификации для запуска контейнеров.
Это главный объект в кластере, в нем прописаны, какие контейнеры должны быть запущены, количество экземпляров или реплик, политика перезапуска, лимиты, подключаемые ресурсы, узел кластера для размещения.
kube-scheduler планирует размещение пода на узлах кластера
kubelet на рабочем узле кластера запускает под
Любители забегать вперед и просто углубиться в тему могут почитать прекрасную статью на github.
Что такое Namespace
Namespace или пространство имен — это абстрактный объект, который логически разграничивает и изолирует ресурсы между подами. Вы можете рассматривать пространство имен как внутренний виртуальный кластер, который поможет вам изолировать проекты или пользователей между собой, применить разные политики квот на свои проекты или выдать права доступа только на определенную область.
default — пространство имён по умолчанию для объектов без какого-либо другого пространства имён
kube-system — пространство имён для объектов, созданных Kubernetes. Там размещаются системные поды кластера
kube-public — создаваемое автоматически пространство имён, которое доступно для чтения всем пользователям (включая также неаутентифицированных пользователей)
Размещение объектов
Давайте разместим свой первый объект в нашем тестовом кластере, для этого создадим свой namespace и положим туда простенький pod с nginx.
Чтобы создать свой namespace, нам нужно передать его спецификацию или манифест в формате yaml.
apiVersion — используемая для создания объекта версия API Kubernetes. Стоит отметить, что из версии к версии версии api могут меняться
kind — тип создаваемого объекта
metadata — данные, позволяющие идентифицировать объект (name, UID и необязательное поле namespace)
spec — требуемое состояние объекта
Давайте создадим test-namespace.yaml со следующим содержанием:
И применим его с помощью команды:
Посмотрим на результат:
Как видим, наш namespace успешно создался. Приступим к созданию своего первого пода (pod). Давайте положим контейнер с NGINX в наш namespace.
Как и с namespace, опишем его. Создадим hello.yaml
Если манифест применился то увидим:
Узнаем развернулся ли наш контейнер
Зайдем через наш браузер на http://localhost:30080/
Если вы видите в браузере:
То контейнер работает, неожиданно. 🙂
Kubernetes для чайников: установка, настройка и основы
Содержание:
Контейнеризация приложений — один из главных трендов современных IT-разработок. Однако, у контейнеров есть один существенный недостаток для массового потребителя — сложная настройка масштабирования.
Решением стали автоматические системы управления контейнеризацией, наиболее популярной из которых является Kubernetes. Это программное обеспечение с открытым исходным кодом от компании Google завоевало признание благодаря сочетанию гибкости, безопасности и мощности.
Cтатья «Kubernetes для чайников» поможет разобраться как устроена платформа управления контейнеризацией, как установить ПО и для чего его можно использовать в дальнейшем. Она будет полезна как для начинающих пользователей Kubernetes, так и для профильных IT-специалистов.
История создания
Проект Kubernetes (сокращенно K8s) вырос из системы управления кластерами Borg. Внутренний продукт поискового гиганта Google получил название в честь кибер-рассы боргов из легендарного сериала «Звездный путь».
Команде разработчиков Google Borg была поставлена масштабная задача — создать открытое программное обеспечение для оркестрирования* контейнеров, которое станет вкладом Google в развитие мировых IT-технологий. Приложение было написано на основе языка Go.
* Под «оркестрированием» подразумевается автоматизированное управление связанными сущностями — контейнерами или виртуальными машинами.
На этапе разработки K8s назвался Project Seven («Проект «Седьмая»). Это было прямой отсылкой к персонажу «Звездного пути» Seven of Nine («Седьмая-из-девяти») — андроиду-боргу, сумевшему вернуть себе человечность. Позже проект получил имя «Кубернетес», от греческого слова κυβερνήτης, которое означает «управляющий», «рулевой» или «кормчий».
В 2014 году общественности представили исходные коды, а годом позже появилась первая версия программы Kubernetes 1.0. В дальнейшем все права на продукт были переданы некоммерческому фонду Cloud Native Computing Foundation (CNCF), куда входят Google, The Linux Foundation и ряд крупнейших технологических корпораций.
Как работает технология
Принципы устройства
Основы работы K8s – применение декларативного подхода. От разработчика требуется указать, чего необходимо достичь, а не способы достижения.
Помимо этого, в Kubernetes могут быть задействованы императивные команды (create, edit, delete), которые позволяют непосредственно создавать, модифицировать и удалять ресурсы. Однако, их не рекомендуется использовать для критически важных задач.
Для развертывания программного обеспечения в Kubernetes применяется база Linux-контейнеров (например, Containerd или CRI-O) и описание — сколько потребуется контейнеров и в каком количестве им потребуются ресурсы. Само развертывание контейнеров происходит на основе рабочих нод — виртуальных или физических машин.
Основные задачи Kubernetes
Преимущества K8s
Kubernetes – удобный инструмент оркестрации контейнеров. Однако, это решение, не работает само по себе, без подготовки и дополнительных настроек. Например, пользователям придется решать вопросы по миграции схем баз данных или разбираться с обратной совместимостью API.
Основные компоненты
Схема взаимодействия основных компонентов K8s
Node (Нода)
Ноды или узлы — виртуальные или физические машины, на которых разворачивают и запускают контейнеры. Совокупность нод образует кластер Kubernetes.
Первая запущенная нода или мастер-нода непосредственно управляет кластером, используя для этого менеджер контроллеров (controller manager) и планировщик (scheduler). Она ответственна за интерфейс взаимодействия с пользователями через сервер API и содержит в себе хранилище «etcd» с конфигурацией кластера, метаданными и статусами объектов.
Namespace (Пространство имен)
Объект, предназначенный для разграничения ресурсов кластера между командами и проектами. Пространства имен — несколько виртуальных кластеров, запущенные на одном физическом.
Pod (Под)
Первичный объект развертывания и основной логический юнит в K8s. Поды — набор из одного и более контейнеров для совместного развертывания на ноде.
Группировка контейнеров разных типов требуется в том случае, когда они взаимозависимы и должны запускаться в одной ноде. Это позволяет увеличить скорость отклика во время взаимодействия. Например, это могут быть контейнеры, хранящие веб-приложение и сервис для его кэширования.
ReplicaSet (Набор реплик)
Объект, отвечающий за описание и контроль за несколькими экземплярами (репликами) подов, созданных на кластере. Наличие более одной реплики позволяет повысить устойчивость от отказов и масштабирование приложение. На практике ReplicaSet создается с использованием Deployment.
ReplicaSet является более продвинутой версией предыдущего способа организации создания реплик (репликации) в K8s – Replication Controller.
Deployment (Развертывание)
Объект, в котором хранится описание подов, количество реплик и алгоритм их замены в случае изменения параметров. Контроллер развертывания позволяет выполнять декларативные обновления (с помощью описания нужного состояния) на таких объектах, как ноды и наборы реплик.
StatefulSet (Набор состояния)
Как и другие объекты, например — ReplicaSet или Deployment, Statefulset позволяет развертывать и управлять одним или несколькими подами. Но в отличие от них, идентификаторы подов имеют предсказуемые и сохраняемые при перезапуске значения.
DaemonSet (Набор даемона)
Объект, который отвечает за то, чтобы на каждой отдельной ноде (или ряде выбранных) запускался один экземпляр выбранного пода.
Job/CronJob (Задания/Задания по расписанию)
Объекты для регулировки однократного или регулярного запуска выбранных подов и контроля завершения их работы. Контроллер Job отвечает за однократный запуск, CronJob — за запуск нескольких заданий по расписанию.
Label/Selector (Метки/Селекторы)
Метки предназначены для маркировки ресурсов. Позволяют упростить групповые манипуляции с ними. Селекторы позволяют выбирать/фильтровать объекты на основе значения меток.
По факту, метки и селекторы не являются самостоятельными объектами Kubernetes, но без них система не сможет полноценно функционировать.
Service (Сервис)
Средство для публикации приложения как сетевого сервиса. Используется, в том числе, для балансировки трафика/нагрузки между подами.
Процесс установки
Установка Kubernetes, рассмотренная ниже, предполагает наличие одного (или более) серверов с операционной системой Centos 7 или Ubuntu 16.04.
Затем открыть «/etc/fstab» с правами root и удалить соответствующую команде строчку «#/swapfile».
Проект Kubernetes изначально действует на основе контейнеров Docker, существенно расширяя их функциональность. Логично, что начинать работу Kubernetes следует именно с установки Docker.
Проще всего остановить выбор на версии, добавленной на текущий момент в репозитории. Ее протестировали разработчики, поэтому данная связка Kubernetes и Docker будет работать наиболее стабильно.
В 2021 году Kubernetes объявили, что, начиная с версии Kubernetes 1.24, откажутся от Docker как основной среды исполнения контейнеров в пользу нативных сред на базе Container Runtime Interface (CRI). В кратком руководстве по переходу, который компания разместила на официальном сайте проекта, сказано, что поддержка контейнеров Docker в старых версиях Kubernetes сохраниться.
Установка контейнеров на Ubuntu 16.04
Чтобы установить Docker на Ubuntu 16.04, необходимо выполнить следующие команды с правами суперпользователя:
Если требуется работать с более новыми версиями контейнеров, запустите команды:
Установка контейнеров в CentOS 7
Для установки Docker на Centos, в консоли нужно выполнить команды:
Установка kubeadm, kubelet и kubectl в Ubuntu
Для работы с Kubernetes понадобится установить компоненты kubeadm, kubelet и kubectl. Эти утилиты понадобятся для создания управления кластером Kubernetes.
В Ubuntu эти компоненты можно установить следующим способом:
Установка kubeadm, kubelet и kubectl в CentOS
В CentOS 7 компоненты устанавливаются следующим образом:
Обращаем внимание! Команда setenforce 0 позволит получить корректный доступ контейнеров к файловой системе хоста. Последняя необходима для функционирования сети у подов.
Нужно убедиться, что «kubelet» и «docker» пользуются одним и тем же драйвером «cgroup». В этом может помочь команда:
Настройка Kubernetes
Инициализация кластера
Нужно указать сервер, на котором установлен K8s (он будет первичным — там будут запускаться остальные операции) и выполнить инициализацию кластера:
Обращаем внимание! Опция «—pod-network-cidr» задает адрес виртуальной сети подов и может отличаться, в зависимости от используемого сетевого плагина.
В данном примере будем использован наиболее распространенный сетевой плагин — Flannel. По умолчанию он использует сеть «10.244.0.0/16», которая была указана в параметре, приведенном выше.
При выполнении команды в консоли, есть вероятность появления ошибок или предупреждений. Ошибки нужно исправлять в обязательном порядке, а на предупреждения можно не обращать внимание, если это не окружение «production».
Если все сделано правильно, на экране отобразится команда, позволяющая присоединить остальные ноды кластера к первичному хосту. Команда может отличаться, в зависимости от структуры кластера. Ее нужно сохранить на будущее.
После выполнения этой команды система выведет примерный результат:
Остается выполнить следующие команды от имени пользователя, который будет управлять кластером:
Настройка CNI
Перед тем, как начать запускать в кластере приложения, нужно выполнить настройку Container Network Interface («сетевой интерфейс контейнера» или CNI). CNI нужен для настройки взаимодействия и управления контейнерами внутри кластера.
Существует много плагинов для создания CNI. В данном примере применяется Flannel, так как это наиболее простое и проверенное решение. Однако, не меньшей популярностью пользуются плагины Weave Net от компании Weaveworks и Calico (Project Calico), обладающие более широким функционалом и возможностями сетевых настроек.
Чтобы установить Flannel, выполните в терминале команду:
В выводе будут отображены имена всех созданных ресурсов.
Добавление узлов (нод) в кластер
Чтобы добавить новые ноды в существующий кластер, требуется выполнить следующий алгоритм:
Данная команда была выведена при выполнении команды «kubeadm init» на мастер-ноде.
Если команда не была сохранена, то можно ее составить повторно.
Получение токена авторизации кластера ( )
Если токена нет, его можно получить, выполнив следующую команду на мастер-ноде:
Вывод должен быть примерно таков:
По умолчанию, срок действия токена — 24 часа. Если требуется добавить новый узел в кластер по окончанию этого периода, можно создать новый токен следующей командой:
Вывод будет примерно таков:
Если значение параметра «—discovery-token-ca-cert-hash» неизвестно, его можно получить следующей командой:
Будет получен примерно такой вывод:
Для ввода IPv6-адреса в параметр « : », адрес должен быть заключен в квадратные скобки. Например:
Дополнительные настройки
В дефолтной конфигурации мастер-нода не запускает контейнеры, так как занимается отслеживанием состояния кластера и перераспределением ресурсов. Ввод данной команды даст возможность запускать контейнеры на мастере, собенно, если кластер содержит лишь одну ноду:
Проверка работоспособности кластера
Проверить, что кластер запустился и правильно работает, можно так:
Вывод будет аналогичен. В нем будут отображены системные POD’ы k8s.
Теперь установку можно считать завершенной. Далее можно продолжить настройку K8s для работы с веб-приложениями. Например, подключить диспетчер пакетов «helm» для автоматического развертывания приложений или контроллер «nginx ingress», отвечающий за маршрутизацию внешнего трафика.
Заключение
Несмотря на кажущуюся сложность настройки, K8s стоит времени, потраченного на его изучение. Kubernetes — наиболее совершенный на сегодня инструмент оркестрирования контейнеров. Он позволяет не только автоматизировать процесс развертывания, но и максимально упрощает дальнейший процесс работы с массивами контейнеров.
С помощью этого краткого руководства начать работу с K8s сможет даже начинающий пользователь. В дальнейшей работе с платформой поможет подробная официальная документация, доступная, в том числе, на русском языке.