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

У меня есть развертывание 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

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

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

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

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

kubernetes,google-cloud-platform,

10

Ответов: 5

голосование 6 голосов принято

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

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

голосование 8 голосов

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

Такое поведение исходит от Планировщика, оно предоставляется на максимальной основе, при условии, что у вас достаточно ресурсов на обоих узлах.

Соответствующий раздел в документации: Рекомендации по настройке - Сервис

1

Я согласен с Антуаном Коттеном в использовании службы для развертывания. Служба всегда сохраняет какое-либо обслуживание, создавая новый модуль, если по какой-то причине один модуль умирает в определенном узле. Однако, если вы просто хотите распространять развертывание среди всех узлов, вы можете использовать анти-сродство pod в файле манифеста pod. Я привел пример на странице 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

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

0

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

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

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

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

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

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

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

gubernets google-cloud-platform
Похожие вопросы
Яндекс.Метрика