Kubernetes

Головна ідея: Kubernetes — це відкрита платформа для автоматизації розгортання, масштабування та керування контейнеризованими застосунками.

Чому це цікаво: Kubernetes став фактичним стандартом cloud-native інфраструктури: він дозволяє запускати застосунки не на одному сервері, а на цілому кластері машин, автоматично перезапускати зламані контейнери, масштабувати сервіси й керувати складними системами декларативно.

Важливо: Kubernetes не є заміною Docker, Linux або хмарного провайдера. Це оркестратор: він керує контейнерами, мережами, конфігурацією, storage, rollout-ами й станом застосунків у кластері.

1. Загальний опис

Kubernetes — це open source-система для оркестрації контейнерів.

Вона допомагає запускати застосунки, які складаються з контейнерів, на групі серверів або віртуальних машин.

Kubernetes часто скорочують як K8s.

Скорочення читається так:

K + 8 літер + s
Kubernetes → K8s

Kubernetes використовується для:

web applications;
microservices;
API;
SaaS-платформ;
cloud-native застосунків;
CI/CD;
machine learning workloads;
batch jobs;
edge computing;
platform engineering;
DevOps;
hybrid cloud;
multi-cloud;
internal developer platforms.

Офіційний сайт Kubernetes описує його як open source system for automating deployment, scaling, and management of containerized applications. Kubernetes групує контейнери в logical units для зручного керування й service discovery. :contentReference[oaicite:0]{index=0}

2. Коротка характеристика

Характеристика	Значення
Назва	Kubernetes
Скорочення	K8s
Тип	Платформа оркестрації контейнерів
Початковий розробник	Google
Поточна екосистема	Cloud Native Computing Foundation, спільнота, vendors
Мова реалізації	Go
Перший анонс	2014 рік
Перший стабільний реліз 1.0	2015 рік
CNCF статус	Graduated
Основна одиниця запуску	Pod
Основний CLI	kubectl
Конфігурація	YAML / JSON manifests
Актуальна стабільна гілка на травень 2026	Kubernetes 1.36
Останній реліз у release history на травень 2026	Kubernetes 1.36.0, випущений 22 квітня 2026 року

Офіційна сторінка релізів Kubernetes на травень 2026 показує Kubernetes 1.36.0 як latest release, випущений 22 квітня 2026 року, а також активні підтримувані гілки 1.35, 1.34 і 1.33. :contentReference[oaicite:1]{index=1}

3. Kubernetes простими словами

Уявімо, що є застосунок:

frontend
backend API
database
cache
worker
message queue

На одному сервері це ще можна запустити вручну.

Але якщо серверів багато, контейнерів сотні, версії змінюються щодня, частина машин падає, а трафік росте — ручне керування стає хаосом.

Kubernetes бере на себе питання:

де запускати контейнери;
скільки копій має працювати;
що робити, якщо контейнер упав;
як оновити застосунок без повного простою;
як дати сервісу стабільну адресу;
як передати конфігурацію;
як підключити storage;
як масштабувати навантаження;
як керувати секретами;
як описати бажаний стан системи.

Людське пояснення: якщо Docker запускає окремий контейнер, то Kubernetes керує цілим “містом контейнерів”: розселяє їх по серверах, стежить за здоров'ям, перенаправляє трафік і замінює зламані частини.

4. Історія

Kubernetes виріс із досвіду Google у запуску великих production-систем.

Ключові етапи:

Рік	Подія
2000-ті	Google розвиває внутрішні системи керування кластерами, зокрема Borg.
2014	Google анонсує Kubernetes як open source-проєкт.
2015	Виходить Kubernetes 1.0.
2015	Kubernetes передають до Cloud Native Computing Foundation.
2018	Kubernetes стає першим CNCF-проєктом, який отримав статус Graduated.
2020-ті	Kubernetes стає стандартом для cloud-native інфраструктури, managed Kubernetes і platform engineering.
2025	Виходить Kubernetes 1.35 Timbernetes.
2026	Виходить Kubernetes 1.36, актуальна гілка на травень 2026 року.

CNCF зазначає, що Kubernetes був прийнятий до CNCF 10 березня 2016 року на рівні Incubating, а 6 березня 2018 року перейшов до Graduated maturity level. :contentReference[oaicite:2]{index=2}

5. Цікавий факт: Kubernetes народився з досвіду Google Borg

До Kubernetes у Google вже була внутрішня система Borg, яка роками керувала величезними production workload-ами.

Kubernetes не є прямою копією Borg, але він натхненний ідеями:

