Служба Azure Kubernetes: Как переместить модули из пула точечных узлов в обычный пул узлов после удаления пула точечных узлов?

#kubernetes #yaml #azure-aks #kubernetes-pod

Вопрос:

У меня всего 3 пула узлов, как показано ниже:

  1. пул баз данных — обычный пул узлов
  2. пул содержимого — обычный пул узлов
  3. пул областей содержимого — пул узлов области

Изначально пул содержимого имеет количество узлов 0 с включенным автомасштабированием. Я развернул одно развертывание модуля nginx в пуле областей содержимого. который имеет минимальное количество узлов 1 и максимальное количество узлов 3. Файл развертывания для nginx выглядит следующим образом:

 apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80
      affinity:
        nodeAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 2
            preference:
              matchExpressions:
              - key: agentpool
                operator: In
                values:
                - contentspotpool
          - weight: 1
            preference:
              matchExpressions:
              - key: agentpool
                operator: In
                values:
                - contentpool
 

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

Кто-нибудь может сказать мне, как я могу этого достичь?..

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

Используемая версия AKS — 1.18.14

Ответ №1:

Я решил предоставить вики-ответ Сообщества, так как был аналогичный ответ, но был удален его автором.

В этом случае вы можете использовать Загрязнения и допуски:

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

Вы можете добавить a taint к узлам из пула баз данных и указать a toleration , который «соответствует» этому taint только для модулей, которые могут быть запланированы в пуле баз данных.


Я создал простой пример, чтобы проиллюстрировать, как это может работать.

У меня есть только один рабочий узел, и я добавил определенный taint для этого узла:

 $ kubectl get nodes
NAME                STATUS   ROLES    AGE     
database-pool       Ready    <none>   6m9s  

$ kubectl taint nodes database-pool type=database:NoSchedule
node/database-pool tainted

$ kubectl describe node database-pool | grep -i taint
Taints:             type=database:NoSchedule
 

Только Pods при toleration условии, что на узле будет разрешено запланировать следующее database-pool :

 tolerations:
- key: "type"
  operator: "Equal"
  value: "database"
  effect: "NoSchedule"
 

Я создал два Pods : web (не терпит taint ) и web-with-toleration (терпит taint ):

 $ cat web.yml
apiVersion: v1
kind: Pod
metadata:
  labels:
    run: web
  name: web
spec:
  containers:
  - image: nginx
    name: web
    
$ cat web-with-toleration.yml
apiVersion: v1
kind: Pod
metadata:
  labels:
    run: web
  name: web-with-toleration
spec:
  containers:
  - image: nginx
    name: web
  tolerations:
  - key: "type"
    operator: "Equal"
    value: "database"
    effect: "NoSchedule"

$ kubectl apply -f web.yml
pod/web created
$ kubectl apply -f web-with-toleration.yml
pod/web-with-toleration created
 

Наконец, мы можем проверить, какой Pod из них был правильно запланирован:

 $ kubectl get pods -o wide
NAME                  READY   STATUS    RESTARTS   AGE     IP           NODE                                         
web                   0/1     Pending   0          6m13s   <none>       <none>                                       
web-with-toleration   1/1     Running   0          6m8s    10.76.0.14   database-pool 
 

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

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