Співбесіда з Kubernetes: Pods, Services та Deployments -- повний розбір

Kubernetes залишається найпоширенішою платформою для оркестрації контейнерів, а питання про Pods, Services та Deployments складають основу технічних співбесід на позиції DevOps та platform engineering. Розуміння взаємодії цих трьох об'єктів -- від планування контейнерів до мережевої маршрутизації та поступового оновлення -- відрізняє кандидатів, які завчили визначення, від тих, хто здатен проєктувати продакшн-системи.

Цей матеріал детально розглядає кожен примітив із production-ready YAML-конфігураціями, пояснює внутрішні механізми, які цікавлять інтерв'юерів, та охоплює типові запитання, що виникають на DevOps-співбесідах у 2026 році.

Kubernetes Pods: найменша одиниця розгортання

Pod -- це атомарна одиниця планування в Kubernetes. Він обгортає один або кілька контейнерів, що розділяють один мережевий простір імен (network namespace), простір IPC та томи зберігання. Кожен контейнер всередині Podа отримує ту саму IP-адресу та може комунікувати з сусідніми контейнерами через localhost.

Найпоширенішим патерном є Pod з одним контейнером. Podи з кількома контейнерами існують для сценаріїв sidecar -- збирачі логів, service mesh проксі або init-контейнери, які підготовлюють файлову систему перед запуском основного процесу.

# api-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: api-server
  labels:
    app: api
    version: v2
spec:
  containers:
    - name: api
      image: registry.example.com/api:3.1.0
      ports:
        - containerPort: 8080
      resources:
        requests:
          cpu: "250m"        # 0.25 CPU core reserved
          memory: "256Mi"    # 256 MB reserved
        limits:
          cpu: "500m"        # hard cap at 0.5 core
          memory: "512Mi"    # OOMKilled beyond this
      readinessProbe:
        httpGet:
          path: /healthz
          port: 8080
        initialDelaySeconds: 5
        periodSeconds: 10
      livenessProbe:
        httpGet:
          path: /healthz
          port: 8080
        initialDelaySeconds: 15
        periodSeconds: 20

Блок resources є критично важливим на співбесідах. Поле requests визначає планування -- планувальник розміщує Pod на вузлі з достатньою вільною ємністю. Поле limits встановлює обмеження під час виконання -- перевищення ліміту пам'яті призводить до OOMKill, а перевищення ліміту CPU викликає throttling (обмеження тактів процесора).

Життєвий цикл Podа та політики перезапуску

Kubernetes відстежує кожен Pod через п'ять фаз: Pending, Running, Succeeded, Failed та Unknown. Інтерв'юери часто запитують, що спричиняє кожен перехід між фазами.

| Фаза | Значення | Типова причина | |------|----------|----------------| | Pending | Заплановано, але не запущено | Завантаження образу, нестача ресурсів | | Running | Щонайменше один контейнер активний | Штатна робота | | Succeeded | Усі контейнери завершилися з кодом 0 | Пакетні завдання, init-контейнери | | Failed | Щонайменше один контейнер завершився з ненульовим кодом | Збій застосунку, OOMKill | | Unknown | Втрачено зв'язок із вузлом | Мережева ізоляція, збій вузла |

Поле restartPolicy контролює поведінку після завершення контейнера. Always (значення за замовчуванням для Deployments) перезапускає незалежно від коду виходу. OnFailure перезапускає лише при ненульовому коді -- корисно для Jobs. Never залишає контейнер зупиненим -- використовується для одноразових діагностичних Podів.

# batch-job-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: data-migration
spec:
  restartPolicy: OnFailure   # restart only on crash
  containers:
    - name: migrate
      image: registry.example.com/migrate:1.0.0
      command: ["python", "migrate.py"]
      env:
        - name: DATABASE_URL
          valueFrom:
            secretKeyRef:
              name: db-credentials
              key: connection-string

Патерн valueFrom.secretKeyRef зберігає конфіденційні дані поза маніфестом. Kubernetes Secrets за замовчуванням кодуються в base64 -- але не шифруються. Для продакшн-середовищ рекомендується ввімкнути шифрування в стані спокою через EncryptionConfiguration API або використовувати зовнішній менеджер секретів, наприклад HashiCorp Vault.

Kubernetes Deployments: декларативне розгортання та масштабування

Deployment створює та керує ReplicaSets, які, у свою чергу, керують Podами. Контролер Deployment спостерігає за бажаним станом і узгоджує його з реальністю -- додає Podи при масштабуванні, замінює їх під час розгортання та відкочує, коли перевірки працездатності зазнають невдачі.

Пряме створення Podів майже ніколи не є доречним у продакшні. Deployments забезпечують управління репліками, поступові оновлення, історію відкатів та можливість паузи/відновлення процесу розгортання.