кластер як єдиний ресурс;
декларативний стан;
автоматичне розміщення workload-ів;
self-healing;
масштабування;
service discovery;
scheduling.

Простими словами:

Google роками вчився запускати величезні системи.
Kubernetes став open source-версією багатьох цих ідей для всього світу.

6. Контейнери

Kubernetes керує контейнерами.

Контейнер — це ізольований процес із власним filesystem, залежностями й середовищем виконання.

Контейнер дозволяє упакувати застосунок разом із тим, що йому потрібно:

application code
runtime
libraries
environment
configuration

Kubernetes не створює саму ідею контейнерів, але керує їх запуском на багатьох машинах.

7. Docker і Kubernetes

Docker і Kubernetes часто плутають.

Інструмент	Роль
Docker	Створення, запуск і керування контейнерами на окремій машині.
Kubernetes	Оркестрація контейнерів у кластері з багатьох машин.
containerd	Container runtime, який фактично запускає контейнери.

Сучасний Kubernetes не потребує саме Docker як runtime. Він може працювати з containerd та іншими CRI-compatible runtime-ами.

8. Кластер

Kubernetes cluster — це набір машин, які разом запускають застосунки.

Кластер складається з:

Control Plane;
Worker Nodes;
мережі;
storage;
runtime-ів;
системних компонентів;
workload-ів користувача.

Загальна схема:

Kubernetes Cluster
   |
   +--> Control Plane
   |
   +--> Worker Node 1
   +--> Worker Node 2
   +--> Worker Node 3

9. Control Plane

Control Plane — мозок Kubernetes-кластера.

Він приймає рішення:

що має бути запущено;
де запускати Pods;
чи здорові Nodes;
чи треба створити нові Pods;
чи треба перезапустити щось;
чи треба оновити стан.

Основні компоненти:

Компонент	Призначення
kube-apiserver	Центральний API Kubernetes.
etcd	Key-value storage для стану кластера.
kube-scheduler	Вирішує, на який Node поставити Pod.
kube-controller-manager	Запускає controllers, які підтримують бажаний стан.
cloud-controller-manager	Інтеграція з cloud provider-ом, якщо використовується.

10. Worker Node

Worker Node — машина, на якій запускаються Pods.

Node може бути:

фізичним сервером;
віртуальною машиною;
cloud instance;
edge-пристроєм у спеціальних сценаріях.

На Node зазвичай працюють:

kubelet;
container runtime;
kube-proxy або CNI/eBPF components;
system agents;
Pods.

11. kubelet

kubelet — агент на кожному Node.

Він:

отримує інструкції від control plane;
запускає Pods через container runtime;
перевіряє стан контейнерів;
повідомляє про стан Node;
стежить за Pod health;
застосовує конфігурацію.

Простими словами:

kubelet — це місцевий менеджер на кожному сервері.
Control Plane каже, що треба зробити.
kubelet робить це на конкретному Node.

12. Pod

Pod — найменша одиниця запуску в Kubernetes.

Pod може містити один або кілька контейнерів.

Найчастіше:

1 Pod = 1 main container

Але може бути:

1 Pod = app container + sidecar container

Pod має:

спільну network namespace;
спільну IP-адресу;
спільні volumes;
lifecycle;
labels;
restart policy.

13. Цікавий факт: Kubernetes не запускає “просто контейнер”, він запускає Pod

У Docker люди часто думають контейнерами.

У Kubernetes головна одиниця — Pod.

Чому?

Бо іноді одному застосунку потрібен допоміжний контейнер:

sidecar для logs;
proxy;
service mesh;
sync agent;
monitoring helper;
init container.

Pod дозволяє групувати такі контейнери як одну логічну одиницю.

14. YAML manifests

Kubernetes зазвичай налаштовують через YAML-файли.

Приклад Pod:

apiVersion: v1
kind: Pod
metadata:
  name: hello-pod
spec:
  containers:
    - name: hello
      image: nginx:latest
      ports:
        - containerPort: 80

Застосування:

kubectl apply -f pod.yaml

15. Declarative configuration

Kubernetes працює декларативно.

Тобто користувач описує бажаний стан:

Я хочу 3 копії цього застосунку.
Я хочу Service для доступу.
Я хочу ConfigMap з такими налаштуваннями.
Я хочу rollout нової версії.

А Kubernetes намагається привести реальний стан до бажаного.

16. Цікавий факт: Kubernetes постійно “порівнює мрію з реальністю”

У Kubernetes є дуже важлива ідея:

desired state
vs
actual state

Якщо бажаний стан каже:

