Kubernetes v1.34: Ресурси на рівні Podʼа переходять у бета

Від імені спільноти 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 (наприклад, агент логування або проксі service mesh), що досягав свого індивідуального обмеження CPU, міг бути обмежений (throttled) і сповільнювати роботу всього Podʼа, навіть якщо основний контейнер застосунку мав достатньо вільного CPU. За допомогою ресурсів на рівні Podʼа sidecarʼи та основний контейнер можуть спільно використовувати ресурси Podʼа, забезпечуючи безперебійну роботу під час пікових навантажень — або обмежується весь Pod, або працюють усі контейнери.

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

  Для планування, якщо запит на рівні Podʼа явно визначений, планувальник використовує це конкретне значення для пошуку відповідного вузла, а не сукупні запити окремих контейнерів. Під час виконання обмеження на рівні 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 ядро CPU.
      memory: "200Mi" # Весь Pod не може використовувати більше ніж 200 МіБ памʼяті.
    # 'requests' визначає мінімальний обсяг ресурсів, гарантований Podʼу.
    # Це значення використовується планувальником Kubernetes для пошуку вузла з достатньою ємністю.
    requests:
      cpu: "1" # Pod гарантовано отримує 1 ядро CPU при плануванні.
      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 під час етапу перевірки. Якщо Pod явно не позначений для Windows, але запланований для вузла Windows (наприклад, за допомогою nodeSelector), Kubelet на цьому вузлі Windows відхилить Pod під час процесу допуску.

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

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

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

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

• Slack: #sig-node
• Список розсилки
• Відкриті тікети спільноти/PR

• ←Попередня
• Наступна→