#kubernetes #yaml #azure-aks #kubernetes-pod
Вопрос:
У меня всего 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
на определенных узлах.
Сходство узлов-это свойство модулей, которое привлекает их к набору узлов (либо в качестве предпочтения, либо в качестве жесткого требования). Пятна противоположны-они позволяют узлу отталкивать набор капсул.