Kubernetes

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

Компоненты кластера

Control Plane управляет кластером:

• API Server — принимает запросы от kubectl и других компонентов, проверяет права и сохраняет изменения.
• etcd — хранит конфигурацию и состояние кластера.
• Scheduler — выбирает узел для нового пода с учётом ресурсов и правил размещения.
• Controller Manager — запускает контроллеры, которые приводят состояние кластера к желаемому.

На рабочих узлах запускаются приложения:

• Kubelet — следит за контейнерами в назначенных узлу подах и сообщает об их состоянии через API Server.
• Container runtime — запускает контейнеры, например containerd или CRI-O.
• Kube-proxy — настраивает сетевые правила для Service. В некоторых сетевых решениях его функции выполняет другой компонент.

Сеть между подами обеспечивает CNI-плагин, а имена сервисов внутри кластера разрешает DNS, обычно CoreDNS.

Pod, ReplicaSet и Deployment

Pod — минимальная единица запуска: один или несколько контейнеров на одном узле. У контейнеров пода общая сеть, они доступны друг другу через localhost и могут использовать общие тома. При замене пода его IP-адрес может измениться.

ReplicaSet поддерживает заданное число подов. Deployment управляет ReplicaSet, обновлениями приложения и откатами. Обычно для приложения создают Deployment, а ReplicaSet и поды появляются автоматически.

Связь объектов: Deployment → ReplicaSet → Pod.

Доступ к приложению

Service даёт стабильную точку доступа к подам, выбранным по меткам. Основные типы:

Тип	Для чего нужен
ClusterIP	Доступ внутри кластера; тип по умолчанию
NodePort	Доступ через выделенный порт на узлах
LoadBalancer	Доступ через внешний балансировщик при наличии соответствующей интеграции
ExternalName	DNS-псевдоним для другого имени, без проксирования трафика

Ingress описывает маршруты HTTP/HTTPS к сервисам по домену и пути. Для обработки этих правил нужен Ingress Controller.

Проверки состояния

Проверки выполняет kubelet. Каждая отвечает на свой вопрос:

Проверка	Что проверяет	Что происходит при сбое
startupProbe	Завершился ли запуск приложения?	Контейнер перезапускается после заданного числа неудач
livenessProbe	Работает ли приложение?	Контейнер перезапускается после заданного числа неудач
readinessProbe	Готово ли приложение принимать трафик?	Под перестаёт получать обычный трафик через Service, без перезапуска контейнера

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

Конфигурация, данные и ресурсы

• Namespace — группирует ресурсы внутри кластера. Сам по себе не обеспечивает полную изоляцию приложений.
• ConfigMap — хранит обычные настройки приложения.
• Secret — хранит пароли, токены и другие секреты. Base64 в манифесте — кодирование, а не шифрование.
• PersistentVolume (PV) — ресурс постоянного хранилища. PersistentVolumeClaim (PVC) — запрос приложения на такое хранилище.
• requests — потребность в CPU и памяти, которую планировщик учитывает при выборе узла.
• limits — ограничения потребления ресурсов контейнером.

Что происходит при создании Deployment

1. kubectl отправляет манифест в API Server.
2. API Server проверяет доступ и корректность объекта, затем сохраняет его в etcd.
3. Контроллер Deployment создаёт ReplicaSet, а контроллер ReplicaSet — поды.
4. Scheduler назначает подам подходящие узлы.
5. Kubelet на каждом выбранном узле через container runtime запускает контейнеры и сообщает их состояние.
6. Готовые поды получают трафик через Service, если он настроен и выбирает их по меткам.

Компоненты взаимодействуют с состоянием кластера через API Server, а не напрямую с etcd. Изменения применяются асинхронно: контроллеры следят за состоянием и постепенно приводят его к заданному.

Подробнее: компоненты Kubernetes и жизненный цикл пода.