Как устроен Kubernetes: архитектура, компоненты и объекты

Что такое Kubernetes?

Kubernetes (сокращённо k8s) — open-source система оркестрации контейнеров: она решает, на каком сервере запускать приложение, перезапускает его при сбое, масштабирует под нагрузку и обновляет без простоя. Сегодня это стандартная платформа для распределённых систем и микросервисов.

• Предок: Borg, внутренняя система Google
• Лицензия: open source
• Работает на: кластере из многих серверов

Какую проблему решает Kubernetes?

Раньше запускать приложения было просто: большинство из них жило на одном сервере, и управлять ими было несложно. Потом стали популярны микросервисы, и вместо одного приложения на одном сервере компании начали держать сотни приложений на сотнях серверов.

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

Как Kubernetes связан с Google Borg?

Google столкнулся с этой проблемой в гигантском масштабе и построил внутреннюю систему Borg. Borg управлял приложениями на тысячах серверов и автоматизировал планирование размещения (scheduling), масштабирование и самовосстановление (self-healing).

Годы спустя на многих тех же идеях построили Kubernetes и выпустили его как open-source систему. Снаружи Kubernetes может выглядеть простым, но внутри кластера множество компонентов постоянно работают над тем, чтобы ваши приложения продолжали работать. Дальше разберём, что происходит за кулисами.

Как устроена архитектура Kubernetes?

Архитектура Kubernetes — это распределённая система: она работает не на одном сервере, а на группе серверов, объединённых в кластер. Кластер состоит из двух частей: control plane, который принимает решения, и worker nodes, на которых запускаются контейнеры.

• Части: control plane + worker nodes
• Серверы: виртуальные машины или bare metal
• Связь: общая сеть кластера

Что такое кластер Kubernetes?

Кластер Kubernetes — группа серверов, которые работают вместе. Это могут быть виртуальные машины или физические серверы (bare metal), а компоненты Kubernetes распределены по ним и общаются через единую сеть. На самом верхнем уровне кластер состоит из двух ключевых частей: control plane и worker nodes.

Что такое control plane в Kubernetes?

Control plane — «мозг» кластера Kubernetes. Он принимает глобальные решения для всего кластера: распределяет приложения по узлам, следит за здоровьем системы и удерживает кластер в желаемом состоянии.

В control plane входят пять компонентов:

• kube-apiserver;
• etcd;
• kube-scheduler;
• kube-controller-manager;
• cloud-controller-manager.

Что такое worker node в Kubernetes?

Worker node (рабочий узел) — «мышцы» кластера Kubernetes. Он отвечает за запуск рабочих нагрузок (workloads), то есть контейнеризированных приложений. На каждом worker node работают три компонента:

• kubelet;
• kube-proxy;
• container runtime (среда выполнения контейнеров).

Иначе говоря, control plane решает, что и где запускать, а worker nodes запускают контейнеры.

Как Kubernetes переживает отказ сервера?

В кластере может быть много узлов control plane и много worker nodes, и их число обычно зависит от количества развёрнутых нагрузок. В продакшне несколько узлов обоих типов — норма: такая конфигурация держит систему стабильной, и приложения продолжают работать, даже если часть машин отказала или недоступна.

У Kubernetes прочная децентрализованная структура: при отказе узла он автоматически переносит нагрузку на здоровые узлы. Kubernetes непрерывно проверяет и чинит систему, поэтому становится фундаментом надёжной самовосстанавливающейся распределённой системы.

Что такое желаемое состояние и reconciliation loop в Kubernetes?

Желаемое состояние (desired state) — это описание того, каким должен быть кластер, например «три реплики приложения». Фактическое состояние (actual state) — то, что работает в кластере прямо сейчас. Reconciliation loop — непрерывный цикл, в котором Kubernetes сравнивает одно с другим и автоматически устраняет расхождения.

• Модель: декларативная
• Кто сверяет: контроллеры
• Результат: самовосстановление

Как работает reconciliation loop в Kubernetes?

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

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

Этот непрерывный процесс проверки и исправления называется reconciliation loop (цикл согласования). Это ключевая идея, на которой держится вся работа Kubernetes.

Из каких компонентов состоит control plane Kubernetes?

Control plane Kubernetes состоит из пяти компонентов: kube-apiserver — центральный узел всей связи в кластере, etcd — хранилище данных кластера, kube-scheduler — планировщик размещения подов, kube-controller-manager — контроллеры, которые держат желаемое состояние, и cloud-controller-manager — интеграция с облачным провайдером.

Control plane принимает глобальные решения для кластера, но делает это не одним компонентом. У каждой из пяти частей своя роль:

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

Что такое kube-apiserver?

kube-apiserver — центральный компонент control plane Kubernetes, который предоставляет Kubernetes API. Через него проходит почти каждая операция в кластере: и запросы пользователей, и обращения внутренних компонентов, которые не общаются друг с другом напрямую.

• Где работает: control plane
• Роль: единая точка входа
• Протокол: REST API поверх HTTPS/TLS

Как работает kube-apiserver?

Остальные компоненты кластера не разговаривают друг с другом напрямую: они читают и обновляют состояние кластера через kube-apiserver. Это позволяет частям работать независимо, но оставаться связанными через центральную систему. Вы тоже никогда не обращаетесь к узлам Kubernetes и их компонентам напрямую — только через API-сервер. Он обрабатывает ваши запросы и обновляет состояние кластера.

Всё общение между API-сервером и другими компонентами зашифровано по TLS. Это не пускает посторонних и защищает связь внутри кластера. Без API-сервера кластер работать не может.