# api-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-server
  labels:
    app: api
spec:
  replicas: 3                    # run 3 identical Pods
  revisionHistoryLimit: 5        # keep 5 old ReplicaSets for rollback
  selector:
    matchLabels:
      app: api                   # must match Pod template labels
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1          # at most 1 Pod down during update
      maxSurge: 1                # at most 1 extra Pod during update
  template:
    metadata:
      labels:
        app: api
        version: v2
    spec:
      containers:
        - name: api
          image: registry.example.com/api:3.1.0
          ports:
            - containerPort: 8080
          resources:
            requests:
              cpu: "250m"
              memory: "256Mi"
            limits:
              cpu: "500m"
              memory: "512Mi"
          readinessProbe:
            httpGet:
              path: /healthz
              port: 8080
            initialDelaySeconds: 5
            periodSeconds: 10

Секція strategy.rollingUpdate визначає поведінку розгортання без простою. При maxUnavailable: 1 та maxSurge: 1 Kubernetes створює один новий Pod, чекає проходження readiness-перевірки, а потім зупиняє один старий Pod. Цей цикл повторюється, доки всі репліки не запустять нову версію.

Відкат невдалого Kubernetes Deployment

Відкати -- одна з найчастіших тем на співбесідах. Контролер Deployment зберігає старі ReplicaSets (кількість визначається параметром revisionHistoryLimit), тому відкат відбувається миттєво -- без потреби перезбирати образ.

# Check rollout status
kubectl rollout status deployment/api-server

# View revision history
kubectl rollout history deployment/api-server

# Roll back to previous version
kubectl rollout undo deployment/api-server

# Roll back to specific revision
kubectl rollout undo deployment/api-server --to-revision=3

Команда undo оновлює специфікацію Deployment відповідно до шаблону Podа цільової ревізії. Далі стратегія rolling update застосовується у звичайному режимі, поступово замінюючи поточні Podи на версію з відкату.

Kubernetes Services: стабільна мережева адресація для динамічних Podів

Podи -- ефемерні об'єкти. Вони отримують нові IP-адреси при кожному перезапуску. Service вирішує цю проблему, надаючи стабільну віртуальну IP-адресу (ClusterIP) та DNS-ім'я, яке маршрутизує трафік до справних Podів відповідно до label selector.

Компонент kube-proxy на кожному вузлі програмує правила iptables або IPVS для розподілу трафіку між бекенд-Podами. Коли Pod не проходить readiness-перевірку, контролер Endpoints видаляє його зі списку Service -- жоден трафік не потрапить до несправного екземпляра.

# api-service.yaml
apiVersion: v1
kind: Service
metadata:
  name: api-service
spec:
  type: ClusterIP               # internal-only by default
  selector:
    app: api                     # routes to Pods with this label
  ports:
    - name: http
      port: 80                   # Service port (what clients use)
      targetPort: 8080           # Pod port (where container listens)
      protocol: TCP

Після створення будь-який Pod у кластері може звертатися до цього Service за адресою api-service.default.svc.cluster.local (або просто api-service в межах того самого namespace). Розв'язання імен забезпечує CoreDNS.

Типи Service: ClusterIP, NodePort та LoadBalancer

Інтерв'юери очікують від кандидатів пояснення трьох основних типів Service та випадків застосування кожного з них.

| Тип | Область доступу | Сценарій використання | |-----|----------------|----------------------| | ClusterIP | Лише всередині кластера | Бекенд API, бази даних, кеш | | NodePort | Зовнішній через <NodeIP>:<Port> | Розробка, bare-metal кластери | | LoadBalancer | Зовнішній через хмарний балансувальник | Продакшн-трафік на AWS/GCP/Azure |

# api-loadbalancer.yaml
apiVersion: v1
kind: Service
metadata:
  name: api-public
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-type: "nlb"  # AWS NLB
spec:
  type: LoadBalancer
  selector:
    app: api
  ports:
    - name: https
      port: 443
      targetPort: 8080
      protocol: TCP

Тип LoadBalancer активує контролер хмарного провайдера для створення зовнішньої точки доступу. На AWS це створює NLB або ALB залежно від анотацій. На bare-metal кластерах без хмарної інтеграції цю роль виконують MetalLB або kube-vip.

З'єднання Deployments та Services через label selectors

Зв'язок між Deployment та Service базується виключно на label selector -- нічого більше. Явного посилання між цими двома об'єктами не існує. Service стежить за Podами, чиї мітки збігаються з його spec.selector, та автоматично підтримує список Endpoints.

Ця розв'язана архітектура означає, що один Service може маршрутизувати трафік до Podів з кількох Deployments (корисно для канаркових релізів), а один Deployment може бути доступний через кілька Services (різні порти, різні рівні доступу).