має бути 3 Pods

а реально працює тільки 2, Kubernetes створить ще один.

Якщо Pod упав, Kubernetes спробує його замінити.

Це називають reconciliation loop.

17. Deployment

Deployment — один із найпопулярніших Kubernetes-об'єктів.

Deployment керує запуском replicated application.

Він дозволяє:

запускати кілька копій;
робити rolling updates;
робити rollback;
контролювати версію;
підтримувати потрібну кількість Pods;
працювати через ReplicaSet.

Приклад:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: nginx:1.27
          ports:
            - containerPort: 80

18. ReplicaSet

ReplicaSet підтримує потрібну кількість копій Pod.

Зазвичай користувач напряму не створює ReplicaSet, а використовує Deployment.

Схема:

Deployment
   |
   +--> ReplicaSet
          |
          +--> Pod
          +--> Pod
          +--> Pod

19. StatefulSet

StatefulSet використовується для stateful-застосунків.

Наприклад:

databases;
message brokers;
clustered systems;
застосунки, де важливі стабільні імена;
застосунки, де важливі persistent volumes.

StatefulSet дає:

стабільні Pod names;
стабільну identity;
ordered rollout;
stable storage association.

20. DaemonSet

DaemonSet запускає Pod на кожному Node або на групі Nodes.

Використовується для:

log agents;
monitoring agents;
network plugins;
storage agents;
security agents;
node-level daemons.

Приклад:

На кожному Node має працювати log collector.
DaemonSet це забезпечує.

21. Job і CronJob

Job запускає задачу до завершення.

CronJob запускає задачі за розкладом.

Приклади:

batch processing;
database migration;
report generation;
cleanup;
backup task;
scheduled sync.

22. Service

Service дає стабільний спосіб доступу до Pods.

Pods можуть створюватися й зникати.

Їх IP змінюється.

Service дає стабільне ім'я й адресу.

Приклад:

apiVersion: v1
kind: Service
metadata:
  name: web-service
spec:
  selector:
    app: web
  ports:
    - port: 80
      targetPort: 80
  type: ClusterIP

Типи Service:

Тип	Опис
ClusterIP	Доступ тільки всередині кластера.
NodePort	Відкриває порт на кожному Node.
LoadBalancer	Створює зовнішній load balancer через cloud provider.
ExternalName	Дає DNS alias на зовнішній сервіс.

23. Ingress

Ingress керує HTTP/HTTPS-доступом до сервісів усередині кластера.

Типова схема:

Internet
   |
   v
Ingress Controller
   |
   +--> Service A
   +--> Service B
   +--> Service C

Ingress дозволяє:

routing за hostname;
routing за path;
TLS termination;
централізований HTTP-доступ;
інтеграцію з cert-manager.

24. Gateway API

Gateway API — сучасніший набір Kubernetes API для керування мережевим трафіком.

Він розвиває ідеї Ingress і дає більш гнучку модель для:

HTTP routing;
TCP/UDP routing;
ролей platform team і application team;
multi-tenant кластерів;
advanced traffic management.

Gateway API поступово стає важливим стандартом у cloud-native networking.

25. ConfigMap

ConfigMap зберігає конфігурацію.

Приклади:

environment variables;
config files;
application settings;
feature flags;
non-secret parameters.

Приклад:

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  APP_MODE: production
  LOG_LEVEL: info

26. Secret

Secret зберігає чутливі дані:

passwords;
tokens;
API keys;
certificates;
private keys.

Приклад:

apiVersion: v1
kind: Secret
metadata:
  name: db-secret
type: Opaque
stringData:
  username: app_user
  password: strong_password

Важливо: Kubernetes Secret — це не магічний сейф. Для production потрібно налаштовувати RBAC, encryption at rest, external secrets, secret rotation і доступ за принципом least privilege.

27. Volumes і PersistentVolume

Контейнери зазвичай тимчасові.

Якщо Pod видалити, дані всередині контейнера можуть зникнути.

Для збереження даних Kubernetes використовує volumes.

Основні поняття:

Об'єкт	Призначення
Volume	Том, доступний Pod-у.
PersistentVolume	Ресурс storage у кластері.
PersistentVolumeClaim	Запит застосунку на storage.
StorageClass	Опис типу storage і способу provision-інгу.

28. Namespace

Namespace дозволяє логічно розділяти ресурси в кластері.

Приклади namespaces:

default;
kube-system;
dev;
staging;
production;
monitoring;
team-a;
team-b.

Namespace допомагає:

організовувати ресурси;
розділяти команди;
задавати quotas;
налаштовувати RBAC;
уникати хаосу в великих кластерах.

29. Labels і selectors

Labels — це key-value мітки.

Приклад:

metadata:
  labels:
    app: web
    environment: production
    tier: frontend

Selectors дозволяють вибирати об'єкти за labels.

Наприклад Service знаходить Pods через selector:

selector:
  app: web

30. Цікавий факт: labels — це “клей” Kubernetes

Багато зв'язків у Kubernetes працюють через labels.

Service не “знає” конкретні Pod names.

Він каже:

Дай мені всі Pods з label app=web.

Це робить систему гнучкою.

Pods можуть змінюватися, але labels залишають логічний зв'язок.

31. kubectl

kubectl — головна командна утиліта Kubernetes.

Приклади:

kubectl get pods

kubectl get nodes

kubectl apply -f deployment.yaml

kubectl describe pod pod-name

kubectl logs pod-name

kubectl exec -it pod-name -- sh

kubectl rollout status deployment/web

kubectl rollout undo deployment/web

32. Helm

Helm — пакетний менеджер для Kubernetes.

Він дозволяє встановлювати застосунки як charts.

Приклад:

helm install my-nginx bitnami/nginx

Helm корисний для:

templating YAML;
versioned releases;
повторного встановлення;
складних застосунків;
values.yaml;
DevOps workflows.

33. Operators

Operator — це Kubernetes extension, який автоматизує керування складним застосунком.

Operator може знати, як:

створити database cluster;
зробити backup;
виконати restore;
оновити версію;
масштабувати;
перевірити health;
виконати failover.

Схема:

Custom Resource
   |
   v
Operator Controller
   |
   v
Real application resources

34. Custom Resource Definition

CRD дозволяє додавати нові типи ресурсів у Kubernetes.

Наприклад:

kind: PostgreSQLCluster
kind: Certificate
kind: KafkaTopic
kind: RedisCluster

CRD перетворює Kubernetes із простого orchestrator-а на платформу для власних API.

35. Цікавий факт: Kubernetes став “операційною системою датацентру”

Kubernetes часто називають:

the operating system for the cloud

Це не буквальна ОС як Linux.

Але ідея схожа:

Linux керує процесами на одній машині;
Kubernetes керує контейнерами на кластері машин.

Тобто Kubernetes став шаром, який перетворює багато серверів на одну керовану платформу.

36. Autoscaling

Kubernetes підтримує різні види autoscaling.

Тип	Що масштабує
Horizontal Pod Autoscaler	Кількість Pod replicas.
Vertical Pod Autoscaler	CPU/memory requests і limits для Pods.
Cluster Autoscaler	Кількість Nodes у кластері.
KEDA	Event-driven autoscaling для workloads.

Приклад:

Більше трафіку → більше Pods.
Менше трафіку → менше Pods.

37. Rolling update

Kubernetes дозволяє оновлювати застосунок поступово.

Схема:

old Pod 1 → new Pod 1
old Pod 2 → new Pod 2
old Pod 3 → new Pod 3

Це зменшує downtime.

Deployment може контролювати:

maxUnavailable;
maxSurge;
rollout status;
rollback.

38. Self-healing

Kubernetes має self-healing-механізми.

Він може:

перезапустити контейнер;
створити новий Pod;
перенести workload на інший Node;
прибрати unhealthy Pod із Service;
підтримувати потрібну кількість replicas;
реагувати на failed health checks.

39. Probes

Kubernetes має probes для перевірки стану застосунку.

Probe	Для чого
livenessProbe	Чи живий контейнер, чи його треба перезапустити.
readinessProbe	Чи готовий Pod приймати трафік.
startupProbe	Чи застосунок ще стартує і йому треба дати час.

40. Resource requests і limits

У Kubernetes важливо задавати ресурси.

Приклад:

resources:
  requests:
    cpu: "100m"
    memory: "128Mi"
  limits:
    cpu: "500m"
    memory: "512Mi"

Requests допомагають scheduler-у розміщувати Pods.

Limits обмежують максимальне використання ресурсів.

41. Цікавий факт: Kubernetes не знає, скільки ресурсів треба вашому застосунку, якщо ви йому не скажете

Новачки часто запускають Pods без requests і limits.

Потім кластер поводиться дивно:

один Pod з'їдає CPU;
інший вилітає через memory;
scheduler погано розміщує workload-и;
autoscaling працює нестабільно;
production стає непередбачуваним.

Kubernetes сильний, але він не телепат.

Йому треба описувати очікування.

42. RBAC