Какие задачи выполняет kube-apiserver?

1. Открывает API-эндпоинт кластера. Это единственный компонент control plane, с которым может общаться внешний мир. Команда kubectl (консольная утилита для работы с Kubernetes) отправляет запрос API-серверу по HTTPS. Приложение, которое разворачивается в кластере, тоже общается с API-сервером.
2. Служит единой точкой входа для всех операций. Все запросы к кластеру — и ваши, и внутренних компонентов Kubernetes — идут через API-сервер. Компоненты не общаются друг с другом напрямую, поэтому у API-сервера всегда есть полная картина происходящего в кластере.
3. Аутентифицирует и авторизует. Проверяет, кто отправил запрос, а затем — есть ли у него право на это действие. Если любая проверка не пройдена, запрос останавливается на этом шаге.
4. Уведомляет остальную систему об изменениях. Как только изменение сохранено, API-сервер оповещает каждый заинтересованный компонент.
5. Хранит состояние кластера в etcd. Ничто, кроме API-сервера, не читает и не пишет в etcd напрямую: каждое изменение сначала проходит через него, и это сохраняет данные чистыми и согласованными.

Поскольку API-сервер хранит всё состояние кластера в etcd, etcd становится источником истины для всего кластера Kubernetes.

Что такое etcd в Kubernetes?

etcd — распределённое хранилище ключ-значение, в котором Kubernetes хранит все данные кластера: что запущено, что должно быть запущено и как настроен каждый компонент. Поэтому etcd называют единственным источником истины (single source of truth) для кластера Kubernetes.

• Модель: распределённое ключ-значение
• Доступ: только через kube-apiserver
• Критичность: требует регулярных бэкапов

Как работает etcd в Kubernetes?

API-сервер Kubernetes сохраняет в etcd всю полученную информацию. Планировщик и controller manager следят за изменениями через API-сервер и помогают удерживать кластер в желаемом состоянии, а сам API-сервер читает данные из etcd. Так etcd становится центральным хранилищем всего кластера.

В продакшне etcd критически важно регулярно бэкапить. Если данные etcd потеряны, кластер теряет своё состояние: Kubernetes больше не знает, какие приложения запущены, какие узлы существуют и каково желаемое состояние системы.

Какие задачи выполняет etcd?

• Хранит состояние кластера. В etcd лежат все объекты Kubernetes, включая Pods, Deployments, Services, Nodes, ConfigMaps и Secrets.
• Служит источником истины. Всё состояние кластера хранится в etcd, и все компоненты опираются на эти данные при принятии решений.
• Позволяет восстановить кластер. Из бэкапа etcd можно восстановить всё состояние кластера после сбоя.

etcd — единственный компонент control plane, который хранит состояние (stateful), поэтому им нужно аккуратно управлять и обязательно его бэкапить.

Что такое kube-scheduler?

kube-scheduler — планировщик Kubernetes, который решает, на каком узле будет работать под. Сам он под не запускает: он только выбирает подходящий узел по доступным ресурсам и требованиям пода и записывает это решение через API-сервер.

• Где работает: control plane
• Алгоритм: фильтрация, затем оценка узлов
• Результат: под привязан к узлу

Как работает kube-scheduler?

Под (pod) — наименьшая единица, которую можно развернуть в Kubernetes, обёртка над одним или несколькими контейнерами. Только что созданный под существует в кластере без назначенного узла. Планировщик постоянно ищет такие поды и распределяет их по подходящим узлам с учётом доступных ресурсов и настроек пода.

Какие шаги выполняет kube-scheduler?

1. Следит за неназначенными подами. Планировщик наблюдает за API-сервером и ищет поды, которые после создания не привязаны ни к одному узлу.
2. Получает список доступных узлов — информацию обо всех worker nodes и их свободных ресурсах.
3. Фильтрует узлы. Отбрасывает узлы, которые не удовлетворяют требованиям пода: не хватает CPU или памяти, не хватает GPU, узел на обслуживании, поду нужен GPU, а на узле его нет.
4. Оценивает оставшиеся узлы. Выставляет каждому оценку с учётом доступных ресурсов, политик планирования, балансировки нагрузки и других факторов, и выбирает узел с наибольшей оценкой.
5. Обновляет информацию о поде. Через API-сервер записывает в объект Pod выбранный узел.

Как только планировщик назначил под на узел, фактически запускает контейнер kubelet на этом узле.

Что такое kube-controller-manager?

kube-controller-manager — компонент control plane Kubernetes, который запускает набор контроллеров. Каждый контроллер отвечает за свою задачу, следит за состоянием кластера через Kubernetes API и, найдя расхождение между желаемым и фактическим состоянием, исправляет его.

• Где работает: control plane
• Принцип: control loop
• Даёт: self-healing, автомасштабирование, rolling updates

Как работает kube-controller-manager?

Пример. Приложение в Kubernetes настроено на три реплики — это желаемое состояние кластера. Одна реплика падает, и фактическое состояние становится 2 вместо 3. Контроллер замечает разницу и автоматически создаёт новую реплику, чтобы их снова стало три. Так контроллеры непрерывно сверяют состояние кластера с желаемым.

Все контроллеры в Kubernetes работают как управляющий цикл (control loop): непрерывно отслеживают состояние кластера через API-сервер и сравнивают фактическое состояние с желаемым. Именно это делает Kubernetes самовосстанавливающимся и сильно автоматизированным, а заодно даёт автомасштабирование и плавные обновления (rolling updates).

Какие контроллеры входят в kube-controller-manager?

