Kubernetes v1.34: Ресурси рівня Pod перейшли в стадію бета

Автор Dixita Narang (Google) | Перекладач(і) Андрій Головін |

Від імені спільноти Kubernetes я з радістю повідомляю, що функція Pod Level Resources (Ресурси рівня Pod) перейшла в стадію бета у версії Kubernetes v1.34 і є стандартно увімкненою! Ця важлива подія відкриває нові можливості для визначення та управління розподілом ресурсів для ваших Podʼів. Така гнучкість зумовлена можливістю вказати ресурси CPU та памʼяті для Podʼа в цілому. Ресурси на рівні Podʼа можна поєднувати зі специфікаціями на рівні контейнера, щоб точно визначити вимоги до ресурсів та обмеження, необхідні для вашого застосунку.

Специфікація ресурсів на рівні Podʼа

До недавнього часу специфікації ресурсів, що застосовувалися до Podʼа, визначалися переважно на рівні окремих контейнерів. Хоча такий підхід був ефективним, іноді він вимагав дублювання або ретельного розрахунку потреб у ресурсах для декількох контейнерів в одному Podʼі. У якості бета-функції Kubernetes дозволяє визначати ресурси CPU, памʼяті та hugepages на рівні Podʼа. Це означає, що тепер ви можете визначати запити та обмеження ресурсів для всього Podʼа, що спрощує спільне використання ресурсів без необхідності детального управління цими ресурсами для кожного контейнера, де це не потрібно.

Чому важливі специфікації на рівні Podʼа?

Ця функція покращує управління ресурсами в Kubernetes, пропонуючи гнучке управління ресурсами як на рівні Podʼів, так і на рівні контейнерів.

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

  • Ресурси на рівні Podʼа дозволяють контейнерам у Podʼі обмінюватися між собою невикористаними ресурсами, сприяючи ефективному використанню ресурсів у Podʼі. Наприклад, це запобігає перетворенню контейнерів-sidecar на вузькі місця, що обмежують продуктивність. Раніше sidecar (наприклад, агент логування або проксі сервісної мережі), що досягали свого індивідуального обмеження CPU, могли бути стишені і сповільнювати роботу всього Podʼа, навіть якщо основний контейнер застосунку мав достатньо вільного CPU. За допомогою ресурсів на рівні Podʼа sidecarʼи та основний контейнер можуть спільно використовувати ресурси Podʼа, забезпечуючи безперебійну роботу під час пікових навантажень — або весь Pod стишується, або всі контейнери працюють.

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

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

  • Ресурси на рівні Podʼів мають пріоритет у впливі на клас якості обслуговування (QoS) Podʼа.

  • Для Podʼів, що працюють на вузлах Linux, при розрахунку коригування показника Out-Of-Memory (OOM) враховуються запити на ресурси як на рівні Podʼа, так і на рівні контейнера.

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

Як вказати ресурси для всього Pod

Використання функціональної можливості PodLevelResources вимагає Kubernetes v1.34 або новішої версії для всіх компонентів кластера, включаючи панель управління та кожен вузол. Ця функція знаходиться в бета-версії та є стандартно увімкненою у v1.34.

Приклад маніфесту

Ви можете вказати ресурси CPU, памʼяті та hugepages безпосередньо в маніфесті специфікації Podʼа у полі resources для всього Podʼа.

Ось приклад, що демонструє Pod із запитами та обмеженнями CPU та памʼяті, визначеними на рівні Pod:

apiVersion: v1
kind: Pod
metadata:
  name: pod-resources-demo
  namespace: pod-resources-example
spec:
  # Поле 'resources' на рівні специфікації Podʼа визначає загальний
  # бюджет ресурсів для всіх контейнерів у цьому Podʼі разом.
  resources: # Ресурси на рівні Podʼа
    # 'limits' визначає максимальну кількість ресурсів, яку може використовувати Pod.
    # Сума обмежень усіх контейнерів у Podʼі не може перевищувати ці значення.
    limits:
      cpu: "1" # Весь Pod не може використовувати більше 1 ядро процесора.
      memory: "200Mi" # Весь Pod не може використовувати більше 200 МБ памʼяті.
    # 'requests' визначає мінімальний обсяг ресурсів, гарантований Podʼу.
    # Це значення використовується планувальником Kubernetes для пошуку вузла з достатньою ємністю.
    requests:
      cpu: "1" # Pod гарантовано отримує 1 ядро процесора при плануванні.
      memory: "100Mi" # При плануванні Pod гарантується 100 МБ памʼяті.
  containers:
  - name: main-app-container
    image: nginx
    ...
    # Для цього контейнера не вказано жодних запитів на ресурси або обмежень.
  - name: auxiliary-container
    image: fedora
    command: ["sleep", "inf"]
    ...
    # Для цього контейнера не вказано жодних запитів на ресурси або обмежень.

