Java Interview Questions

Главная / Все ответы / Docker Kubernetes

Вопрос 8 · Раздел 14

Что такое Kubernetes и зачем он нужен?

(«хочу 3 копии приложения»), а K8s автоматически его поддерживает.

Russian Docker Kubernetes Исходный Markdown
Версии по языкам: English Russian Ukrainian

🟢 Junior Level

Простое объяснение

Kubernetes (K8s) — это оркестратор контейнеров. Вы описываете желаемое состояние («хочу 3 копии приложения»), а K8s автоматически его поддерживает.

Если Pod падает – K8s создаёт новый. Если нагрузка растёт – K8s добавляет копии. Это и есть «самолечение» (self-healing). Если Docker — это упаковка, то Kubernetes — это конвейер и логистический центр.

K8s НЕ нужен для: одного приложения на одном сервере, простой статичной страницы, прототипа на выходные.

Аналогия

Представьте оркестр (от греческого «kybernetes» — кормчий, управляющий):

  • Docker-контейнер = один музыкант
  • Kubernetes = дирижёр, который знает, кто когда играет, заменяет заболевших музыкантов и добавляет новых при росте аудитории

Основные задачи Kubernetes

  1. Service Discovery — K8s даёт каждому контейнеру IP-адрес и DNS-имя, распределяет трафик.
  2. Масштабирование — автоматически добавляет копии приложения при росте нагрузки.
  3. Самолечение — перезапускает упавшие контейнеры, заменяет и переносит их при сбое.
  4. Rolling updates и откаты — обновляет приложение без простоя, может откатить при проблемах.
  5. Управление секретами — хранит пароли и токены без пересборки образов.

Архитектура простыми словами

Control Plane (Голова):

  • kube-apiserver — точка входа для всех команд
  • etcd – база данных кластера, хранит все настройки и состояния.
  • scheduler – решает, на какой Node посадить каждый Pod.
  • controller-manager — следит за состоянием кластера

Worker Nodes (Рабочие серверы):

  • kubelet – агент на каждом Node, докладывает Control Plane о состоянии контейнеров.
  • kube-proxy — отвечает за сеть и трафик
  • Container Runtime — среда запуска контейнеров (containerd)

Зачем K8s нужен бизнесу?

  • Масштабируемость – K8s мониторит CPU/RAM Pod’ов и автоматически создаёт новые копии при превышении порогов (Horizontal Pod Autoscaler).
  • Оптимизация ресурсов — плотная «упаковка» контейнеров для экономии денег
  • Cloud Agnostic — легко переезжать между провайдерами (GCP, Azure, AWS)

Что запомнить

  • Kubernetes — стандарт управления облачной инфраструктурой
  • Главные преимущества: Self-healing, Auto-scaling, Declarative management
  • В основе — архитектура с разделением на Control Plane и Worker Nodes
  • Self-hosted K8s требует глубоких знаний. Managed K8s (GKE, EKS, AKS) значительно упрощает эксплуатацию.

🟡 Middle Level

Архитектура Kubernetes

Control Plane (Control Plane)

Компонент Роль Что будет если упадёт
kube-apiserver REST API, точка входа Нельзя управлять кластером, работающие поды продолжают работать
etcd Хранилище всех данных Потеря состояния кластера. Критичный компонент!
kube-scheduler Выбор Node для Pod’ов Новые поды не запускаются, существующие работают
kube-controller-manager Поддержание желаемого состояния Pod’ы не восстанавливаются при падении

Worker Nodes

Компонент Роль Что будет если упадёт
kubelet Агент на Node, управляет Pod’ами Поды на этой Node перестают управляться
kube-proxy Сетевые правила (iptables/IPVS) Нарушается сетевая связь между сервисами
containerd Runtime контейнеров Все контейнеры на Node останавливаются

Типичные ошибки

Ошибка Последствие Как избежать
Нет requests/limits у Pod’ов Один Pod забирает все ресурсы, остальные Killed Всегда указывайте resources.requests и resources.limits
Использование latest тега Невозможно откатить, недетерминизм Фиксируйте теги образов
Один реплик Pod’а Нет HA, downtime при обновлении Минимум 2 реплики, PodDisruptionBudget
Без liveness/readiness probes K8s не знает, живо ли приложение Настройте оба probe
Хранение состояния в Pod’ах Данные теряются при перезапуске Используйте StatefulSet + PersistentVolume

Основные объекты Kubernetes