• Node Controller обнаруживает отказы узлов и реагирует, когда узлы становятся недоступны.
• Replication Controller следит, чтобы работало нужное число реплик подов.
• Deployment Controller проводит rolling updates и удерживает Deployment в желаемом состоянии.
• Endpoint Controller обновляет эндпоинты Service, когда меняются поды.
• Namespace Controller управляет жизненным циклом namespace и очисткой ресурсов.
• Service Account Controller создаёт сервисные аккаунты и токены и управляет ими.
• Job Controller следит, чтобы задачи (Jobs) завершались успешно.

Что такое cloud-controller-manager?

Cloud-controller-manager (CCM) — компонент control plane Kubernetes, который связывает кластер с инфраструктурой облачного провайдера: заказывает балансировщики нагрузки, тома хранения и виртуальные машины для узлов. Облачная логика вынесена в него отдельно, поэтому ядро Kubernetes остаётся независимым от конкретного облака.

• Где работает: control plane, опционально
• Облака: любой облачный провайдер
• Даёт: cloud-agnostic ядро

Как работает cloud-controller-manager?

kube-controller-manager отвечает за внутренние задачи кластера. Но Kubernetes нужно получать ресурсы и у облачного провайдера, и этим занимается cloud-controller-manager. Облачная логика отделена от основных компонентов Kubernetes, поэтому Kubernetes работает у разных облачных провайдеров и в собственных дата-центрах (on-premises), и для этого не нужно менять код ядра.

Какие ресурсы заказывает cloud-controller-manager?

• балансировщики нагрузки для Service;
• тома хранения для постоянных данных;
• виртуальные машины для узлов.

Control plane управляет кластером и принимает решения, но сам приложения не запускает. Приложения работают на worker nodes.

Из каких компонентов состоит worker node в Kubernetes?

Worker node Kubernetes состоит из трёх ключевых компонентов: kubelet — агент, который управляет подами на узле, container runtime — среда, которая фактически запускает контейнеры, и kube-proxy — компонент, который направляет сетевой трафик к нужным подам.

На worker nodes работают сами приложения и нагрузки. Control plane решает, какие приложения и где запускать, а worker nodes их выполняют, сообщают о своём состоянии и следят, чтобы всё работало гладко.

Что такое kubelet?

kubelet — главный компонент каждого worker node Kubernetes, агент, который работает на узле как демон systemd. Он получает от API-сервера спецификации подов, назначенных на узел, запускает их контейнеры через container runtime и перезапускает контейнер, если тот упал.

• Где работает: каждый worker node
• Интерфейсы: CRI, CSI, CNI
• Роль: агент узла

Как работает kubelet?

kubelet отвечает за поды, назначенные на его узел, и следит, чтобы все нагрузки на этом узле работали правильно. Он обращается к API-серверу за инструкциями о том, какие поды запускать, получает спецификации подов и через container runtime запускает контейнеры и управляет ими. Если контейнер упал или остановился, kubelet пытается его перезапустить, чтобы сохранить желаемое состояние.

Какие задачи выполняет kubelet?

• Управление контейнерами (CRI). Через Container Runtime Interface общается с container runtime, чтобы запускать контейнеры и управлять ими.
• Логи и exec-доступ. Предоставляет эндпоинты для потоковой выдачи логов и выполнения команд в контейнерах.
• Управление хранилищем (CSI). Через Container Storage Interface работает с плагинами хранения, подключает и монтирует тома.
• Настройка сети (CNI). Через плагины CNI (Container Network Interface) назначает подам IP-адреса и настраивает сетевые правила.
• Мониторинг здоровья. Следит за здоровьем контейнеров и узла и сообщает статус в control plane.

Три главные задачи kubelet на узле: управлять контейнерами через CRI, хранилищем через CSI и сетью через CNI.

Что такое container runtime в Kubernetes?

Container runtime (среда выполнения контейнеров) — компонент worker node, который фактически запускает контейнеры: скачивает образы, создаёт, запускает и останавливает контейнеры. Сам Kubernetes запускать контейнеры не умеет, поэтому использует для этого среду выполнения, например containerd.

• Где работает: каждый worker node
• Интерфейс: CRI
• Примеры: containerd, CRI-O

Как работает container runtime в Kubernetes?

Получив спецификацию пода от API-сервера, kubelet работает с container runtime: тот скачивает нужный образ контейнера из реестра (registry) и запускает контейнер.

Какие задачи выполняет container runtime?

• скачивает образы контейнеров;
• создаёт, запускает и по необходимости останавливает контейнеры;
• обслуживает хранилище и сеть каждого контейнера.

Что такое kube-proxy?

kube-proxy — компонент каждого worker node Kubernetes, который управляет сетью и маршрутизацией трафика внутри кластера. Он следит, чтобы запросы, пришедшие на Service, попадали на правильные поды, даже если эти поды работают на других узлах.

• Где работает: каждый worker node
• Механизм: правила iptables
• Замена: eBPF-инструменты, например Cilium

Как работает kube-proxy?

Приложения в Kubernetes открываются наружу через Service. Service даёт группе подов стабильный IP-адрес и DNS-имя. kube-proxy следит за изменениями подов и сервисов через API-сервер. Когда создаётся новый сервис или падает под, kube-proxy обновляет сетевые правила на своём узле, поэтому трафик всегда идёт на живые и готовые поды.

Исторически kube-proxy использовал iptables — правила в ядре Linux, которые перехватывают сетевые пакеты и перенаправляют их. Этот процесс не виден, но именно он доводит ваш запрос до нужного адресата, пока kube-proxy незаметно переписывает маршруты.

Чем kube-proxy заменяют в современных кластерах?

Многие кластеры постепенно заменяют kube-proxy инструментами на базе eBPF, например Cilium. eBPF выполняет ту же маршрутизацию эффективнее и с гораздо меньшими накладными расходами, особенно в масштабе, где правил iptables набираются тысячи и они начинают бить по производительности.

Что происходит в Kubernetes, когда вы деплоите приложение?

Деплой в Kubernetes проходит шесть шагов: вы описываете желаемое состояние в YAML, kube-apiserver проверяет запрос и сохраняет его в etcd, kube-scheduler выбирает узел, kubelet запускает контейнеры, kube-proxy настраивает сеть, а kube-controller-manager дальше непрерывно удерживает приложение в желаемом состоянии.

Шаг 1. Как задаётся желаемое состояние?

Пользователь пишет YAML-файл, который описывает, что должно работать в кластере. Например:

• какой образ контейнера запускать;
• сколько реплик приложения нужно;
• сколько CPU и памяти нужно приложению;
• сетевые настройки;
• переменные окружения и секреты.

Пользователь применяет эту конфигурацию к кластеру командой kubectl. Контейнеры от этого не запускаются: команда лишь сообщает Kubernetes, как должна выглядеть система. Это и есть желаемое состояние.

Шаг 2. Что делает API-сервер с запросом?

Применённая конфигурация попадает в kube-apiserver — точку входа кластера. API-сервер:

• валидирует запрос;
• аутентифицирует и авторизует пользователя;
• создаёт объекты Kubernetes (например, Pods или Deployments);
• сохраняет желаемое состояние в etcd.

Когда желаемое состояние сохранено в etcd, Kubernetes знает, что приложение должно работать, но ещё не решил, где именно.

Шаг 3. Как планировщик выбирает узел для пода?

kube-scheduler непрерывно следит за API-сервером и ищет новые поды, ещё не назначенные на узел. Найдя их, он фильтрует и оценивает worker nodes по нескольким факторам:

• свободные CPU и память;
• здоровье узла;
• правила affinity и anti-affinity;
• taints и tolerations;
• resource requests и limits.

Выбрав узел, планировщик записывает его в информацию о поде в API-сервере.

Шаг 4. Как kubelet запускает под?

kubelet на выбранном узле тоже следит за API-сервером. Как только он видит, что под назначен на его узел, он сразу начинает действовать: скачивает образ контейнера из реестра, создаёт контейнер через runtime, запускает его и следит, чтобы он продолжал работать.

Если контейнер падает, kubelet его перезапускает. Если узел теряет связь с control plane, kubelet продолжает держать контейнеры запущенными по последней известной ему конфигурации.

Шаг 5. Как kube-proxy настраивает сеть?

Запущенным подам нужно общаться друг с другом и принимать трафик от пользователей. За это отвечают Service и сетевые компоненты Kubernetes. kube-proxy работает на каждом worker node и помогает направлять трафик к правильным подам, а Service даёт стабильный IP и балансирует трафик между многими подами.

Шаг 6. Как controller manager поддерживает желаемое состояние?

Этот шаг и отличает Kubernetes от простого инструмента деплоя: когда приложение запущено, Kubernetes не прекращает работу. Controller manager отслеживает текущее состояние кластера и сверяет его с заданным вами желаемым:

• упал под — создаёт новый;
• отказал узел — переназначает поды, которые на нём работали;
• кто-то вручную удалил под — возвращает его.

Вы сказали, что вам нужны три реплики приложения? Kubernetes будет добиваться этого не один раз, а постоянно и бесконечно. Это и есть reconciliation loop — ключевая идея Kubernetes. Эти шаги делают систему самовосстанавливающейся, отказоустойчивой и масштабируемой: приложения работают ровно так, как вы задумали.

Что такое объекты Kubernetes?

Объекты Kubernetes — строительные блоки, которыми вы описываете, что должно работать в кластере: вы их определяете, разворачиваете и управляете ими, а Kubernetes непрерывно приводит кластер к описанному ими состоянию. Объекты делятся на три категории: рабочие нагрузки, сеть и конфигурация.

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

• Объекты рабочих нагрузок (workload objects) — что и как запускать.
• Сетевые объекты (networking objects) — как приложения общаются между собой и с пользователями.
• Объекты конфигурации (configuration objects) — настройки и чувствительные данные отдельно от контейнеров.

Какие объекты рабочих нагрузок есть в Kubernetes?

Объекты рабочих нагрузок Kubernetes описывают, какие приложения запускать в кластере: как должен работать контейнер, сколько его экземпляров нужно и где они должны работать. Основные из них — Pod, ReplicaSet, Deployment, DaemonSet, StatefulSet, Job и CronJob.

Что такое под (Pod) в Kubernetes?

Pod (под) — наименьшая единица развёртывания в Kubernetes. Каждый контейнер в Kubernetes живёт внутри пода. Обычно под запускает один контейнер, но может запускать и несколько тесно связанных контейнеров, которые делят общую сеть и хранилище.

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

Поды почти никогда не создают и не управляют ими напрямую: обычно это делают объекты более высокого уровня, например Deployment и DaemonSet.

Что такое ReplicaSet в Kubernetes?

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

ReplicaSet тоже не создают напрямую: ими управляют Deployment. Так вы получаете все возможности ReplicaSet и вдобавок можете легко выкатывать обновления и откатывать их.

Что такое Deployment в Kubernetes?