RBAC — Role-Based Access Control.

Він керує тим, хто що може робити в кластері.

Основні об'єкти:

Role;
ClusterRole;
RoleBinding;
ClusterRoleBinding;
ServiceAccount.

Приклад:

developer може дивитися Pods у namespace dev,
але не може видаляти secrets у production.

43. NetworkPolicy

NetworkPolicy дозволяє обмежувати мережевий трафік між Pods.

Без NetworkPolicy багато кластерів дозволяють Pods спілкуватися занадто вільно.

NetworkPolicy допомагає:

ізолювати namespaces;
обмежити доступ до databases;
дозволити тільки потрібний трафік;
зменшити blast radius;
будувати zero trust-підхід.

44. CNI

CNI — Container Network Interface.

CNI-плагіни забезпечують мережу для Pods.

Приклади CNI-рішень:

Calico;
Cilium;
Flannel;
Weave Net;
Antrea;
cloud provider CNI.

CNI відповідає за:

Pod networking;
IP allocation;
routing;
network policy;
іноді eBPF-функції.

45. CSI

CSI — Container Storage Interface.

CSI дозволяє Kubernetes працювати з різними storage systems.

Приклади:

cloud block storage;
network storage;
distributed storage;
Ceph;
Longhorn;
EBS;
Persistent Disks;
Azure Disks.

46. Service Mesh

Service mesh — шар для керування сервісним трафіком.

Приклади:

Istio;
Linkerd;
Consul service mesh;
Kuma.

Service mesh може давати:

mTLS;
traffic splitting;
retries;
observability;
circuit breaking;
policy;
zero trust networking.

Але service mesh також додає складність.

47. Observability

У Kubernetes важливо мати observability:

logs;
metrics;
traces;
events;
dashboards;
alerts;
distributed tracing.

Типові інструменти:

Prometheus;
Grafana;
Loki;
Tempo;
Jaeger;
OpenTelemetry;
Alertmanager;
Kubernetes events;
kube-state-metrics.

48. Monitoring

Що варто моніторити:

Node CPU;
Node memory;
Pod restarts;
Pod pending;
Pod OOMKilled;
API server latency;
etcd health;
disk pressure;
network errors;
failed deployments;
HPA behavior;
ingress errors.

49. Logging

У Kubernetes logs зазвичай збирають централізовано.

Схема:

Pod logs
   |
   v
Node log collector
   |
   v
Log storage
   |
   v
Search / dashboards / alerts

Інструменти:

Fluent Bit;
Fluentd;
Vector;
Loki;
Elasticsearch / OpenSearch;
Cloud logging services.

50. GitOps

GitOps — підхід, де бажаний стан кластера зберігається в Git.

Типова схема:

Git repository
   |
   v
GitOps controller
   |
   v
Kubernetes cluster

Інструменти:

Argo CD;
Flux;
Helm;
Kustomize.

Переваги:

version control;
audit trail;
rollback;
pull request workflow;
reproducible infrastructure;
менше ручних змін через kubectl.

51. Kustomize

Kustomize — інструмент для налаштування Kubernetes manifests без шаблонізації як у Helm.

Приклад ідеї:

base/
  deployment.yaml
overlays/
  dev/
  prod/

Dev і prod можуть мати різні replicas, images, labels, resources.

52. Managed Kubernetes

Багато хмар пропонують managed Kubernetes.

Приклади:

Google Kubernetes Engine;
Amazon Elastic Kubernetes Service;
Azure Kubernetes Service;
DigitalOcean Kubernetes;
Oracle Container Engine for Kubernetes;
IBM Cloud Kubernetes Service;
OVH Managed Kubernetes;
Scaleway Kubernetes Kapsule.

Managed Kubernetes зменшує складність control plane, але не скасовує потребу розуміти workloads, networking, security, storage і observability.

53. Kubernetes дистрибутиви

Є багато Kubernetes-дистрибутивів і платформ:

vanilla Kubernetes;
OpenShift;
Rancher / RKE2;
k3s;
MicroK8s;
Talos Linux + Kubernetes;
Tanzu Kubernetes;
Charmed Kubernetes;
kubeadm clusters;
managed cloud Kubernetes.

54. k3s

k3s — легкий Kubernetes-дистрибутив.

Підходить для:

edge;
home lab;
IoT;
маленьких кластерів;
testing;
developer labs;
lightweight environments.

55. MicroK8s

MicroK8s — Kubernetes-дистрибуція від Canonical.

Підходить для:

local development;
edge;
навчання;
small clusters;
Ubuntu-based workflows;
CI/CD labs.

