Kubernetes Python Client - Поиск ожидающих заданий и планирование всех модулей за один раз или как запланировать отложенные задания

Question

Я использую Kubernetes 1.7 и Python Client 2.0. У меня есть программа машинного обучения MNIST из TensorFlow, работающая в кластере K8. У него есть один рабочий и один сервер параметров. Он развернут как kind: Job (в манифесте). Пользовательский планировщик, написанный на python, следит за ожидающими модулями, используя list_namespaced_pod, и планирует их в зависимости от доступности ресурсов. Так как поступает поток событий, как я могу убедиться, что все ожидающие модули под одной работой запланированы или нет? Другими словами, я не хочу планировать работу частично, планировать все пакеты ожидающих работ или ни одной.

Кроме того, есть ли способ в Kubernetes перехватывать / находить / просматривать все события одного и того же задания (т. Е. Развернутые в одном файле манифеста) за один раз? Я также пытался list_namespaced_event, но это также сообщает о событиях один за другим. В результате может случиться так, что одна часть задания может быть запланирована, а вторая - нет. Небольшая версия пользовательского планировщика доступна здесь .

файл my-mnist.yml (уменьшенная версия)

---

apiVersion: batch/v1
kind: Job
metadata:
  name: my-ps 
  labels:
    name: my-ps 
    jobName: my-ps-mnist_dist
  namespace: my-namespace
spec:
  template:
    metadata:
      labels:
        name: my-ps 
        jobName: my-ps-mnist_dist
        jobId: 5b2a6cd25b02821468e41571
        manifestFile: my-mnist.yml
        jobTrainingType: distributed
        jobTaskName: "my-ps"
        jobTaskIndex: "0"
        jobWorkerInstances: "1"
      namespace: my-namespace
    spec:
      nodeSelector:
        gpu: "no"
        dlts: "yes"
      containers:
        - name: my-ps
          image: "123.456.789.10:1234/myimg/5b2a6cd25b02821468e41571"
          imagePullPolicy: Always
          tty: true
          stdin: true
          env:
            - name: JOB_TASK_NAME
              value: "ps"
            - name: JOB_ID
              value: "5b2a6cd25b02821468e41571"
            - name: JOB_LD_LIBRARY_PATH
              value: "/usr/local/cuda-9.0/lib64:/usr/lib64/nvidia:/usr/local/cuda-9.0/targets/x86_64-linux/lib"
            - name: JOB_PYTHON_VERSION
              value: "3"


---

apiVersion: batch/v1
kind: Job 
metadata:
  name: my-wkr
  labels:
    name: my-wkr
    jobName: wkr0-mnist_dist
  namespace: my-namespace
spec:
  template:
    metadata:
      labels:
        name: my-wkr
        jobName: wkr0-mnist_dist
        jobId: 5b2a6cd25b02821468e41571
        manifestFile: my-mnist.yml
        jobTrainingType: distributed
        jobTaskName: "worker"
        jobTaskIndex: "0"
        jobWorkerInstances: "1" 
      namespace: my-namespace
    spec:
      nodeSelector:
        gpu: "yes"
        dlts: "yes"
      containers:
        - name: my-wkr
          image: "123.456.789.10:1234/myimg/5b2a6cd25b02821468e41571" 
          imagePullPolicy: Always
          tty: true
          stdin: true
          resources:
            limits:
              alpha.kubernetes.io/nvidia-gpu: 2
          env:
            - name: JOB_TASK_NAME
              value: "worker"
            - name: JOB_TASK_INDEX
              value: "0"
            - name: JOB_ID
              value: "5b2a6cd25b02821468e41571"
            - name: JOB_LD_LIBRARY_PATH
              value: "/usr/local/cuda-9.0/lib64:/usr/lib64/nvidia:/usr/local/cuda-9.0/targets/x86_64-linux/lib"
            - name: JOB_PYTHON_VERSION
              value: "3"

Answer 1

Кроме того, есть ли способ в Kubernetes перехватывать / находить / смотреть все события одного и того же задания (т. Е. Развернутого в одном файле манифеста) за раз?

Короткий ответ - нет. В любом случае все события модуля проходят один за другим.

Мне в голову приходит одна возможность:
Поскольку модули, для которых требуется настраиваемый планировщик, не могут быть запланированы каким-либо другим планировщиком, ваш настраиваемый планировщик может собирать список модулей, относящихся к одному и тому же заданию, и планировать их один за другим, а затем переходить к списку, связанному со следующим заданием. Таким образом вы можете быть уверены, что ресурсы, предназначенные для использования модулями первого задания, не будут выделены для одного из модулей, связанных с другим заданием, до того, как все модули, связанные с первым заданием, будут запланированы для узлов.

В событии, которое получает планировщик, есть аннотации и метки. Я не проверял результаты list_namespaces_pod или list_namespaces_event, но я думаю, что аннотации и метки должны быть там. Можно настроить конфигурацию задания в аннотациях, например, количество модулей в задании или метки для каждого модуля в задании (например, labels:{job_ID:100,role:master,uid:xxx}, annotations:{[job_ID:none, master:none, worker1:none worker2:none]}). Когда планировщик видит первый модуль с аннотациями для задания, которого у него еще нет, он создает новый список модулей для задания ([job_ID:100, master:xxx, worker1:none worker2:none]). При появлении следующих событий планировщик заполняет этот список, используя метки модуля, и списки расписаний только полностью заполнены ([job_ID:100, master:uid1, worker1:uid2: worker2:uid3]).