Deployment — объект Kubernetes для запуска stateless-приложений: веб-серверов, API и фоновых обработчиков. Deployment управляет ReplicaSet, который в свою очередь управляет подами, и добавляет плавные обновления (rolling updates) и откаты (rollbacks).

Что такое DaemonSet в Kubernetes?

DaemonSet — объект Kubernetes, который следит, чтобы копия определённого пода работала на каждом узле кластера или на каждом узле, подходящем под заданный критерий. Речь не о множестве копий приложения, как у ReplicaSet, а ровно об одной копии на узел.

DaemonSet обычно используют для системных сервисов, которые должны работать на каждом узле: агентов сбора логов, агентов мониторинга и сетевых компонентов. Когда нужно, чтобы что-то работало везде, DaemonSet — правильный выбор.

Что такое StatefulSet в Kubernetes?

StatefulSet — объект Kubernetes для stateful-приложений, например баз данных и распределённых систем. Каждый под в StatefulSet получает постоянное имя (pod-01, pod-02, pod-03) и собственное постоянное хранилище, которое остаётся привязанным к нему даже после перезапуска на другом узле.

Большинству приложений всё равно, какой под обработает запрос: подойдёт любая реплика. Но некоторым не всё равно. Базам данных и распределённым системам нужны стабильные идентичности, предсказуемый порядок запуска и остановки и постоянное хранилище, которое остаётся за ними. Если pod-01 перезапустится, он вернётся как pod-01 с тем же подключённым хранилищем, а не как случайный новый под.

Deployment — для stateless-приложений: любой под может заменить любой другой. StatefulSet — для stateful-приложений: у каждого пода своя идентичность и своё хранилище.

Что такое Job и CronJob в Kubernetes?

Job — объект Kubernetes для задач, которые нужно выполнить один раз и завершить, например миграции базы данных или пакетной обработки. Kubernetes запускает под, ждёт его успешного завершения и помечает задачу выполненной. CronJob запускает Job по расписанию, например каждую ночь в полночь или каждый час.

Deployment и StatefulSet рассчитаны на то, чтобы работать бесконечно, а Job и CronJob закрывают разовые и периодические задачи.

Какие сетевые объекты есть в Kubernetes?

Сетевые объекты Kubernetes позволяют приложениям в кластере общаться между собой, а пользователям — получать к ним доступ. Они управляют тем, как трафик входит в кластер и выходит из него. Основные сетевые объекты — Service, Ingress и Gateway API.

Что такое Service в Kubernetes?

Service — объект Kubernetes, который даёт группе подов стабильную сетевую точку входа: постоянный IP-адрес и DNS-имя. Трафик приходит на Service, и Kubernetes направляет его на один из здоровых подов, сколько бы их ни было и где бы они ни работали.

Поды эфемерны: они создаются, падают и перезапускаются на других узлах с другими IP-адресами. Полагаться на IP пода нельзя — при каждом пересоздании он получает новый. Service решает эту проблему. Три основных типа Service:

• ClusterIP — сервис доступен только внутри кластера;
• NodePort — сервис открыт на порту каждого узла и доступен снаружи;
• LoadBalancer — через облачного провайдера создаётся внешний балансировщик нагрузки с публичным IP.

Что такое Ingress в Kubernetes?

Ingress — объект Kubernetes, который направляет внешний HTTP- и HTTPS-трафик на множество сервисов через единую точку входа. Он задаёт правила маршрутизации по URL или доменному имени, поэтому для сотни сервисов не нужна сотня отдельных внешних IP.

Service типа LoadBalancer даёт по одному внешнему IP на каждый сервис. Если сервисов сотни, отдельный балансировщик с внешним IP на каждый обойдётся дорого. С Ingress, например:

• запросы на /api идут в API-сервис;
• запросы на /dashboard идут во фронтенд-сервис.

И всё это через один внешний IP.

Что такое Gateway API в Kubernetes?

Gateway API — более новая и продвинутая замена Ingress в Kubernetes. Ingress создавался только для простой маршрутизации HTTP по пути URL, а Gateway API даёт более чистую и гибкую модель управления трафиком. Это текущее направление развития экосистемы Kubernetes.

Ingress хорошо подходил для простых конфигураций, но упирался в ограничения, когда нужны:

• разделение трафика между версиями приложения;
• маршрутизация по заголовкам;
• перенаправления (redirects);
• более тонкий контроль над потоками трафика в кластере.

Какие объекты конфигурации есть в Kubernetes?

Объекты конфигурации Kubernetes — ConfigMap и Secret — хранят настройки приложения и чувствительные данные отдельно от контейнеров. Благодаря этому конфигурацию можно менять без пересборки образа.

Что такое ConfigMap в Kubernetes?

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

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

Что такое Secret в Kubernetes?

Secret — объект Kubernetes для чувствительных данных: паролей, API-ключей и TLS-сертификатов. Secret работает как ConfigMap, но хранится отдельно от контейнеров приложения, что даёт больше контроля над доступом. По умолчанию значения Secret лежат в etcd в кодировке base64, а это кодирование, а не шифрование.

Kubernetes Secrets не так надёжны, как обещает их название. Любой, у кого есть доступ к etcd или нужные права в кластере, может раскодировать эти строки и прочитать секреты. Если нужна настоящая защита, используйте внешние хранилища секретов (например, Vault) и External Secrets Operator. При этом такие инструменты обычно всё равно доставляют значения в поды через встроенные Kubernetes Secrets.

Как Kubernetes управляет ресурсами?