У цьому прикладі Pod pod-resources-demo в цілому запитує 1 CPU і 100 MiB памʼяті, і обмежений 1 CPU і 200 MiB памʼяті. Контейнери всередині будуть працювати в рамках цих загальних обмежень на рівні Podʼа, як пояснено в наступному розділі.

Взаємодія з запитами або обмеженнями ресурсів на рівні контейнера

Коли вказані ресурси як на рівні Podʼа, так і на рівні контейнера, запити та обмеження на рівні podʼа мають пріоритет. Це означає, що вузол розподіляє ресурси на основі специфікацій на рівні pod.

Розглянемо Pod з двома контейнерами, де визначені запити та обмеження на рівні podʼа щодо CPU та памʼяті, і лише один контейнер має власні явні визначення ресурсів:

apiVersion: v1
kind: Pod
metadata:
  name: pod-resources-demo
  namespace: pod-resources-example
spec:
  resources:
    limits:
      cpu: "1"
      memory: "200Mi"
    requests:
      cpu: "1"
      memory: "100Mi"
  containers:
  - name: main-app-container
    image: nginx
    resources:
      requests:
        cpu: "0.5"
        memory: "50Mi"
  - name: auxiliary-container
    image: fedora
    command: [ "sleep", "inf"]
    # Для цього контейнера не вказано жодних запитів на ресурси або обмежень.

  • Обмеження на рівні Podʼа: Обмеження на рівні Podʼа (cpu: "1", memory: "200Mi") встановлюють абсолютну межу для всього Podʼа. Сума ресурсів, що споживаються всіма його контейнерами, обмежується цією межею і не може бути перевищена.

  • Спільне використання та перевищення ресурсів: контейнери можуть динамічно запозичувати будь-яку невикористану потужність, що дозволяє їм перевищувати обмеження за потреби, якщо сукупне використання Podʼа залишається в межах загального обмеження.

  • Запити на рівні Pod: запити на рівні Pod (cpu: "1", memory: "100Mi") слугують основою для гарантування ресурсів для всього Podʼа. Це значення впливає на рішення планувальника щодо розміщення і представляє мінімальні ресурси, на які Pod може розраховувати під час конфлікту на рівні вузла.

  • Запити на рівні контейнера: запити на рівні контейнера створюють систему пріоритетів у межах гарантованого бюджету Podʼа. Оскільки main-app-container має явний запит (cpu: "0.5", memory: "50Mi"), йому надається пріоритет у розподілі ресурсів під тиском ресурсів над auxiliary-container, який не має такого явного запиту.

Обмеження

  • По-перше, зміна на місці розміру ресурсів на рівні pod не підтримується для Kubernetes v1.34 (або раніше). Спроба змінити обмеження або запити ресурсів на рівні podʼа для працюючого Podʼа призводить до помилки: зміна розміру відхиляється. Реалізація ресурсів на рівні Podʼа у версії v1.34 зосереджена на тому, щоб дозволити початкове оголошення загального ресурсного конверту, який застосовується до всього Podʼа. Це відрізняється від зміни розміру на місці, яка (незважаючи на те, що може натякати назва) дозволяє динамічно коригувати запити та обмеження ресурсів контейнера в працюючому Podʼі і, можливо, без перезапуску контейнера. Зміна розміру на місці також ще не є стабільною функцією; вона перейшла в стадію бета у версії v1.33.

  • На рівні pod можна вказати лише ресурси CPU, памʼяті та великі сторінки (hugepages).

  • Ресурси на рівні pod не підтримуються для podʼів Windows. Якщо специфікація Podʼа явно націлена на Windows (наприклад, шляхом встановлення spec.os.name: "windows"), сервер API відхилить Pod під час етапу перевірки. Якщо под явно не позначений для Windows, але запланований для вузла Windows (наприклад, за допомогою nodeSelector), Kubelet на цьому вузлі Windows відхилить под під час процесу допуску.

  • Менеджер топології, менеджер памʼяті та менеджер процесора не вирівнюють под і контейнери на основі ресурсів на рівні пода, оскільки ці менеджери ресурсів наразі не підтримують ресурси на рівні пода.

Початок роботи та надання відгуків

Готові ознайомитися з функцією Pod Level Resources? Вам знадобиться кластер Kubernetes з версією 1.34 або пізнішою. Не забудьте увімкнути функціональну можливість PodLevelResources у вашій панелі управління та на всіх вузлах.

Оскільки ця функція перебуває на стадії бета-тестування, ваші відгуки є надзвичайно цінними. Будь ласка, повідомляйте про будь-які проблеми або діліться своїм досвідом через стандартні канали комунікації Kubernetes: