В версии Kubernetes 1.35 стала стабильной (GA) долгожданная функция — поле
.spec.managedBy для ресурсов Job. Теперь можно явно указать, какой контроллер отвечает за управление задачей, открывая новые возможности для интеграции с внешними системами.
➡️ Зачем делегировать управление Job?
— Сложная логика выполнения
Внешние контроллеры могут реализовывать продвинутые сценарии.
— Интеграция с экосистемой
Системы оркестрации рабочих процессов получают нативный способ управления созданными через них заданиями.
— Чёткое разделение ответственности
Исключаются конфликты между встроенным контроллером Kubernetes и внешними системами.
— Упрощение отладки
По значению поля managedBy сразу понятно, какая система управляет задачей.
➡️ Как работает
.spec.managedBy?🟡 Обычная Job (управляется встроенным контроллером)
apiVersion: batch/v1
kind: Job
metadata:
name: classic-job
spec:
# Поле managedBy отсутствует - управляет kube-controller-manager
template:
spec:
containers:
- name: calculator
image: alpine:latest
command: ["sh", "-c", "echo 'Result: $(expr 10 \* 10)'"]
restartPolicy: Never
🟡 Job с делегированным управлением
apiVersion: batch/v1
kind: Job
metadata:
name: managed-externally
spec:
managedBy: argo-workflows-controller # Указываем внешний контроллер
template:
spec:
containers:
- name: data-processor
image: data-processor:latest
command: ["process", "--dataset", "daily"]
restartPolicy: OnFailure
➡️ Что происходит:
— Встроенный контроллер Kubernetes видит поле managedBy и не вмешивается в управление Job
— Внешний контроллер (например, Argo Workflows) отслеживает Job с такой меткой
— Весь жизненный цикл (перезапуски, обработка завершения) ложится на внешний контроллер
Поле
.spec.managedBy — это элегантный механизм интеграции, который превращает нативные Kubernetes Job в строительные блоки для сложных систем оркестрации. Он позволяет реализовывать продвинутые сценарии выполнения задач, сохраняя преимущества Kubernetes API и избегая войны контроллеров.➡️ Подробнее в официальной анонсе в блоге Kubernetes
#заметкиИнженера