Управление ресурсами в Kubernetes держится на четырёх механизмах: resource requests и limits задают, сколько CPU и памяти нужно контейнеру, правила размещения (affinity, taints и tolerations) определяют, на каких узлах запускать поды, а автоскейлеры меняют число подов и узлов под нагрузку.

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

Что такое resource requests и limits в Kubernetes?

Resource requests — минимальное количество CPU или памяти, которое нужно контейнеру для работы; по ним планировщик выбирает узел. Resource limits — максимум, который контейнеру разрешено использовать; лимит не даёт ему отнять ресурсы у соседей по узлу.

Каждому поду в кластере нужны CPU и память. Вопрос в том, сколько именно и как сообщить это Kubernetes. Для этого у каждого контейнера в файле Deployment есть две настройки:

• Resource requests. Планировщик Kubernetes проверяет requests пода и рассматривает только узлы, где хватает ресурсов для запуска контейнера.
• Resource limits. Не дают контейнеру потреблять лишние ресурсы и гарантируют, что другие приложения на том же узле получат своё.

Важно понимать: при размещении подов планировщик Kubernetes не смотрит на фактическое потребление CPU и памяти. Он учитывает только requests, указанные в спецификации пода. Поэтому для стабильной работы подов requests и limits обязательно нужно задавать правильно.

Что такое affinity, taints и tolerations в Kubernetes?

Affinity, taints и tolerations — механизмы Kubernetes, которые управляют тем, на каких узлах запускаются поды. Affinity притягивает под к нужным узлам или к другим подам, anti-affinity разводит поды по разным узлам, а taint на узле не пускает на него поды без подходящего toleration.

• Node affinity. Позволяет указать, что под должен работать на определённом узле по меткам (labels). Например, вы помечаете часть узлов как high-memory или GPU-enabled и запускаете нужные поды только на них.
• Pod affinity. Позволяет указать, что под нужно разместить на узле, где уже работают определённые другие поды. Полезно, когда два сервиса часто общаются и вы хотите держать их на одном узле, чтобы снизить задержку.
• Pod anti-affinity. Полная противоположность pod affinity: определённые поды не должны попадать на узел, где работают некоторые другие поды. Полезно для приложений с множеством реплик: если разнести реплики по разным узлам, отказ одного узла не положит всё приложение, остальные узлы продолжат его обслуживать.
• Taints и tolerations. Здесь узел выбирает поды, а не поды выбирают узел. Узел получает taint — метку, которая говорит: «поды не могут работать на этом узле, если у них нет toleration к нему». На такой узел попадают только поды с подходящим toleration, а поды без него размещаются на других узлах.

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

Какие автоскейлеры есть в Kubernetes?

Автомасштабирование в Kubernetes обеспечивают четыре механизма: Horizontal Pod Autoscaler меняет число подов, Vertical Pod Autoscaler — ресурсы контейнеров, Cluster Autoscaler — число узлов, а KEDA масштабирует поды по внешним событиям, например по длине очереди.

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

• Horizontal Pod Autoscaler (HPA) увеличивает или уменьшает число реплик пода по метрикам, например по загрузке CPU или памяти. Если поды постоянно работают на 80% CPU, HPA добавляет поды, потому что текущие не справятся с дополнительным трафиком. Когда трафик и загрузка CPU падают, поды убираются.
• Vertical Pod Autoscaler (VPA) решает ту же задачу по-другому: меняет requests CPU и памяти у контейнеров, а не число подов.
• Cluster Autoscaler работает на уровне кластера, а не подов. Он автоматически добавляет узлы, когда подам не хватает узлов со свободными ресурсами, а когда узлы недогружены и их поды можно перенести, убирает лишние узлы ради экономии.
• KEDA (Kubernetes Event Driven Autoscaler). HPA масштабирует по CPU или памяти, но многим реальным приложениям нужно масштабироваться по внешним событиям: сообщениям в очереди, строкам в базе данных, запросам на HTTP-эндпоинт. KEDA отслеживает внешние источники событий и автоматически меняет по ним число подов. Так Kubernetes масштабирует приложения, даже когда CPU и память загружены слабо, а нагрузка высокая.

Разные механизмы автомасштабирования вместе подстраивают под нагрузку и приложения, и инфраструктуру.

Как устроена безопасность в Kubernetes?

Безопасность Kubernetes построена слоями: аутентификация проверяет, кто вы, RBAC — что вам разрешено, namespaces изолируют команды и окружения, network policies ограничивают связи между подами, Secrets хранят чувствительные данные, а admission controllers проверяют каждый запрос на соответствие политикам перед записью в etcd.

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

Как работает аутентификация в Kubernetes?

Аутентификация — первый шаг защиты кластера: он отвечает на вопрос «кто вы?». Кластер проверяет личность пользователя или сервиса, который запрашивает доступ. Для этого используют сертификаты, токены или внешних провайдеров идентификации (identity providers). Когда личность подтверждена, начинается авторизация.

Что такое RBAC в Kubernetes?

RBAC (Role-Based Access Control, управление доступом на основе ролей) отвечает на вопрос «что вам можно?». После аутентификации Kubernetes проверяет, какие действия разрешены пользователю. RBAC позволяет создавать роли с разными правами — например, создавать поды, просматривать сервисы или обновлять Deployment — и привязывать их к пользователям или сервисам:

• одна команда имеет право деплоить приложения;
• другая — управлять сетью;
• только администраторы могут менять настройки кластера.

Так пользователи и сервисы выполняют только те действия, на которые у них есть права.

Что такое namespace в Kubernetes?

Namespace (пространство имён) — логический раздел внутри кластера Kubernetes. С namespaces один кластер можно использовать для разных команд или приложений, и не нужно поднимать отдельный кластер под каждое окружение. Например:

