Как обеспечить, чтобы на моем узле в GKE работал только один модуль? - PullRequest
2 голосов
/ 08 марта 2019

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

Что я хочу знать, так это как я могу запретить kubernetes планироватьнесколько экземпляров моего модуля на одном узле?Я хочу избежать этого, так как хочу, чтобы мой модуль мог использовать как можно больше ресурсов ЦП, и я также не хочу, чтобы несколько модулей взаимодействовали через локальный ssd.

Как предотвратить планирование большего количества модулей?чем один стручок моего типа на узел?Сначала я думал о наборах демонов, но я думаю, что в дальнейшем я хочу установить пул узлов на автоматическое масштабирование. Таким образом, когда в моем пуле n узлов и я запрашиваю n + 1 реплик, пул узлов автоматически масштабируется.до.

Ответы [ 3 ]

1 голос
/ 09 марта 2019

Вы можете использовать Daemonsets в сочетании с nodeSelector или affinity.В качестве альтернативы вы можете настроить podAntiAffinity на Pod с, например:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: rest-server
spec:
  selector:
    matchLabels:
      app: rest-server
  replicas: 3
  template:
    metadata:
      labels:
        app: rest-server
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - rest-server
            topologyKey: "kubernetes.io/hostname"
      containers:
      - name: rest-server
        image: nginx:1.12-alpine
1 голос
/ 15 марта 2019

В зависимости от того, чего вы пытаетесь достичь, DaemonSets может быть не полным ответом, потому что DaemonSet НЕ масштабируется автоматически, и он только поместит модуль в новый узел; когда вы добавляете новые узлы в свой пул.

Если вы хотите изменить свою рабочую нагрузку с помощью n + 1 реплик, лучше использовать podAntiAffinity , , управляющий расписанием с портами узлов и кластером autoscaler ; это гарантирует, что новый узел будет добавлен при увеличении ваших модулей и удален при уменьшении количества ваших модулей:

apiVersion: v1
kind: ReplicationController
metadata:
 name: echoheaders
spec:
 replicas: 1
 template:
   metadata:
     labels:
       app: echoheaders
   spec:
     affinity:
       podAntiAffinity:
         requiredDuringSchedulingIgnoredDuringExecution:
         - labelSelector:
             matchExpressions:
             - key: app
               operator: In
               values:
               - echoheaders
           topologyKey: "kubernetes.io/hostname"
     containers:
     - name: echoheaders
       image: k8s.gcr.io/echoserver:1.4
       ports:
       - containerPort: 8080
     tolerations:
     - key: dedicated
       operator: Equal
       value: experimental
       effect: NoSchedule
0 голосов
/ 08 марта 2019

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

1.Ограничение количества планируемых модулей на узел

Вы можете установить это ограничение при создании нового кластера, однако оно будет ограничено, если позже вы передумаете.Найдите следующее поле в дополнительных настройках при создании кластера.

enter image description here

2.Присвоение pod конкретному узлу и занятие всех ресурсов

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...