Развертывание одного контейнера — задача простая. Десяти — вполне посильная. Но как только вы начинаете запускать сотни контейнеров на десятках машин, ручное управление перестает быть просто трудным и становится невозможным. Вы теряете контроль над тем, какой контейнер где находится. Сервер выходит из строя, и ваше приложение исчезает до тех пор, пока кто-нибудь не проснется, чтобы его перезапустить. Всплески трафика перегружают вашу систему еще до того, как вы успеете запустить новые экземпляры. Именно здесь на сцену выходит Kubernetes. Это не просто очередной инструмент DevOps. Это слой оркестрации, который рассматривает управление контейнерами как задачу управления, а не просто как выполнение набора скриптов.

Почему скрипты в конечном итоге подводят

Большинство команд начинают с shell-скриптов или базовой автоматизации. Они пишут команды для скачивания образов, запуска контейнеров, отслеживания логов и перезапуска упавших процессов. Такой подход работает для проверки концепции (PoC), но он рушится под реальной нагрузкой. Микросервисы взаимодействуют друг с другом на разных хостах, полагаются на специфические переменные окружения, нуждаются в постоянном хранилище, которое переживает перезапуск контейнеров, и ожидают согласованной работы сети между версиями. Скрипт не может автоматически переназначить нагрузку, если виртуальная машина исчезает. Он не может распределять сетевой трафик между исправными экземплярами, обходя те, что застряли в цикле перезагрузки (crash loop). Kubernetes решает эту проблему, возлагая ответственность за такие решения на сам кластер. Вы описываете желаемое состояние, а система непрерывно поддерживает его.

Три возможности, которые он дает

Kubernetes предоставляет три основные возможности, которые заменяют ручное «тушение пожаров» автоматизированной надежностью.

Высокая доступность (High availability) означает, что ваши приложения остаются в сети, даже если части вашей инфраструктуры выходят из строя. Если контейнер падает, Kubernetes заменяет его в течение нескольких секунд. Если целый рабочий узел (worker node) отключается, планировщик замечает отсутствие сигнала heartbeat и переносит затронутые рабочие нагрузки на исправные машины в других частях кластера. Система постоянно следит за заданным вами состоянием, исправляя отклонения без вмешательства человека.

Масштабируемость (Scalability) означает, что ваши приложения растут вместе с вашими пользователями. Вместо того чтобы выделять двадцать серверов только для того, чтобы пережить двухчасовой пик трафика, вы определяете важные метрики, такие как использование CPU или задержка запросов, и позволяете кластеру добавлять новые экземпляры контейнеров при достижении пороговых значений. Когда спрос падает, количество реплик снова уменьшается. Вы платите за то, что вам нужно, и тогда, когда это нужно.

Аварийное восстановление (Disaster recovery) означает, что ваши данные и конфигурация восстанавливаются после сбоя. Kubernetes хранит всё состояние кластера в распределенном хранилище «ключ-значение». Если катастрофический сбой уничтожит рабочие узлы или даже часть control plane, это сохраненное состояние позволит системе восстановить ваши рабочие нагрузки именно в том виде, в котором они были настроены. Ваши данные возвращаются, потому что оркестратор помнит, как они должны были выглядеть.

Устройство: Мозг и Мышцы

Кластер Kubernetes имеет две фундаментальные роли, которые в данном описании представлены как мозг и мышцы, и эта аналогия отлично работает на практике.

Master Node (Мастер-узел) — это мозг. Он не запускает ваши клиентские приложения. Вместо этого он размещает компоненты control plane, которые планируют задачи, управляют состоянием кластера и реагируют на изменения. Когда вы вводите команду или отправляете конфигурационный файл, мастер-узел решает, где должна находиться рабочая нагрузка, исправна ли она и что делать, если это не так.

Worker Nodes (Рабочие узлы) — это мышцы. На каждом рабочем узле запущен легковесный агент, который взаимодействует с мастером и использует среду выполнения контейнеров (container runtime) для выполнения самих подов (pods). Именно на этих узлах ваш программный код потребляет ресурсы CPU и памяти. Добавьте больше рабочих узлов — и ваш кластер получит дополнительную мощность. Добавьте больше мастер-узлов, настроенных для обеспечения избыточности, — и ваш control plane станет устойчивым к отдельным отказам оборудования.

Поды, контейнеры и сервисы

Для работы с Kubernetes необходимо понимать три термина, которые определяют, как упаковывается и как вызывается программное обеспечение.

Контейнеры (Containers) — это пакеты, которые объединяют ваше приложение с его зависимостями, библиотеками и конфигурацией. Они изолируют программное обеспечение от базового хоста, благодаря чему оно работает одинаково в средах разработки, тестирования и эксплуатации.

Поды — это наименьшая развертываемая единица в Kubernetes. Под объединяет один или несколько контейнеров, которым необходимо совместно использовать ресурсы. Они используют одно и то же сетевое пространство имен и могут иметь доступ к одним и тем же локальным томам хранения. Это важно: вы не развертываете «голый» контейнер напрямую. Вы развертываете под, который его содержит. Поды также намеренно эфемерны. Они создаются, уничтожаются и заменяются по мере изменения условий. Их жизненный цикл динамичен по своей сути.

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

Kubernetes в масштабе: пример Netflix

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

С чего начать: YAML, JSON и API-сервер

Начало работы с Kubernetes означает отказ от императивного подхода «click-ops» в пользу декларативной конфигурации. Вы описываете то, что хотите получить, в файлах YAML или JSON. Эти манифесты описывают всё: от образа контейнера до количества реплик, открытых портов, переменных окружения и монтирования хранилищ. Как только файл готов, вы отправляете его на API-сервер на мастер-узле. Control plane принимает это объявление, сохраняет его в базе данных состояния кластера, а затем приступает к тому, чтобы привести реальность в соответствие с вашим описанием. Вы не говорите Kubernetes точно, как выполнять свою работу. Вы говорите ему, каким должен быть конечный результат, а он сам вычисляет необходимые шаги.

Главный вывод

Kubernetes требует времени на обучение. Терминология поначалу кажется перегруженной. Здесь много движущихся частей, а отладка распределенной системы по своей природе сложнее, чем отладка одного сервера. Но наградой становится операционное спокойствие. Вы перестаете «нянчиться» с отдельными машинами. Вы перестаете молиться, чтобы ваши скрипты запуска сработали во время сбоя в 3 часа ночи. Вы начинаете проектировать систему с расчетом на сбои по умолчанию, предполагая, что узлы будут выходить из строя, и доверяя оркестратору сохранять работоспособность вашего приложения. Эта смена парадигмы — от надежды на то, что ничего не сломается, к знанию того, что система справится с поломкой, — и делает все усилия оправданными.

Источник: What Is Kubernetes? Kubernetes Explained in 15 Mins

Дополнительное сообщество для обучения: GyaanSetu AI on Telegram