Какой ресурс создает jobs в k8s?

Отличный вопрос, который касается фундаментальной концепции оркестрации в Kubernetes. Прямой и простой ответ: Job в Kubernetes создается пользователем (или системой автоматизации) путем применения манифеста YAML или выполнения команды kubectl, который отправляет запрос на API-сервер Kubernetes (kube-apiserver). API-сервер — это единственная точка входа для всех изменений в кластере, и он валидирует, сохраняет и обрабатывает этот запрос.

Однако за этим простым ответом скрывается цепочка ключевых ресурсов и контроллеров, которые делают работу Job возможной. Давайте разберем это подробно.

Кто и что создает Job?

1. Пользователь/Оператор (Declarative/Imperative подход): Вы, как инженер, или система CI/CD (например, Jenkins, GitLab Runner) создаете файл job.yaml. Затем вы применяете его с помощью:

   kubectl apply -f job.yaml
   

    Или создаете игрушечный Job императивно:

```bash
kubectl create job my-test-job --image=busybox -- echo "Hello"
```

2. API-сервер (kube-apiserver): Команда kubectl отправляет HTTP-запрос к API-серверу. API-сервер проводит аутентификацию, авторизацию и валидацию манифеста. Если все в порядке, он сохраняет состояние Job (желаемое количество завершенных Pod'ов и их спецификацию) в распределенном key-value хранилище — etcd. Это источник истины для кластера.

Что происходит после создания Job в etcd?

Сам по себе факт записи в etcd ничего не запускает. Запуском и управлением жизненным циклом Job занимается контроллер.

Ключевой механизм: Job Controller

В Control Plane Kubernetes работает специальный компонент — Job Controller. Он является частью kube-controller-manager. Его единственная задача — наблюдать за изменениями объектов Job в etcd (через API-сервер) и приводить фактическое состояние системы к желаемому, описанному в Job.

Алгоритм работы Job Controller для вновь созданного Job:

1. Watch (Наблюдение): Контроллер подписывается на события API, связанные с ресурсами типа Job.
2. Diff (Сравнение): Он обнаруживает новый Job, у которого spec.completions (требуемое количество успешных завершений) не равно status.succeeded (текущее количество успешных Pod'ов). Обычно для нового Job status.succeeded = 0.
3. Reconcile (Согласование): Контроллер понимает, что нужно создать Pod(ы). Он не создает Pod напрямую. Вместо этого он создает и отправляет в API-сервер запрос на создание одного или нескольких объектов Pod, спецификация которых (spec.template) взята из манифеста Job.
4. Создание Pod'ов: Запрос на создание Pod проходит через тот же API-сервер и сохраняется в etcd.
5. Наблюдение за Pod'ами: Job Controller теперь также начинает наблюдать за созданными им Pod'ами. Он отслеживает их статус (Pending, Running, Succeeded, Failed).
6. Управление повторами и завершением:

    *   Если Pod завершается **успешно** (`Succeeded`), контроллер увеличивает `status.succeeded`. Если достигнуто нужное количество `completions`, Job помечается как завершенный.
    *   Если Pod **падает с ошибкой** (`Failed`), поведение зависит от `spec.backoffLimit` и `spec.restartPolicy` (который для Job может быть только `Never` или `OnFailure`).
        *   При `restartPolicy: OnFailure` **kubelet** на ноде перезапустит контейнер внутри того же Pod.
        *   При `restartPolicy: Never` или если перезапуски исчерпаны, Job Controller **создаст новый Pod** для повторного выполнения задачи. Это принципиальное отличие Job от Deployment: при сбое создается новый Pod, а не перезапускается старый.

Взаимодействие с другими компонентами

• Scheduler (kube-scheduler): Как только Pod, созданный Job, появляется в etcd со статусом Pending, в работу вступает Scheduler. Он назначает этот Pod на конкретную ноду в кластере, исходя из критериев доступности ресурсов (CPU/RAM), affinity/anti-affinity правил и т.д. Решение о назначении (nodeName) записывается обратно в spec Pod'а через API-сервер.
• Kubelet: На назначенной ноде kubelet (агент) наблюдает за Pod'ами, которые должны быть на его ноде. Он обнаруживает новый Pod, скачивает образ, создает контейнеры через container runtime (например, containerd) и запускает их. Kubelet также отвечает за обновление статуса Pod'а и его перезапуск (если restartPolicy: OnFailure).

Итог и аналогия

Ресурс, который создает Jobs — это вы (или ваш инструмент) через API-сервер. Но "мозгом", который управляет Job, является Job Controller. Весь процесс можно представить как конвейер:

Ваш манифест (YAML) -> kubectl -> API-сервер -> etcd -> Job Controller -> (Создание Pod) -> API-сервер -> etcd -> Scheduler -> (Назначение ноды) -> API-сервер -> etcd -> Kubelet (на ноде) -> Container Runtime -> Выполнение задачи.

Важное уточнение: Существуют также CronJobs (kind: CronJob) — это更高уровневый ресурс, который сам создает объекты Job по расписанию, указанному в spec.schedule. CronJob Controller наблюдает за временем и, когда наступает момент, создает новый Job объект, после чего вся описанная выше цепочка запускается заново.