Вы наверняка знаете, Kubernetes просто повсюду. От разработчиков, тестировщиков, DevOps-инженеров и системных аналитиков ожидают умения работать с этим инструментом. Даже продакт-менеджеры иногда интересуются, что это такое.
Если вы только начинаете знакомство с Kubernetes и хотите понять, с чего начать, эта статья для вас. Разберем, какие задачи он решает, какие у него основные объекты и как можно управлять кластером без сложных команд в терминале. Подробнее читайте внутри.
Автор: Артем Шумейко.
Используйте навигацию, если не хотите читать статью полностью
Как все работало до Kubernetes
Зачем вообще нужен Kubernetes? Давайте разбираться. Часто приложение представляют так: фронтенд + веб-интерфейс + бэкенд.
В бэкенд входят сервисы: основной, авторизации, уведомлений (нотификации) и платежей. Но есть один нюанс — неравномерная нагрузка. Люди авторизуются редко, делают заказы чуть чаще, получают уведомления еще чаще. Поэтому, чтобы обрабатывать большую нагрузку, мы разворачиваем каждый сервис в нескольких экземплярах.
Если располагать сервисы на одном сервере, не будет отказоустойчивости. Падает один сервер и падает все приложение. Нужно разнести сервисы по разным серверам. Например, арендовать три виртуальные машины или три физических сервера и распределить все эти сервисы. Так, если один сервер упадет, мы выживем.
Следующая задача — распределить нагрузку. Для этого используем балансировщик. Но как он поймет, куда перенаправлять трафик?
Нужно руками в нем указать все IP-адреса всех серверов и порты, где находятся приложения. Со временем нагрузка увеличивается, сервис растет, становится больше пользователей. Необходимо добавить еще один экземпляр основного сервиса. И снова приходится обновлять все руками, что очень неудобно.
В какой-то день все сервисы на третьем сервере умирают, а балансировщик продолжает отправлять туда запросы. Он не понимает, что с ними что-то не так. Самостоятельно сервисы не поднимутся, придется делать это руками. При этом пострадали мы и пользователи, у которых в лучшем случае была большая задержка, а в худшем — все зависло на полчаса.
С обновлениями приложения ситуация еще интереснее. Можем убить сразу все пять сервисов, а потом поднять их заново. Но тогда будет даунтайм, и пользователи будут ждать. Поэтому выключать сервисы надо по очереди. Первый сервис выключили, потом включили его новую версию. Если все хорошо, то версию деплоим на все остальные серверы. Да, снова руками, снова неудобно.
Потом в новом обновлении нашлась утечка памяти. Нужно откатываться на прошлую версию. И конечно, нам нужно убивать попеременно каждый сервис и заново запускать со старой версией.
Это был маленький кусочек системы. В небольших компаниях это выглядит вот так:
А в крупных компаниях — примерно вот так:
И чтобы всем этим управлять, на помощь пришел Kubernetes.
Managed Kubernetes на выделенных серверах
Снизьте расходы на IT-инфраструктуру и улучшите производительность микросервисов.
Kubernetes
Kubernetes — это система с открытым кодом которая автоматизирует развертывание, масштабирование и управление контейнеризированными приложениями. Она помогает запускать, масштабировать и поддерживать приложения, упрощая работу с ними и распределяя нагрузку между сервисами.
Он решает следующие задачи:
деплоймент — поднимает новые экземпляры приложения;
самовосстановление — следит за приложением, если упало, автоматически перезапускает;
управление — контролирует жизненный цикл приложения;
масштабирование — добавляет или уменьшает количество экземпляров приложения, в зависимости от нагрузки;
балансировка трафика — распределяет нагрузку, по экземплярам приложений.
Но Kubernetes не хранит данные и образы приложений, а также не собирает Docker-образы.
Как устроен Kubernetes
Пройдемся по верхам. Нода (node) — это сервер или виртуальная машина. Можно представлять себе компьютер в дата-центре. Есть мастер-нода (master node) — центр управления, мозг Kubernetes. Он управляет всем остальным. И есть воркер-ноды (они же worker node, или просто воркеры) — серверы или виртуальные машины, на которых запущены приложения. Там крутятся API, фронтенд, приложения, базы данных и т. д.
Чтобы быть отказоустойчивым, Kubernetes использует три мастер-ноды. Что находится в них? Первое и самое простое — etcd. Это база данных формата «ключ — значение», которая содержит текущую конфигурацию и состояние кластера Kubernetes. Например, в ней хранится информация о развертываемых приложениях, настройках и ресурсах. Есть scheduler, который определяет, на какую из воркер-нод деплоим приложение.
Далее — API-сервер. С ним общаются все: от разработчика до нод. Никто напрямую в базу ETCD не лезет и ей не управляет. API — это единственная точка входа в кубер. И последнее — Controller manager. Программа, которая следит за тем, чтобы все, что попросили, было сделано.
Управлять Kubernetes и в целом работать с ним можно через kubectl. Это интерфейс в командной строке, с помощью которого получаем информацию о Kubernetes.
Что такое minikube
Minikube создает кластер Kubernetes на локальной машине. Для него достаточно одной машины, одного ноутбука. В данном случае, Mac OS.
Устанавливается в две команды и запускается через minikube start. Например, мы можем в командной строке вызвать kubectl и get nodes. Так как K8s развернут на одной машине, воркер- и мастер-ноды объединены.
Не всем удобно работать с Kubernetes через командную строку. Поэтому придумали утилиту для визуального отображения — Kubernetes dashboard. Если здесь выбрать все namespaces, то виден состав кластера. Например: Deployments, Pods, Replica Sets.
Помимо этого, можно посмотреть, сколько CPU занято, сколько используется ядер и памяти и даже посмотреть какие-то логи.
Deployment
Начнем с самого маленького, что можно представить. Под — минимальная концепция в Kubernetes. K8s не оперирует термином контейнер, чаще всего говорят о подах. И обычно в поде всего один Docker-контейнер (приложение).
Deployment — манифест или просто yaml-файл, в котором описываем, что нам надо. Deployment не сразу создает под, он сначала создает, ReplicaSet. Она уже поднимает поды и следит за тем, что поднято и что работает.
А как вообще ведется работа с трафиком в Kubernetes? Как одному поду достучаться до другого? И самое главное — как пользователь по ту сторону интернета может пробросить запрос. Когда на пути все эти слои Kubernetes до нашего приложения.
Чаще всего ставится Ingress Controller. Ingress содержит правила как распределять входящий трафик из интернета. Еще часто ставят Nginx. И после того, как он принял запрос, его отправляет в Service. И Service уже понимает, в какой под отправить запрос. Вы можете спросить: «Нам этот ваш Service не нужон А зачем нам этот Service? Почему нельзя сразу в под отправить, зачем лишние сущности?».
Так вот, поды — это наше приложение. Они разворачиваются на разных нодах, разных серверах или у них меняется IP адрес, местоположение.
А внутри Kubernetes может быть 15 подов: по пять на каждом сервере. Чтобы понять, куда послать запрос, нужен Service.
На каждом сервере, на каждой ноде есть программа. Она называется kube-proxy. Именно она принимает запрос от условного Nginx. И уже он балансирует нагрузку и понимает, в какой под нужно отправить запрос.
Еще один нюанс, на каждой ноде есть еще один процесс — kubelet. Он отвечает за то, чтобы было развернуто ровно столько подов, сколько попросили, определенное количество реплик приложения.
Kubelet занимается тем, что проверяет каждые несколько секунд, жив ли под. DevOps-инженеры или разработчики могут указать, как часто нужно проверять, что приложение живо, а также задать условия проверок.
Что делать с базами данных (PostgreSQL, Redis, Kafka), которым нужно определенное состояние? Их нельзя просто так развернуть на другой ноде. У каждого приложения есть свое хранилище, и к нему должен привязываться конкретный под. Поэтому вместо deployment, есть сущность StatefulSet.
Она позволяет каждому экземпляру приложения выдавать конкретные IP адреса, помечать их конкретными именами, реплицировать всю нагрузку и добавлять health Check. Чаще всего StatefulSet в сыром виде не используется. Обычно используют уже готовые образы.
А теперь давайте перейдем к самому интересному — немного поработаем с Kubernetes и запустим собственное приложение. Если хочется увидеть весь процесс настройки и деплоя в действии, предлагаем посмотреть на реальный пример в видео.
Пошаговый гайд по развертыванию кластера K8s и настройке приложения
Kubernetes: торт или не торт?
Kubernetes — один из самых востребованных инструментов в IT-индустрии, и его популярность продолжает расти. По последним данным, в 2024 году 96% компаний уже использовали или тестировали кубер. Более того, 45% опрошенных работают с пятью и более кластерами, а у 15% в продакшене развернуто более 50.
В России Kubernetes также занимает лидирующую позицию: 57% респондентов используют его для оркестрации. Почему это так? Потому что Kubernetes решает сложнейшие задачи автоматизации развертывания, масштабирования и управления приложениями.
Итак, несмотря на широкий спектр применения Kubernetes, самостоятельная поддержка кластера нередко оказывается сложной задачей. Часто в командах не хватает необходимых ресурсов или компетенций, а содержание полной команды DevOps-специалистов может быть экономически невыгодным.
В таких случаях часть функций стоит доверить провайдеру Managed Kubernetes. Такой подход упрощает работу с кластерами, включая их развертывание, масштабирование и обслуживание инфраструктуры в целом. Сервис гарантирует стабильную работу за счет отказоустойчивости и автомасштабирования. Вы можете создать кластер любой конфигурации в несколько кликов.
Доступность кластеров в Managed Kubernetes определяется и фиксируется в SLA, поэтому, пользуясь услугой, компания может снять с себя часть рисков и делегировать их провайдеру услуги. Это позволяет сосредоточиться на развитии продукта, а не на настройке инфраструктуры.
Знание Kubernetes открывает двери к созданию современных, гибких и стабильных IT-инфраструктур, которые поддерживают бизнес в условиях быстрого роста и изменений. Это означает готовность к новым цифровым вызовам.
Вы только начинаете рассматривать Kubernetes или уже давно используете? Делитесь мнением в комментариях.