• namespace development;
• namespace staging;
• namespace production.

Ресурсы в одном namespace не видны из других, если это не настроено явно. Это позволяет делить кластер без конфликтов.

Что такое network policies в Kubernetes?

Network policies (сетевые политики) отвечают на вопрос «кто с кем может общаться?». По умолчанию во многих сетевых конфигурациях Kubernetes поды могут свободно обращаться друг к другу. Сетевые политики позволяют ограничить связи между подами и сервисами, например:

• с backend-подами могут общаться только frontend-поды;
• к подам базы данных можно обратиться, только если соединение начинает backend-сервис;
• некоторые сервисы недоступны из-за пределов кластера.

Это ещё один уровень защиты — на этот раз сетевой.

Как Kubernetes защищает доступ к Secrets?

Kubernetes Secrets хранят пароли, API-ключи и сертификаты и поэтому играют ключевую роль в безопасности. Доступ к ним Kubernetes разграничивает через RBAC, namespaces и сервисные аккаунты (service accounts): приложение получает доступ только к разрешённым ему секретам, а не к секретам других приложений и команд. В больших кластерах управление доступом к Secrets критично для общей безопасности.

Что такое admission controllers в Kubernetes?

Admission controllers — цепочка проверок, через которую проходит запрос после того, как API-сервер его аутентифицировал и авторизовал. Только после неё что-либо записывается в etcd. Admission controllers проверяют запрос, изменяют его или полностью отклоняют по политике. Например, они могут:

• запретить запуск контейнеров от root;
• требовать указания resource limits;
• применять политики безопасности;
• ограничивать, какие образы контейнеров можно использовать.

Так в кластере соблюдаются политики организации и стандарты безопасности.

Как работает постоянное хранилище в Kubernetes?

Постоянное хранилище в Kubernetes (persistent storage) отделяет данные от подов и контейнеров, чтобы они переживали перезапуск и замену пода. Им управляют три объекта: Persistent Volume — сам ресурс хранения, Persistent Volume Claim — запрос приложения на хранилище, и StorageClass — описание типа хранилища для автоматического создания томов.

Контейнеры в Kubernetes эфемерны: их могут создать и уничтожить в любой момент. Если хранить данные внутри контейнера, они пропадут при его замене. Для stateless-приложений вроде веб-серверов это нормально, но базам данных, очередям сообщений и приложениям, которым нужно хранить данные, так работать нельзя: базы, загрузки, логи и пользовательские данные не должны исчезать при перезапуске контейнера. Поэтому Kubernetes разделяет вычисления и хранение: данные не привязаны к конкретным контейнерам.

Что такое Persistent Volume в Kubernetes?

Persistent Volume (PV) — ресурс хранения в кластере, то есть само хранилище. За ним могут стоять разные устройства: блочные диски облачного провайдера, сетевое хранилище или локальные диски.

Что такое Persistent Volume Claim в Kubernetes?

Persistent Volume Claim (PVC) — запрос пользователя или приложения на ресурс хранения. Приложение запрашивает хранилище через PVC и не обращается к ресурсам напрямую, а Kubernetes сопоставляет PVC с подходящим Persistent Volume.

Что такое StorageClass в Kubernetes?

StorageClass описывает типы хранилища в кластере: SSD, обычный диск или сетевое хранилище. Он позволяет кластеру автоматически создать хранилище, когда появляется Persistent Volume Claim, поэтому заранее создавать Persistent Volume вручную не нужно. Автоматическое создание хранилища через StorageClass называется динамическим выделением (dynamic provisioning).

Какие сильные стороны у архитектуры Kubernetes?

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

Kubernetes — больше чем инструмент оркестрации контейнеров: он надёжно и автоматически управляет распределёнными системами. Его архитектура складывается из control plane, worker nodes, планирования, хранилища, сети и контроллеров.

Что значит декларативная модель Kubernetes?

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

• автоматически пересоздавать упавшие контейнеры;
• поддерживать число реплик;
• проводить rolling updates;
• откатывать неудачные деплои;
• автоматически масштабировать приложения.

Вместо ручного управления инфраструктурой система становится самоуправляемой.

Как работает самовосстановление в Kubernetes?

Kubernetes постоянно сверяет желаемое состояние с фактическим, поэтому может автоматически исправлять проблемы. Kubernetes умеет:

• перезапускать упавшие контейнеры;
• заменять нездоровые поды;
• переносить нагрузки при отказе узла;
• переназначать поды на здоровые узлы;
• поддерживать нужное число реплик.

Самовосстановление обеспечивают controller manager и reconciliation loop: они следят за кластером и устраняют любые расхождения между желаемым и фактическим состоянием.

Как Kubernetes масштабирует приложения?

Kubernetes рассчитан на запуск приложений на многих машинах, а не на одном сервере. Архитектура масштабируется несколькими способами:

• масштабирование подов через Horizontal Pod Autoscaler;
• масштабирование узлов через Cluster Autoscaler;
• rolling updates без простоя;
• балансировка нагрузки через Service;
• распределённое планирование по узлам.

Поэтому Kubernetes подходит и для небольших приложений, и для больших распределённых систем.

Где можно запустить Kubernetes?

Ещё одно ключевое преимущество Kubernetes — переносимость. Он даёт одинаковый API и одинаковую среду, где бы ни работал:

• в публичном облаке у облачного провайдера;
• в частных дата-центрах;
• в гибридном облаке;
• на локальной машине разработчика.

