Как распределить развертывание по узлам?

У меня есть развертывание Kubernetes, которое выглядит примерно так (заменили имена и другие вещи на "...." ):

# Please edit the object below. Lines beginning with a '#' will be ignored,
# and an empty file will abort the edit. If an error occurs while saving this file will be
# reopened with the relevant failures.
#
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  annotations:
    deployment.kubernetes.io/revision: "3"
    kubernetes.io/change-cause: kubectl replace deployment ....
      -f - --record
  creationTimestamp: 2016-08-20T03:46:28Z
  generation: 8
  labels:
    app: ....
  name: ....
  namespace: default
  resourceVersion: "369219"
  selfLink: /apis/extensions/v1beta1/namespaces/default/deployments/....
  uid: aceb2a9e-6688-11e6-b5fc-42010af000c1
spec:
  replicas: 2
  selector:
    matchLabels:
      app: ....
  strategy:
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
    type: RollingUpdate
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: ....
    spec:
      containers:
      - image: gcr.io/..../....:0.2.1
        imagePullPolicy: IfNotPresent
        name: ....
        ports:
        - containerPort: 8080
          protocol: TCP
        resources:
          requests:
            cpu: "0"
        terminationMessagePath: /dev/termination-log
      dnsPolicy: ClusterFirst
      restartPolicy: Always
      securityContext: {}
      terminationGracePeriodSeconds: 30
status:
  availableReplicas: 2
  observedGeneration: 8
  replicas: 2
  updatedReplicas: 2

Проблема, которую я наблюдаю, заключается в том, что Кубернетес помещает обе реплики (в развертывании, о котором я просил два) на том же node. Если этот node падает, я теряю оба контейнера, и служба отключается.

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

Есть ли способ сказать Кубернету, сколько избыточности для узлов, которые я хочу для контейнера?

EDIT: Я не уверен, что ярлыки будут работать; ярлыки ограничивают, где будет выполняться node, чтобы он имел доступ к локальным ресурсам (SSD) и т.д. Все, что я хочу сделать, это обеспечить отсутствие простоя, если node отключен.

Ответ 1

Я думаю, что вы ищете селекторы Affinity/Anti-Affinity.

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

Итак, для того, что вы делаете, я бы поближе взглянул на эти две ссылки: https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#never-co-located-in-the- тот же узел

https://kubernetes.io/docs/tutorials/stateful-application/zookeeper/#tolerating-node-failure

Ответ 2

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

Из документации Kubernetes (Управление ресурсами):

Лучше всего сначала указать службу, поскольку это позволит планировщику распределять модули, связанные с этой службой, по мере того, как они создаются контроллером (ами), такими как Deployment.

Также связано: Рекомендации по настройке - Сервис.

Ответ 3

Я согласен с Антуаном Коттеном использовать сервис для вашего развертывания. Служба всегда поддерживает любую службу, создавая новый модуль, если по какой-то причине один модуль умирает в определенном узле. Однако, если вы просто хотите распределить развертывание по всем узлам, вы можете использовать pod anti affinity в вашем файле pod manifest. Я разместил пример на своей странице gitlab, которую вы также можете найти в блоге Kubernetes. Для вашего удобства я также привожу здесь пример.

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 2
  template:
    metadata:
      labels:
        app: nginx
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - nginx
              topologyKey: kubernetes.io/hostname
      containers:
      - name: nginx
        image: gcr.io/google_containers/nginx-slim:0.8
        ports:
        - containerPort: 80

В этом примере у каждого Развертывания есть метка, которая является приложением, и значение этой метки - nginx. В спецификации pod у вас есть podAntiAffinity, который будет ограничен двумя одинаковыми модулями (label app: nginx) в одном узле. Вы также можете использовать podAffinity, если хотите разместить несколько развертываний в одном узле.

Ответ 4

Если сбой node, все запущенные на нем контейнеры будут перезагружены автоматически на другом node.

Если вы начнете указывать, где именно вы хотите их запустить, вы фактически потеряете способность Кубернеса перенести их на другой node.

Таким образом, обычная практика заключается в том, чтобы просто позволить Кубернетам сделать свое дело.

Если у вас есть действительные требования для запуска модуля на конкретном node, из-за требований к определенному типу локального тома и т.д., прочитайте:

http://kubernetes.io/docs/user-guide/node-selection/

Ответ 5

Возможно, DaemonSet будет работать лучше. Я использую DaemonStets с nodeSelector, чтобы запускать контейнеры на определенных узлах и избегать дублирования.

http://kubernetes.io/docs/admin/daemons/