Объект Назначение
Pod Минимальная единица — один или несколько контейнеров
Deployment Управление stateless Pod’ами, rolling updates
Service Стабильный IP/DNS для группы Pod’ов (L4 балансировка)
Ingress HTTP-маршрутизация (L7), SSL termination
ConfigMap Конфигурация (ключ-значение)
Secret Секреты (закодированные в base64)
PersistentVolume Постоянное хранилище данных
Namespace Логическое разделение ресурсов

Когда K8s — избыточен?

  • Простые монолиты на 1-2 серверах
  • Небольшие команды без DevOps-инженеров
  • Лучше подходят: Heroku, AWS Elastic Beanstalk, Docker Swarm

Что запомнить

  • Понимание архитектуры критично для траблшутинга
  • etcd — самый критичный компонент, требует бэкапов
  • Всегда настраивайте resources, probes, replicas
  • K8s — избыточен для простых монолитов
  • Для небольших команд лучше Managed K8s (GKE, EKS, AKS)

🔴 Senior Level

Глубокая архитектура Control Plane

kube-apiserver

  • Stateless HTTP/HTTPS сервер, обрабатывает REST запросы
  • Аутентификация (X.509, Bearer tokens, OIDC), авторизация (RBAC, ABAC, Webhook), Admission Controllers (Mutating + Validating)
  • Масштабируется горизонтально за load balancer
  • Все компоненты Control Plane общаются только через API Server

etcd

  • Распределённое key-value хранилище на базе Raft consensus algorithm
  • Требуется нечётное количество нод (3 или 5) для quorum
  • Критичность: потеря etcd = потеря всего состояния кластера
  • Бэкапы: etcdctl snapshot save — обязательно в CI/CD и по расписанию
  • Performance: etcd чувствителен к latency disk. Используйте SSD. etcd хранит все изменения — компактирование (compaction) необходимо.

kube-scheduler

  • Multi-pass scheduling: Filter (отсеивает неподходящие Node) → Score (ранжирует оставшиеся)
  • Учитывает: resources requests, node selectors, taints/tolerations, affinity/anti-affinity, pod topology spread
  • Можно кастомизировать через Scheduler Framework plugins

kube-controller-manager

  • Набор контроллеров, каждый из которых следит за своим объектом:
    • ReplicaSet Controller — поддерживает нужное число Pod’ов
    • Node Controller — мониторит состояние Node
    • Endpoint Controller — обновляет Endpoints для Service
    • ServiceAccount Controller — создаёт default ServiceAccount

Control Plane HA (High Availability)

                    [Load Balancer]
                   /       |        \
          apiserver   apiserver   apiserver
               |          |          |
              etcd ------ etcd ------ etcd   (Raft consensus)
  • Multi-master: 3x API Server + 3/5 etcd + 2x scheduler (active-passive) + 2x controller-manager (active-passive)
  • etcd quorum: при 3 нодах выдерживает 1 отказ, при 5 — 2 отказа
  • etcd latency: < 10ms между нодами, иначе Raft consensus деградирует

Trade-offs

Аспект Self-hosted K8s Managed K8s (GKE/EKS/AKS)
Контроль Полный Ограниченный (no API server tuning)
Сложность Очень высокая Средняя
Стоимость Ниже (своя инфраструктура) Выше (managed fee)
Обновления Ручные Автоматические
etcd management Сам Провайдер
SLA Ваш 99.95%+

Edge Cases

  • etcd fragmentation: при частых обновлениях etcd фрагментируется. Нужна периодическая дефрагментация (etcdctl defrag).
  • API Server overload: при 5000+ Pod’ов и частых обновлениях API Server может стать bottleneck. Решение: горизонтальное масштабирование, tuning --max-requests-inflight.
  • NotReady Node timeout: Node перешла в NotReady. Control Plane ждёт 5 минут (pod-eviction-timeout), прежде чем пересоздавать Pod’ы. В критических системах таймаут нужно тюнинговать.
  • Kernel Panic на Node: Kubelet перестаёт слать heartbeats. K8s не всегда отличает падение узла от проблем с сетью. Pod’ы могут «зависнуть» в Unknown статусе.
  • Pod stuck in Terminating: Volume не может отмонтироваться, finalizer не завершается. Решение: kubectl patch pod <name> -p '{"metadata":{"finalizers":null}}'.

Производительность и масштабирование

Параметр Default Maximum (tested)
Pod’ов на Node 110 250+ (зависит от CNI)
Pod’ов в кластере - 150,000
Node в кластере - 5,000
Namespace - Десятки тысяч
etcd размер - < 8GB (рекомендуется)

