Kubernetes. Taints and Tolerations. Запуск подов на мастере.

При первых опытах с Kubernetes возникает проблема, когда Вы разворачиваете одну или несколько нод-мастеров в кластере, служебные поды запускаются и работают, но при попытки развернуть pod с каким-либо сервисом, он зависает в статусе Pending и мы получаем ошибку: «0/1 nodes are available: 1 node(s) had taints that the pod didn’t tolerate.»

И так, что мы имеем?

Есть кластер, с одной нодой:

# kubectl get nodes
NAME           STATUS   ROLES    AGE   VERSION
k8s-master-1   Ready    master   16h   v1.16.3

Служебные поды работают:

# kubectl get po -n kube-system
NAME                                   READY   STATUS    RESTARTS   AGE
coredns-5644d7b6d9-bqsfm               1/1     Running   0          16h
coredns-5644d7b6d9-h5rr5               1/1     Running   0          16h
etcd-k8s-master-1                      1/1     Running   0          16h
kube-apiserver-k8s-master-1            1/1     Running   0          16h
kube-controller-manager-k8s-master-1   1/1     Running   0          16h
kube-flannel-ds-amd64-nmszk            1/1     Running   0          16h
kube-proxy-sw84w                       1/1     Running   0          16h
kube-scheduler-k8s-master-1            1/1     Running   0          16h

Однако же поды которые вы создаете сами остаются в статусе Pending:

# kubectl get po
NAME          READY   STATUS    RESTARTS   AGE
kubia-b2cgm   0/1     Pending   0          15h

Смотрим состояние пода:

# kubectl describe po kubia-b2cgm 
...
Type     Reason            Age                From               Message
----     ------            ----               ----               -------
Warning  FailedScheduling  51s (x15 over 3m)  default-scheduler  0/1 nodes are available: 1 node(s) had taints that the pod didn't tolerate.

В чем же дело?

Ответ на этот вопрос изложен в официальной документации в статье «Taints and Tolerations».

Вкратце, в Kubernetes реализована политика разграничение ролей узлов кластера, ограничивающая установку тех или иных подов на «зараженные» поды.

Как быть, что делать?

Первый делом проверяем свойство ноды на предмет наличия установленной политики:

# kubectl describe nodes k8s-master-1 |grep Taints
...
Taints:             node-role.kubernetes.io/master:NoSchedule
...

Согласно вышеупомянутой документации, мы можем сделать вывод, что нода k8s-master-1 в статусе master:NoSchedule

Это означает, что ни один под не сможет планировать развертывание на узел k8s-master-1, если у него нет соответствующего допуска.

И тут у нас есть два варианта развития событий:
— Предоставить соответствующий допуск самому поду.
— Отключить эту политику для данного узла.

Вариант 1. Выдать допуск поду.

В манифесте указываем допуск:

tolerations:
- key: node-role.kubernetes.io/master
  operator: "Exists"
  effect: NoSchedule 

Пример создание Replication Controller для подов с допуском:

apiVersion: v1
kind: ReplicationController
metadata:
  name: kubia
spec:
  replicas: 3
  selector:
    app: kubia
  template:
    metadata:
      labels:
        app: kubia
    spec:
      containers:
      - name: kubia
        image: luksa/kubia
        ports:
        - containerPort: 8080
      tolerations:
      - key: node-role.kubernetes.io/master
        operator: "Exists"
        effect: NoSchedule 

Этот способ подходи только в том случае, если Вы выносите самописные поды. При установки подов с помощью Helm нужно указывать tolerations отдельным ключом.

Вариант 2. Отключить политику в Taints.

Отключаем политику на ноде k8s-master-1:

# kubectl taint nodes k8s-master-1 node-role.kubernetes.io/master- 

Проверяем состояние ноды:

# kubectl describe nodes k8s-master-1 |grep Taints
...
Taints:             <none>
...

Данный способ более универсальный и не привязывает нас к модификациям манифестов.

Первоисточник:
— статья «Taints and Tolerations».
— Книга «Kubernetes в действии» автор Лукша Марко.

0

Добавить комментарий

Ваш e-mail не будет опубликован.