Це багатосторінкова версія цього розділу для друку. Натисніть тут, щоб надрукувати.

Повернутися до звичайного перегляду сторінки.

Workload API

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.35 [alpha](стандартно вимкнено)

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

Що таке робоче навантаження?

Ресурс Workload API є частиною scheduling.k8s.io/v1alpha1 групи API (і ваш кластер повинен мати цю групу API увімкнену, а також функціональну можливість GenericWorkload, перш ніж ви зможете скористатися цим API). Цей ресурс діє як структуроване, машиночитане визначення вимог до планування багатоподових застосунків. У той час як робочі навантаження, орієнтовані на користувача, такі як Jobs, визначають, що потрібно запустити, ресурс Workload визначає, як слід планувати групу Podʼів і як слід керувати її розміщенням протягом усього життєвого циклу.

Структура API

Workload дозволяє визначити групу Podsʼів і застосувати до них політику планування. Він складається з двох розділів: списку груп подів і посилання на контролер.

Групи Podʼів

Список podGroups визначає окремі компоненти вашого робочого навантаження. Наприклад, завдання машинного навчання може мати групу driver та групу worker.

Кожен запис у podGroups повинен мати:

  1. Унікальне поле name, яке можна використовувати в посиланні на Workload Podʼів.
  2. Політику планування (basic або gang).
apiVersion: scheduling.k8s.io/v1alpha1
kind: Workload
metadata:
  name: training-job-workload
  namespace: some-ns
spec:
  controllerRef:
    apiGroup: batch
    kind: Job
    name: training-job
  podGroups:
  - name: workers
    policy:
      gang:
        # gang може бути запланована тільки в тому випадку, якщо одночасно можуть працювати 4 пода.
        minCount: 4

Посилання на обʼєкт керування робочим навантаженням

Поле controllerRef звʼязує Workload з конкретним обʼєктом вищого рівня, що визначає застосунок, наприклад Job або власний CRD. Це корисно для спостереження та інструментів. Ці дані не використовуються для планування або управління Workload.

Що далі

1 - Політики груп Podʼів

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.35 [alpha](стандартно вимкнено)

Кожна група Podʼів, визначена у Workload, повинна мати політику планування. Ця політика визначає, як планувальник обробляє колекцію Podʼів.

Типи політик

Наразі API підтримує два типи політик: basic та gang. Ви повинні вказати тільки одну політику для кожної групи.

Політика basic

Політика basic наказує планувальнику вважати всі Podʼи у групі незалежними сутностями, плануючи їх за допомогою стандартного поведіння Kubernetes.

Основна причина використання політики basic полягає в тому, щоб організувати Podʼи у вашому Workload для кращої спостережуваності та управління.

Цю політику можна використовувати для груп Workload, які не потребують одночасного запуску, але логічно належать до застосунку, або для відкриття шляху до майбутніх групових обмежень, які не передбачають розміщення "все або нічого".

policy:
  basic: {}

Політика gang

Політика gang забезпечує планування "все або нічого". Це необхідно для сильно звʼязаних робочих навантажень, де частковий запуск призводить до блокувань або втрати ресурсів.

Цю політику можна використовувати для Jobs або будь-якого іншого пакетного процесу, де всі працівники повинні працювати одночасно, щоб зробити прогрес.

Політика gang вимагає параметра minCount:

policy:
  gang:
    # Кількість Podʼів, які повинні бути заплановані одночасно
    # для того, щоб група була прийнята.
    minCount: 4

Що далі