# canary-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-server-canary
spec:
  replicas: 1
  selector:
    matchLabels:
      app: api                   # same label as main Deployment
  template:
    metadata:
      labels:
        app: api                 # Service picks this up automatically
        version: v3-canary
    spec:
      containers:
        - name: api
          image: registry.example.com/api:3.2.0-rc1
          ports:
            - containerPort: 8080

При 3 репліках основного Deployment та 1 репліці канаркового Service розподілятиме приблизно 25% трафіку на канаркову версію. Зміна конфігурації Service не потрібна -- зіставлення міток забезпечує все автоматично.

Горизонтальне автомасштабування Podів (HPA) для Kubernetes Deployments

Статична кількість реплік марнує ресурси при низькому трафіку та не справляється зі сплесками навантаження. HorizontalPodAutoscaler (HPA) автоматично коригує кількість реплік на основі спостережуваних метрик.

# api-hpa.yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-server
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70   # scale up above 70% CPU
    - type: Resource
      resource:
        name: memory
        target:
          type: Utilization
          averageUtilization: 80
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300  # wait 5 min before scaling down

HPA опитує metrics server кожні 15 секунд за замовчуванням. У Kubernetes v1.35 з'явилась можливість налаштування порогу толерантності HPA, що замінює жорстко закодований поріг у 10%. Це дозволяє командам, які працюють із чутливими до затримок навантаженнями, встановлювати точніші тригери масштабування.

Параметр behavior.scaleDown.stabilizationWindowSeconds запобігає flapping -- швидким циклам збільшення/зменшення кількості реплік, що виникають при нерівномірних патернах трафіку.

Типові запитання на Kubernetes-співбесідах та відповіді

Ці запитання регулярно з'являються на DevOps та platform engineering співбесідах. Кожна відповідь відповідає глибині, яку очікують інтерв'юери.

Що відбувається, коли Pod перевищує ліміт пам'яті? Kubelet надсилає SIGKILL через OOM killer. Контейнер завершується з кодом 137. Контролер Deployment виявляє невдалий Pod та створює заміну відповідно до політики перезапуску та затримок backoff.

Як Kubernetes маршрутизує трафік на конкретну версію Podа під час канаркового релізу? Service selector зіставляє спільні мітки (наприклад, app: api). Обидва Deployments -- стабільний та канарковий -- використовують цю мітку. Розподіл трафіку пропорційний кількості готових endpointів -- 3 стабільні репліки + 1 канаркова = приблизно 25% канаркового трафіку. Для точнішого розподілу (наприклад, 5%) варто використовувати Gateway API HTTPRoute з weighted backends.

Яка різниця між readinessProbe та livenessProbe? Readiness probe контролює, чи отримує Pod трафік від Service. Невдала readiness probe видаляє Pod зі списку Endpoints, але не перезапускає його. Liveness probe контролює, чи буде контейнер перезапущено. Невдала liveness probe спричиняє перезапуск контейнера. Обидва типи можуть використовувати HTTP, TCP або exec перевірки.

Як rolling updates гарантують нульовий час простою? Контролер Deployment створює нові Podи перед зупинкою старих, відповідно до параметрів maxSurge та maxUnavailable. Нові Podи повинні пройти readiness probe перед тим, як старі Podи будуть виведені з обслуговування. Параметр terminationGracePeriodSeconds (за замовчуванням 30 секунд) дає час поточним запитам завершитися до надсилання SIGKILL.

Підготовка до Kubernetes-співбесіди потребує практичної роботи з YAML, а не лише теоретичних знань. Запитання для DevOps-співбесід на SharpSkill охоплюють ці теми з інтерактивними вправами.

Висновки

• Podи є одиницею планування -- завжди встановлюйте ресурсні requests та limits, а також налаштовуйте readiness та liveness probes
• Deployments керують кількістю реплік, поступовими оновленнями та історією відкатів через ReplicaSets -- створення голих Podів у продакшні неприпустиме
• Services забезпечують стабільну мережеву адресацію через label selectors та віртуальні IP -- ClusterIP для внутрішнього трафіку, LoadBalancer для зовнішнього
• Зв'язок між Deployments та Services базується виключно на мітках, що дозволяє реалізовувати канаркові розгортання без змін конфігурації
• HPA масштабує Deployments на основі метрик CPU та пам'яті -- параметр stabilizationWindowSeconds запобігає flapping
• Gateway API замінює Ingress NGINX починаючи з Kubernetes v1.35 -- нові проєкти мають впроваджувати його від початку
• Практика з реальними YAML-маніфестами та командами kubectl значно ефективніша за заучування визначень