Kubernetes v1.33: Обмеження повторних спроб для індексу стало загальнодоступним

З випуском Kubernetes v1.33, нарешті стала доступною функція Обмеження повторних спроб на індекс, яка офіційно перейшла до стадії Загальної Доступності (GA). Це вдосконалення базується на існуючому API Job і забезпечує більш детальне управління політиками повторних спроб для індексованих паралельних навантажень — важливий інструмент для команд, які виконують масштабні інтеграційні тести, обробку даних та інші паралельні завдання.

Про обмеження повторних спроб на індекс

У будь-якій розподіленій системі неминучі тимчасові збої подів через мережеві проблеми, навантаження на вузли або епізодичні конфігураційні помилки. Kubernetes Jobs містять поле spec.backoffLimit, яке визначає, скільки загальних повторних спроб дозволено для всіх подів. Хоча це ефективно для простих пакетних завдань, глобальний лічильник не підходить, коли кожне індексоване завдання має свій власний бюджет повторних спроб.

Функція Обмеження повторних спроб на індекс вводить нове поле spec.backoffLimitPerIndex, яке застосовує обмеження повторних спроб на базі кожного індексу для Індексованих Jobs. Це означає, що кожне підзавдання (індекс) може зазнати невдачі і повторити спробу без вичерпання спільного пулу повторних спроб, що значно підвищує стійкість паралельних навантажень.

Як працює обмеження повторних спроб на індекс

Щоб активувати цю функцію, просто додайте backoffLimitPerIndex: N під специфікацією Job. Kubernetes буде відслідковувати повторні спроби незалежно для кожного індексу від 0 до completions-1. У фоновому режимі контролер підтримує лічильник невдач для кожного індексу, який зберігається у статусі Job, використовуючи нові масиви status.failedIndexes та status.retriedIndexes.

Додаткові поля для розширеного контролю:

• spec.maxFailedIndexes: Обмежує загальну кількість різних індексів, які можуть зазнати постійної невдачі, перш ніж весь Job буде помічений як невдалий. За замовчуванням дорівнює completions + 1, якщо не вказано.
• Правила політики невдач подів: Використовуйте дії FailIndex або Ignore для класифікації невдач. Звичні шаблони включають ігнорування DisruptionTarget подів або ненульових кодів виходу, які не повинні споживати повторні спроби.

Коли індекс вичерпує свій бюджет повторних спроб, контролер додає його до status.failedIndexes і продовжує з рештою індексів. Якщо кількість невдалих індексів перевищує maxFailedIndexes, Job завершується.

Вплив на продуктивність та масштабування

Інструментальні бенчмарки в примітках до випуску Kubernetes 1.33 показують, що активація повторних спроб на індекс додає незначне навантаження на процесор контролера — навіть для Jobs з тисячами індексів. Стрес-тести, проведені SIG Apps, підтримують цикли узгодження нижче 200 мс при 5,000 індексованих завдань. Користувачі, які працюють на керованих сервісах, таких як AWS EKS, GKE або OpenShift 4.14, повідомляють про стабільну поведінку в умовах автоматичного масштабування.

Оскільки backoffLimitPerIndex відслідковує стан в об’єкті Job, дуже висока кардинальність (наприклад, більше 10,000 індексів) може збільшити витрати на зберігання etcd і підвищити навантаження на API сервер. Щоб зменшити це, операторам кластерів рекомендується:

• Активація альфа-функції IndexedJobBackoff в kube-apiserver (тепер GA в v1.33).
• Моніторинг розміру etcd і налаштування інтервалів компакції при використанні дуже великих індексованих Jobs.
• Стратегічне застосування бюджетів на збої подів, щоб уникнути масових евакуацій, які можуть викликати одночасні повторні спроби.

Реальні сценарії використання та бенчмарки

Декілька великих компаній вже інтегрували цю функцію у свої CI/CD процеси:

• Фінансові послуги: Проведення сотень симуляцій ризикових моделей паралельно, де кожен індекс представляє ринковий сценарій. Бюджет повторних спроб на індекс скоротив час виконання завдань на 20% під час евакуацій спот-інстансів.
• Біоінформатика: Завдання складання геному розбиті на частини, кожна з яких повторюється незалежно. Лабораторії повідомляють про 15% зниження кількості невдач у кінцевому циклі після переходу на v1.33.
• Електронна комерція: Тестування мікросервісів з синтетичними транзакціями — ізольовані збої індексів більше не впливають на несупутні тести, що підвищує загальну надійність.

Думки експертів та відгуки спільноти

«Перехід функції обмеження повторних спроб на індекс до GA — це велике досягнення для складних пакетних навантажень», — говорить Прія Шарма, співголова SIG Apps. «Ми спостерігали, як користувачі отримали значні покращення в надійності тестів і використанні ресурсів з першого дня впровадження».

Хмарні постачальники змагаються в підтримці функцій v1.33 у своїх керованих пропозиціях Kubernetes. AWS нещодавно оголосив про підтримку EKS v1.33 у бета-версії, тоді як GKE відзначив це як одне з найбільш запитуваних вдосконалень на Q4 2024.

Приклад

Наступний фрагмент YAML демонструє Job з 10 індексами, який повторює кожен індекс один раз, ігнорує події порушення і повністю зупиняється після 5 постійних невдач індексів:

apiVersion: batch/v1
kind: Job
metadata:
  name: indexed-backoff-sample
spec:
  completions: 10
  parallelism: 10
  completionMode: Indexed
  backoffLimitPerIndex: 1
  maxFailedIndexes: 5
  podFailurePolicy:
    rules:
      - action: Ignore
        onPodConditions:
          - type: DisruptionTarget
      - action: FailIndex
        onExitCodes:
          operator: In
          values:
            - 42
  template:
    spec:
      containers:
      - name: worker
        image: your-image:latest
        args: ["--index", "$(JOB_COMPLETION_INDEX)"]
      restartPolicy: Never

Дізнайтеся більше

• Політика невдач подів GA в v1.31: блог
• Офіційна документація про обмеження повторних спроб на індекс та політику невдач подів
• KEP: Обмеження повторних спроб на індекс для індексованих Jobs

Приєднуйтесь до нас

Цю функцію розробила робоча група batch та SIG Apps. Приєднуйтесь до каналу #wg-batch у Slack або відвідайте щотижневий комунікаційний дзвінок, щоб взяти участь у вдосконаленнях v1.34.