Java Interview Questions

Головна / Усі відповіді / Docker Kubernetes

Питання 8 · Розділ 14

Що таке Kubernetes і навіщо він потрібен?

(«хочу 3 копії додатку»), а K8s автоматично його підтримує.

Ukrainian 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.

Моніторинг

  • 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