56. OpenShift

OpenShift — enterprise Kubernetes-платформа від Red Hat.

Вона додає:

opinionated platform;
developer tools;
security defaults;
integrated registry;
routes;
operators;
enterprise support;
OpenShift-specific workflows.

57. Цікавий факт: Kubernetes сам по собі — це не “готова PaaS”

Новачки іноді думають:

Поставлю Kubernetes — і отримаю Heroku.

Насправді Kubernetes — це нижчий шар.

Щоб отримати зручну платформу, часто додають:

CI/CD;
GitOps;
registry;
ingress;
cert-manager;
monitoring;
logging;
secrets management;
policy;
developer portal;
templates;
platform documentation.

Kubernetes — це фундамент, але будинок треба ще збудувати.

58. Безпека Kubernetes

Безпека Kubernetes включає:

RBAC;
NetworkPolicy;
Pod Security Standards;
image scanning;
signed images;
secrets management;
encryption at rest;
audit logs;
admission controllers;
least privilege;
namespace isolation;
secure supply chain;
node hardening;
runtime security.

59. Pod Security Standards

Pod Security Standards визначають рівні безпеки Pod-ів:

privileged;
baseline;
restricted.

Для production бажано рухатися в бік restricted, якщо застосунок це дозволяє.

60. Admission Controllers

Admission controllers перевіряють або змінюють запити до Kubernetes API перед створенням об'єктів.

Приклади:

заборонити privileged containers;
вимагати resource limits;
вимагати labels;
перевіряти image registry;
застосовувати security policies;
автоматично додавати sidecars.

Інструменти:

OPA Gatekeeper;
Kyverno;
built-in admission controllers.

61. Supply chain security

Для Kubernetes важлива безпека supply chain:

звідки image;
хто його зібрав;
чи є vulnerabilities;
чи image підписаний;
чи є SBOM;
чи не використовується latest у production;
чи є provenance;
чи не зламаний CI/CD.

Популярні інструменти:

cosign;
Sigstore;
Trivy;
Grype;
Syft;
SLSA;
Notation.

62. Цікавий факт: у Kubernetes найслабше місце часто не Kubernetes, а процес навколо нього

Багато проблем виникає не через сам Kubernetes, а через:

неправильні Docker images;
secrets у Git;
відсутність limits;
занадто широкі RBAC-права;
відкритий dashboard;
відсутність NetworkPolicy;
ручні зміни в production;
відсутність backup etcd;
поганий monitoring;
невідомі third-party charts.

Kubernetes дає інструменти, але дисципліна все одно потрібна.

63. etcd

etcd — key-value storage, де Kubernetes зберігає стан кластера.

У etcd зберігається:

objects;
configuration;
cluster state;
metadata;
secrets у зашифрованому або незашифрованому вигляді залежно від налаштування.

Backup etcd — критично важливий для self-managed кластерів.

64. Backup Kubernetes

Backup Kubernetes — це не тільки backup Pods.

Потрібно думати про:

etcd;
manifests;
CRDs;
persistent volumes;
secrets;
Helm releases;
GitOps repositories;
external databases;
cloud resources.

Інструменти:

Velero;
etcd snapshots;
storage snapshots;
GitOps backup;
cloud backup systems.

65. Переваги Kubernetes

Перевага	Опис
Оркестрація контейнерів	Керує запуском контейнерів у кластері.
Self-healing	Перезапускає або замінює failed Pods.
Scaling	Підтримує горизонтальне й інші види масштабування.
Rolling updates	Дозволяє оновлювати застосунки поступово.
Service discovery	Дає стабільний доступ до змінних Pods.
Declarative model	Описує бажаний стан через manifests.
Велика екосистема	Helm, Operators, GitOps, monitoring, service mesh, policy tools.
Cloud-neutral	Може працювати в різних clouds, on-prem і hybrid.

66. Недоліки Kubernetes

Недолік	Опис
Складність	Має багато понять, компонентів і edge cases.
Overkill для малих проєктів	Для одного сайту часто достатньо Docker Compose або VPS.
Потребує досвіду	Networking, storage, security і observability непрості.
Вартість	Кластери потребують ресурсів і часу команди.
YAML-складність	Manifests можуть розростатися.
Небезпечні defaults у неправильних руках	Без RBAC, NetworkPolicy і hardening можна створити ризики.
Debugging складніший	Проблеми можуть бути на рівні app, Pod, Node, CNI, CSI, DNS, Ingress або cloud.

67. Kubernetes vs Docker Compose

