Автоматическое масштабирование узла Kubernetes и точный контроль над пакетами на узел

Question

Я пытаюсь реплицировать пакетный API Azure в Kubernetes, у меня есть веб-интерфейс API, который работает как служба и, в свою очередь, использует API Kubernetes для динамического создания пакетных заданий.

Пока все хорошо.

Когда я отрываюсь, обычно каждая задача в этих заданиях довольно трудна для глубокого обучения TensorFlow, поэтому в идеале я бы хотел, чтобы Kubernetes планировал только один модуль на узел, а затем в сочетании с автоматическим масштабированием узла масштабировалдо моего кластера по мере необходимости.

В пакетном режиме Azure для каждого задания вы можете указать задачи для каждой виртуальной машины, аналогично пакетам на узел в Kubernetes.Кажется, что это не поддерживается в API Kubernetes и доступно только через конфигурацию kubelet max pods, которая не идеальна, так как она более жестко запрограммирована, чем хотелось бы.

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

Answer 1

Вы можете использовать правила pod affinity / anti-affinity, чтобы гарантировать, что как только модуль определенного приложения запланирован на одном узле, тогда никакие другие модули того же приложения не запланированы на этом узле.

Копированиепример развертывания Redis с веб-сайта документации :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: redis-cache
spec:
  selector:
    matchLabels:
      app: store
  replicas: 3
  template:
    metadata:
      labels:
        app: store
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - store
            topologyKey: "kubernetes.io/hostname"
      containers:
      - name: redis-server
        image: redis:3.2-alpine

Это гарантирует, что на одном узле работает только один экземпляр кэша Redis.Некоторые ключевые моменты, на которые следует обратить внимание:

1. Метка app=store важна для идентификации приложения

2. Использование метки - имя хоста узласогласовано, чтобы решить планирование: topologyKey: "kubernetes.io/hostname"

3. Экспертиза requiredDuringSchedulingIgnoredDuringExecution гарантирует, что это трудное решение во время планирования и не будет выполнено планирование модуля, если критерии не выполнены.

Проверьте различные варианты планирования здесь для получения более подробной информации.