Введение
Taints и tolerations используются в Kubernetes для указания, какие узлы подходят для планирования определенных подов. Taints применяются к узлам, чтобы отклонить поды, в то время как tolerations применяются к подам, чтобы привлечь их к определенным узлам. В этом лабораторном занятии (LabEx) мы научимся использовать taints и tolerations для планирования подов на определенных узлах.
Запустите кластер Minikube
Перед созданием ресурсов вам нужен работающий кластер Kubernetes. Minikube - это легковесная среда Kubernetes, которая запускается на вашем локальном компьютере.
Перейдите в рабочую директорию:
Откройте терминал и перейдите в папку проекта по умолчанию:
cd /home/labex/projectЗапустите Minikube:
Запустите Minikube для инициализации кластера Kubernetes:
minikube start- Эта команда настраивает однокузловой кластер Kubernetes на вашем локальном компьютере.
- В зависимости от производительности вашей системы Minikube может потребовать несколько минут на запуск.
Проверьте, что Minikube запущен:
Проверьте статус кластера Minikube:
minikube status- Проверьте, чтобы компоненты, такие как
kubeletиapiserver, были перечислены какRunning(работающие). - Если кластер не запущен, запустите команду
minikube startснова.
- Проверьте, чтобы компоненты, такие как
Если у вас возникли проблемы при запуске Minikube, используйте minikube delete для сброса среды при необходимости.
Создание узла с taint
На этом шаге мы создадим узел с taint, который отклонит определенные поды.
- Пометьте узел пользовательской меткой (label):
kubectl label nodes minikube disk-type=ssd
- Примените taint к узлу с помощью следующей команды:
kubectl taint nodes minikube disk-type=ssd:NoSchedule
Эффект NoSchedule препятствует планированию подов без tolerations на этом узле.
Создание пода без tolerations
На этом шаге мы создадим под без tolerations и проверим, что он не может быть запланирован на узле с taint.
- Создайте файл с именем
pod-without-toleration.yamlсо следующим содержимым:
apiVersion: v1
kind: Pod
metadata:
name: pod-without-toleration
spec:
containers:
- name: nginx
image: nginx:latest
- Примените изменения:
kubectl apply -f pod-without-toleration.yaml
- Проверьте, что под не запланирован на узле с taint:
kubectl describe pod pod-without-toleration | grep -i taint
В выводе должно быть показано, что под не запланирован на узле с taint.
Создание пода с tolerations
На этом шаге мы создадим под с tolerations, которые позволят ему быть запланированным на узле с taint.
- Создайте файл с именем
pod-with-toleration.yamlсо следующим содержимым:
apiVersion: v1
kind: Pod
metadata:
name: pod-with-toleration
spec:
containers:
- name: nginx
image: nginx:latest
tolerations:
- key: "disk-type"
operator: "Equal"
value: "ssd"
effect: "NoSchedule"
- Примените изменения:
kubectl apply -f pod-with-toleration.yaml
- Проверьте, что под запланирован на узле с taint:
kubectl get pod pod-with-toleration -o wide
Поддержка нескольких taint
На этом шаге мы создадим под с несколькими tolerations, которые позволят ему быть запланированным на узлах с несколькими taint.
- Создайте файл с именем
pod-with-multiple-tolerations.yamlсо следующим содержимым:
apiVersion: v1
kind: Pod
metadata:
name: pod-with-multiple-tolerations
spec:
containers:
- name: nginx
image: nginx:latest
tolerations:
- key: "disk-type"
operator: "Equal"
value: "ssd"
effect: "NoSchedule"
- key: "gpu"
operator: "Equal"
value: "true"
effect: "NoSchedule"
- Примените изменения:
kubectl apply -f pod-with-multiple-tolerations.yaml
- Проверьте, что под запланирован на узле с обоими taint:
kubectl get pod pod-with-multiple-tolerations -o wide
Резюме
В этом практическом занятии (lab) мы научились использовать taint и tolerations для планирования подов на определенных узлах. Мы начали с создания узла с taint и проверили, что поды без tolerations не могут быть запланированы на нем. Затем мы создали под с tolerations и проверили, что он может быть запланирован на узле с taint. Наконец, мы создали под с несколькими tolerations и проверили, что он может быть запланирован на узлах с несколькими taint.
Taint и tolerations - это мощная функция Kubernetes, которая может быть использована для обеспечения того, чтобы определенные рабочие нагрузки (workloads) были запланированы только на определенных узлах.