Критерій	Kubernetes	Docker Compose
Масштаб	Кластери, production, cloud-native.	Локальна розробка, маленькі deployments.
Складність	Вища.	Нижча.
Self-healing	Розвинений.	Обмежений.
Scaling	Потужний.	Обмежений.
Networking	Складніший, але гнучкий.	Простий.
Найкращий сценарій	Production container platform.	Local dev або невеликі сервіси.

68. Kubernetes vs Docker Swarm

Критерій	Kubernetes	Docker Swarm
Популярність	Фактичний стандарт індустрії.	Значно менш популярний сьогодні.
Складність	Вища.	Нижча.
Екосистема	Дуже велика.	Менша.
Enterprise adoption	Дуже висока.	Набагато нижча.
Навчання	Складніше.	Простіше.

69. Kubernetes vs Nomad

Критерій	Kubernetes	Nomad
Фокус	Container orchestration і cloud-native platform.	General workload orchestrator.
Складність	Вища.	Часто простіший core.
Екосистема	Величезна.	Менша, але сильна в HashiCorp-екосистемі.
Workloads	Контейнери, batch, extensions.	Containers, VMs, binaries, batch.
Найкращий сценарій	Cloud-native Kubernetes ecosystem.	Простішій scheduler для різних workload-ів.

70. Kubernetes vs OpenShift

Критерій	Kubernetes	OpenShift
Тип	Open source orchestrator.	Enterprise Kubernetes platform.
Vendor	CNCF/community.	Red Hat.
Безпека	Залежить від налаштувань.	Має більш opinionated security defaults.
Developer experience	Потрібно будувати самому.	Багато готових platform features.
Вартість	Сам Kubernetes безкоштовний, але операційні витрати є.	Комерційна enterprise-платформа.

71. Kubernetes vs Serverless

Критерій	Kubernetes	Serverless
Контроль	Високий.	Нижчий, більше керує provider.
Операційна складність	Вища.	Нижча для простих сценаріїв.
Portability	Вища між середовищами.	Залежить від provider-а.
Scaling	Гнучке, але треба налаштовувати.	Часто автоматичне.
Найкращий сценарій	Складні платформи й довгоживучі services.	Event-driven functions, невеликі backend tasks.

72. Коли варто використовувати Kubernetes

Kubernetes доцільно використовувати, якщо:

є багато сервісів;
потрібне масштабування;
потрібні rolling updates;
потрібна self-healing інфраструктура;
команда працює з containers;
потрібна cloud portability;
потрібна GitOps-модель;
є platform engineering-команда;
потрібні operators;
потрібна multi-tenant платформа;
застосунок достатньо складний, щоб виправдати кластер.

73. Коли Kubernetes може бути не найкращим вибором

Kubernetes може бути не найкращим варіантом, якщо:

у вас один маленький сайт;
команда не має DevOps-досвіду;
немає часу підтримувати кластер;
workload простий;
Docker Compose достатньо;
managed PaaS простіший;
бюджет малий;
потрібен максимально простий deployment;
складність Kubernetes перевищує користь.

74. Типові помилки новачків

Помилка	Чому виникає	Як правильно думати
“Kubernetes вирішить усі проблеми”	Його часто рекламують як стандарт.	Він вирішує orchestration, але додає операційну складність.
“Поставлю все в default namespace”	Так простіше на старті.	Використовувати namespaces для організації.
“Не потрібні resource limits”	На dev усе працює.	У production limits і requests дуже важливі.
“Secrets можна зберігати в Git”	YAML здається зручним.	Використовувати external secrets і encryption.
“latest image нормально”	Легко оновлювати.	У production краще pinned versions.
“kubectl apply вручну — достатньо”	На старті це швидко.	Для production краще GitOps/CI/CD.
“Ingress сам усе зробить”	Плутають API і controller.	Потрібен Ingress Controller.

75. Базовий хороший workflow

1. Зібрати container image.
2. Запушити image у registry.
3. Описати Deployment.
4. Описати Service.
5. Додати Ingress або Gateway, якщо потрібен зовнішній доступ.
6. Додати ConfigMap і Secret.
7. Задати resource requests і limits.
8. Додати probes.
9. Налаштувати monitoring і logs.
10. Зберігати manifests у Git.
11. Використовувати CI/CD або GitOps.
12. Тестувати rollout і rollback.

76. Мінімальний приклад Deployment + Service

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 2
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: nginx:1.27
          ports:
            - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: web
spec:
  selector:
    app: web
  ports:
    - port: 80
      targetPort: 80

Застосування:

kubectl apply -f web.yaml