Ограничения:

  • Количество Pod’ов на Node ограничено доступными IP (CNI), нагрузкой на kubelet, количеством доступных PID.
  • etcd хранит все объекты. При > 8GB размер базы деградирует performance.
  • API Server throughput: tuning --max-requests-inflight и --max-mutating-requests-inflight.

Безопасность

Defense in Depth:

  1. Network Policies — микросегментация, zero-trust networking
  2. RBAC — минимальные привилегии (least privilege)
  3. Pod Security Standards — restricted, baseline, privileged
  4. Admission Controllers — OPA/Gatekeeper для policy enforcement
  5. Image Policy — только подписанные образы из trusted registry
  6. Secrets encryption at rest — шифрование etcd данных
  7. Audit logging — все API запросы логируются

Production Story

Крупная fintech-компания развернула self-hosted K8s кластер (10 masters, 50 workers). Первые 6 месяцев — стабильная работа. Затем: etcd начал деградировать (fragmentation, latency > 50ms). Причина: частые обновления Deployment’ов (каждые 5 минут) + отсутствие компактирования. Решение: периодическая дефрагментация, batch updates, monitoring etcd latency. Второй инцидент: API Server overload из-за «watch storm» — 10,000 клиентов одновременно переподключились после network blip. Решение: tuning --max-requests-inflight, horizontal scaling API Server, connection multiplexing.

Monitoring

  • Control Plane: API Server latency/p99, etcd disk latency, etcd leader elections, scheduler scheduling duration, controller-manager queue depth
  • Nodes: CPU/Memory pressure, disk pressure, PID pressure, kubelet runtime operations, kube-proxy sync latency
  • Pods: restart count, OOMKilled, CrashLoopBackOff, container waiting time, resource usage vs requests
  • Stack: Prometheus + kube-prometheus-stack (AlertManager, Grafana), cAdvisor для контейнерных метрик
  • Golden Signals: latency, traffic, errors, saturation — на уровне кластера, namespace, deployment, pod

Резюме

  • Kubernetes — стандарт управления облачной инфраструктурой с разделением на Control Plane и Worker Nodes.
  • etcd — самый критичный компонент. Бэкапы обязательны.
  • Главные преимущества: Self-healing, Auto-scaling, Declarative management.
  • Самохостящийся K8s требует команды из 3-5 SRE инженеров. Managed K8s снижает операционную нагрузку.
  • Всегда настраивайте: resources requests/limits, liveness/readiness probes, PodDisruptionBudget, NetworkPolicies.
  • K8s — избыточен для монолитов. Для микросервисов на масштабе — незаменим.
  • Понимание внутренней архитектуры (API Server → etcd → Scheduler → Controller → Kubelet) критично для траблшутинга.

🎯 Шпаргалка для интервью

Обязательно знать:

  • Kubernetes — оркестратор контейнеров: self-healing, auto-scaling, declarative management
  • Control Plane: API Server (точка входа), etcd (хранилище), Scheduler, Controller Manager
  • Worker Nodes: kubelet (агент), kube-proxy (сеть), container runtime (containerd)
  • Pod — минимальная единица запуска; Service — стабильный адрес; Deployment — управление replicas
  • etcd — самый критичный компонент; потеря etcd = потеря состояния кластера
  • Self-hosted K8s требует SRE-команду; Managed (GKE/EKS/AKS) значительно проще
  • K8s избыточен для монолитов; незаменим для микросервисов на масштабе

Частые уточняющие вопросы:

  • «Что будет если упадёт etcd?» — Потеря всего состояния кластера; бэкапы обязательны
  • «Почему kube-apiserver stateless?» — Можно масштабировать горизонтально за load balancer
  • «K8s для одного приложения?» — Избыточен; лучше Heroku, ECS, или простой сервер
  • «Что такое reconciliation loop?» — K8s постоянно сверяет desired state с actual и исправляет расхождения

Красные флаги (НЕ говорить):

  • «K8s нужен каждому проекту» (избыточен для монолитов и маленьких команд)
  • «etcd можно не бэкапить» (потеря etcd = полная потеря кластера)
  • «Kubelet на Control Plane» (kubelet только на Worker Nodes)
  • «K8s сам по себе безопасен» (требует RBAC, NetworkPolicies, Pod Security)

Связанные темы:

  • [[Что такое Pod в Kubernetes]] — минимальная единица запуска
  • [[Что такое Service в Kubernetes]] — сетевая абстракция
  • [[Как происходит масштабирование в Kubernetes]] — HPA, VPA, Cluster Autoscaler