Приложения разворачиваются одинаково в разных средах. Это снижает привязку к вендору (vendor lock-in) и делает инфраструктуру гибче.

Какие недостатки у архитектуры Kubernetes?

Главные недостатки Kubernetes — критическая зависимость от etcd, высокие затраты на эксплуатацию самого кластера и сложная отладка распределённой системы. Те же архитектурные решения, которые делают Kubernetes мощным, добавляют расходы и новые способы отказа.

Почему etcd — единая точка отказа Kubernetes?

etcd хранит всё состояние кластера, и это делает его одним из самых критичных компонентов архитектуры. Если etcd недоступен или повреждён:

• состояние кластера теряется;
• Kubernetes не знает, какие поды должны работать;
• информация о Deployment и Service теряется;
• кластер приходится восстанавливать из бэкапа.

Кластер etcd из трёх или пяти узлов защищает от отказа отдельного узла, но не от повреждения данных, случайного удаления или неудачного обновления. Потеря данных etcd не просто роняет кластер — она стирает всю его память. Управляемые сервисы (managed Kubernetes) бэкапят etcd автоматически. Если вы поднимаете Kubernetes сами, бэкапы etcd обязательны.

Сколько стоит эксплуатация Kubernetes?

Эксплуатация Kubernetes — это не только запуск приложений, но и управление самим кластером. Обычно она включает:

• обновления кластера;
• обновления узлов;
• настройку сети;
• настройку хранилища;
• RBAC и политики безопасности;
• мониторинг и логирование;
• бэкапы и аварийное восстановление (disaster recovery);
• настройку автомасштабирования;
• управление сертификатами.

Чтобы кластер работал, Kubernetes часто требует поддержки platform engineering или DevOps-команды — и это нужно ещё до того, как задеплоено первое приложение. Для небольшой команды такие затраты могут быть существенными.

Почему Kubernetes сложно отлаживать?

Kubernetes — распределённая система, поэтому искать проблемы в нём сложнее, чем на одном сервере. Даже простая неполадка требует проверить:

• логи пода;
• события пода;
• статус узла;
• решения планировщика;
• сетевые проблемы;
• разрешение DNS;
• и многое другое.

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

Какую роль играет каждый компонент Kubernetes?

Каждый компонент Kubernetes служит одному механизму — reconciliation loop: API-сервер принимает все запросы, etcd хранит состояние, планировщик выбирает узел, контроллеры устраняют расхождения, kubelet запускает контейнеры, а объекты описывают, каким должен быть кластер.

Объекты рабочих нагрузок отличаются тем, какую нагрузку они запускают:

Когда нужен Kubernetes, а когда нет?

Kubernetes нужен, когда сервисов много, нужны автомасштабирование, высокая доступность и переносимость инфраструктуры, а у компании есть команда, которая будет поддерживать платформу. Для маленького приложения и маленькой команды Kubernetes избыточен: проще взять управляемый сервис контейнеров или serverless-платформу.

Какие ошибки чаще всего допускают при работе с Kubernetes?

• Хранят важные данные внутри пода, а не в Persistent Volume, и теряют их при пересоздании пода.
• Не задают resource requests и limits: планировщик смотрит только на requests, а не на фактическое потребление.
• Считают Kubernetes Secrets зашифрованными, хотя по умолчанию это base64 в etcd.
• Не бэкапят etcd в самостоятельно поднятом кластере, полагаясь на репликацию, которая не спасает от повреждения данных и неудачного обновления.
• Создают поды напрямую вместо Deployment или StatefulSet и теряют самовосстановление.
• Заводят отдельный LoadBalancer на каждый сервис вместо Ingress или Gateway API.
• Берут Kubernetes для маленького проекта без команды, которая сможет его эксплуатировать.

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

Частые вопросы о Kubernetes

Источники

• Документация Kubernetes: https://kubernetes.io/docs/
• Архитектура Kubernetes: https://kubernetes.io/docs/concepts/architecture/
• Концепции Kubernetes: https://kubernetes.io/docs/concepts/
• Справочник Kubernetes API: https://kubernetes.io/docs/reference/
• kube-apiserver: https://kubernetes.io/docs/reference/command-line-tools-reference/kube-apiserver/
• kube-scheduler: https://kubernetes.io/docs/concepts/scheduling-eviction/kube-scheduler/
• kube-controller-manager: https://kubernetes.io/docs/concepts/architecture/controller/
• kubelet: https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/
• kube-proxy: https://kubernetes.io/docs/reference/networking/kube-proxy/
• Документация etcd: https://etcd.io/docs/
• Документация containerd: https://containerd.io/docs/
• containerd на GitHub: https://github.com/containerd/containerd
• Container Runtime Interface (CRI): https://kubernetes.io/docs/concepts/containers/runtime-class/
• CRI-O: https://cri-o.io/
• Сетевая модель Kubernetes: https://kubernetes.io/docs/concepts/cluster-administration/networking/
• Container Network Interface (CNI): https://github.com/containernetworking/cni
• Persistent Volumes: https://kubernetes.io/docs/concepts/storage/persistent-volumes/
• Container Storage Interface (CSI): https://github.com/container-storage-interface/spec
• Безопасность Kubernetes: https://kubernetes.io/docs/concepts/security/
• Kubernetes RBAC: https://kubernetes.io/docs/reference/access-authn-authz/rbac/
• Large-scale cluster management at Google with Borg — статья Google о системе Borg.
• Архив design proposals Kubernetes: https://github.com/kubernetes/design-proposals-archive
• Проект Kubernetes в CNCF: https://www.cncf.io/projects/kubernetes/