Перевірка:

kubectl get deployments
kubectl get pods
kubectl get services

77. Цікаві факти

Факт	Пояснення
Kubernetes скорочують як K8s	Між K і s у слові Kubernetes є 8 літер.
Kubernetes натхненний Google Borg	Google мав багаторічний досвід cluster management.
Kubernetes написаний мовою Go	Це одна з причин популярності Go в cloud-native світі.
Kubernetes був першим CNCF Graduated-проєктом	Він отримав цей статус 6 березня 2018 року.
Pod — головна одиниця запуску	Kubernetes не керує “просто контейнером”, а працює з Pod.
Kubernetes декларативний	Ви описуєте бажаний стан, а controllers намагаються його підтримувати.
etcd — серце стану кластера	Без backup etcd self-managed кластер може бути важко відновити.
Kubernetes має величезну екосистему	Helm, Operators, GitOps, service mesh, monitoring і policy tools стали окремими світами.

78. Людське пояснення: чим є Kubernetes

Kubernetes — це не просто модний інструмент.

Це спосіб мислити про інфраструктуру як про живу систему.

Не так:

У мене є сервер, я зайду на нього по SSH і щось виправлю.

А так:

У мене є бажаний стан.
Кластер сам має прийти до цього стану.
Якщо щось падає — замінити.
Якщо треба більше копій — масштабувати.
Якщо виходить нова версія — оновити поступово.

Kubernetes дуже потужний, але він не простий.

Його сила розкривається тоді, коли є команда, процеси, observability, security, GitOps або CI/CD і розуміння, навіщо кластер взагалі потрібен.

79. Безпека

Рекомендовані практики:

використовувати підтримувані версії Kubernetes;
регулярно оновлювати cluster components;
налаштовувати RBAC за принципом least privilege;
не використовувати default ServiceAccount без потреби;
обмежувати privileged containers;
використовувати NetworkPolicy;
вмикати encryption at rest для Secrets;
не зберігати Secrets у Git;
сканувати container images;
використовувати pinned image tags або digests;
налаштувати audit logs;
використовувати admission policies;
робити backup etcd і persistent data;
налаштувати monitoring і alerts;
обмежувати доступ до Kubernetes API.

80. Kubernetes у сучасній інфраструктурі

У 2026 році Kubernetes залишається одним із головних стандартів cloud-native інфраструктури.

Його використовують у:

public cloud;
private cloud;
hybrid cloud;
multi-cloud;
enterprise;
startups;
DevOps;
platform engineering;
AI/ML platforms;
edge;
SaaS;
fintech;
e-commerce;
internal developer platforms.

Kubernetes 1.36 є latest release у офіційній release history на травень 2026, а гілка 1.35 ще actively supported з patch-релізом 1.35.4 від 14 квітня 2026 року. :contentReference[oaicite:3]{index=3}

81. Висновок

Kubernetes — це відкрита платформа оркестрації контейнерів, яка стала фундаментом cloud-native інфраструктури.

Його головні переваги:

автоматизація deployment;
масштабування;
self-healing;
service discovery;
rolling updates;
declarative configuration;
велика екосистема;
cloud portability;
GitOps;
Operators;
managed Kubernetes у major clouds.

Головні обмеження:

висока складність;
потреба в досвідченій команді;
складні networking і storage;
security треба налаштовувати уважно;
observability обов'язкова;
для маленьких проєктів може бути overkill;
YAML і CRDs можуть розростатися;
кластер сам по собі не робить платформу зручною.

Kubernetes найкраще підходить командам, які мають достатньо складні containerized workloads, хочуть автоматизувати інфраструктуру, масштабувати сервіси, будувати cloud-native платформу й готові інвестувати в DevOps, security та observability.

82. Джерела

Kubernetes official website
Kubernetes documentation
Kubernetes releases
Kubernetes 1.36 release information
Kubernetes 1.35 release information
Kubernetes blog: Kubernetes v1.35 Timbernetes
CNCF Kubernetes project page
CNCF: Kubernetes first graduated project
Kubernetes concepts documentation
Kubernetes API documentation
Helm documentation
Gateway API documentation
CNCF cloud-native ecosystem documentation

83. Див. також

Kubernetes K8s Контейнери Docker containerd Pod Deployment ReplicaSet StatefulSet DaemonSet Service Ingress Gateway API ConfigMap Secret Helm Operators CRD kubectl etcd CNCF Cloud-native DevOps GitOps Argo CD Flux Prometheus Grafana Istio OpenShift Docker Compose Nomad Linux Операційні системи