Я не явялсюь разработчиком k8s, все что написано в статье исключительно мой опыт взаимодействия с этим средством оркестрации. Если есть неточности, буду рад увидеть отсылки на них в комментариях. Спасибо!
Также в статье будут использоваться такие слова как: k8s, кубер, руль, штурвал, рулевой, дирежер, оркестратор, кубершмекис, кубермекис, главный по контейнерам. В рамках этой статьи это все синонимы — kubernetes! Не пугаемся.Также хочу упомянть что это моя первая статья на хабре, пожалуйста не кидайтесь камнями. Спасибо!
Еще до открытия для себя практик DevOps я использовал Docker для упаковки и быстрой доставки кода на серверы (всё делалось вручную, я еще не знал про CI/CD xD). Со временем мои приложения становились сложнее, появлялись микросервисы, уходил монолит. И управлять вручную или через Portainer всей архитектурой было слегка сложновато: простой, куча вопросов, падение контейнеров, рост нагрузки и всё в этом духе. Тогда‑то я и открыл для себя Кубер.
Если представить ваше приложение как оркестр, где каждый микросервис играет свою партию (БД, бэкенд, фронтенд и тому подобное), то K8S — это «дирижер», который управляет всем этим, руководит всем, что происходит на сцене.
Что же делает K8S, что он так полюбился всем, кто ценит легко масштабируемую и отказоустойчивую инфраструктуру?
Автоматически поддерживает порядок. Вы говорите Kubernetes, какое состояние системы хотите видеть (например: «запущено 3 копии моего веб‑сервера и 1 копия базы данных»). K8s берёт на себя всю работу по поддержанию этого состояния. Если одна из копий веб‑сервера «заболеет» и упадёт, дирижёр это заметит и немедленно запустит новую взамен. Это и есть отказоустойчивость.
Гибко масштабирует оркестр. Если к вашему приложению пришло много пользователей и нагрузка выросла, вы можете одной командой сказать Kubernetes: «теперь нужно 10 копий веб‑сервера». Он равномерно распределит новую нагрузку. Когда пик пройдет, можно так же легко вернуться к 3 копиям.
Управляет обновлениями без пауз. K8s умеет аккуратно обновлять ваше приложение «на лету» по разным стратегиям (например, постепенно заменяя старые контейнеры на новые). Если что‑то пошло не так, он может так же легко откатить изменения. Это обеспечивает непрерывность работы (zero‑downtime deployments).
Работает с множеством серверов. Kubernetes изначально создан для управления не одним сервером, а целым кластером — группой машин (нод), которые работают вместе. Он сам решает, на какой из машин запустить тот или иной контейнер, чтобы оптимально использовать ресурсы
Структура этого вашего рулевого
Что бы эффективно управлять K8S, очень важно понимать его структуру и какие компоненты в нем есть. Пугаться этого не стоит, мы разберем все на аналогиях. Начнем с базы и потихоньку погрузимся в дебри.
Кластер k8s состоит из двух вещей: Ноды и Управляющие компоненты (Control Plane).
Начнем с нод, нода это физический сервер или виртуальная машина, на которых непосредственно запускается ваше приложение. Есть два вида нод: Master и Slave (ну или worker, кому как удобнее).
Master нода отвечает за управление всем кластером и отвечает за распределение нагрузки между другими нодами. Их может быть несколько штук в кластере, об этом поговорим чуть позже.
Slave нода отвечает за сами приложения, на них держиться вся нагрузка и на них стартуют ваши микросервисы.
Важный момент! В небольших или учебных кластерах Master‑узел может также быть и Worker‑узлом, чтобы на нем тоже можно было запускать приложения (это называется
schedule workloads on the control plane node). Но в продакшене так делать нельзя, в чем смысл тогда от кубершмекиса?
Исходя из этого описания можно сделать вывод, что Master отвечает за управление кластером, а Slave управляется мастером и запускает на себе ваши приложения.
Теперь подробнее разберемся с нодами, очевидно что на них есть какие‑то компоненты, которые запускают ваши приложения. Всего на ноде должно быть 3 ключевых компонента:
Kubelet — это главный компонент на узле, он общается с Control Plane. Он следит чтоб ваши приложения которые должны работать на этом узле, дейстивтельно работали и были в нормально состоянии. Представим что kubelet это прораб, который получает от главного архитектора чертежи и следит чтоб строители делали все по чертежу.
Container Runtime. k8s — это не средство контейнризации, он всего лишь следит за вашими контейнерами. Container Runtime это ПО которое как раз и запускает контейнеры, за которыми уже следит K8S. Container Runtime может быть — Docker, CRI‑O и мой самый любимый вариант containerd. Это «инструменты» в руках прораба.
kube‑proxy — это компонент который отвечает за сетвеое взаимодействие между контейнерами. Он выпускает «правила» которые обеспечивают связь между вашим контейнером и внешним миром. Это своего рода диспетчер связи на ноде.
Все эти компоненты нужно ставить на каждую ноду! Это неотъемлемая часть K8S!
Теперь разберемся с Control Plane. Мозговой центр, главный архитектор, называйте как хотите. Это часть кубера которая управляет всем штурвалом. В Control Plane входит 4 основных компонента.
API Server (kube‑apiserver). Это единственная и самая важная точка входа в кластер для управления. Все‑все взаимодействия будь то вы через команду
kubectl(о нем чуть позже), или компоненты кластера между собой проходят через API Server. Его можно сравнить с «приемной» или «диспетчерской». Вы приходите, говорите, что хотите сделать, а он уже распределяет задачи.etcd. Если сказать грубо, это база данных типа «ключ — значение». В ней хранится вся конфигурация, состояние и в целом важная для жизни кластера информация. Если etcd умрет, то умрет и кластер! Уже из опыта могу сказать что etcd очень плохо относиться к миграциям на виртуализации и перезагрузкам. Это я написал на всякий случай. Вдруг вы собираетесь разворачивать кубер в каком нибудь ESXI или Proxmox. Там есть тонкости!
Scheduler следит за новыми запросами на запуск приложений. Например вы попросили запустить 3 копии вашего сайта. Sheduler принимает решение что на какой worker ноде запустить. Решение будет очень рациональным, оно состоит из кучи факторов вроде: свободного количества RAM, CPU, требования самого приложения и тд и тп.
Controller Manager (kube‑controller‑manager). Это смотритель за кластером, он отслеживает состояние кластера которое вы описали, сравнивает его со значениями в etcd и в случае расхождения желаемого состояния и данных c etcd, он начинает предпринимать действия. Или например вы захотели развернуть 3 копии вашего сайта, Controller Manager видит что их 2. Он через API Server отдает команды на создание еще одной копии. Или если упала нода, он скомандует запустить все приложения на другой ноде.
Простая аналогия
API Server — это главный телефонный аппарат и секретарь мэра города (кластера).
etcd — это большой городской архив, где хранятся все указы и данные о каждом жителе.
Scheduler — это начальник ЖКХ, который решает, в каком доме (узле) поселить новую семью (пода).
Controller Manager — это мэр города, который постоянно сверяется с архивом (etc) и отдает распоряжения через секретаря (API Server), чтобы в городе был порядок.
Kubelet — это управдом, который следит за порядком в своем доме (узле).
Kube‑proxy — это почтальон и организатор связи внутри дома.
Понимая эту структуру, вы уже не просто бездумно выполняете команды, а представляете, какой компонент за что отвечает. В следующей части мы воспользуемся этими знаниями и выберем инструмент для развертывания нашего первого кластера, где все эти компоненты оживут.
Информация взята с:
olku
Где можно почитать про тонкости поднятия кубера на Proxmox?