Embora haja uma pequena diferente, eu gosto da explicação do Google sobre a questão dos node taints. No Kubernetes quando você envia uma carga de trabalho para ser executada em um cluster, o scheduler determina onde colocar os pods associados à essa carga de trabalho. O scheduler é livre para colocar um pod em qualquer node que satisfaça os requisitos de recursos personalizados de CPU e de RAM do pod. Se o cluster executa várias cargas de trabalho, convém exercer um controle sobre quais cargas de trabalho podem ser executadas em um pool de nodes em particular.
Com um node taint você marca um node para que o scheduler do kubernetes evite ou impeça o uso dele em determinados pods. Com o recurso adicional de tolerations; que permite designar pods para serem usados em nodes tainted ou contaminados, você designa pods que podem ser usados em nodes com taints.
Node taints são pares de chave e valor associados a um effect (efeito). Aqui estão os effects disponÃveis no Kubernetes:
NoSchedulePreferNoScheduleNoExecute
| Name | Concept |
|---|---|
| Afinidade de nó | É uma propriedade dos Pods que os associa a um conjunto de nós (seja como uma preferência ou uma exigência). Taints são o oposto -- eles permitem que um nó repudie um conjunto de pods. |
| Tolerâncias | São aplicadas em pods e permitem, mas não exigem, que os pods sejam alocados em nós com taints correspondentes. |
| Taints e tolerâncias | Trabalham juntos para garantir que pods não sejam alocados em nós inapropriados. Um ou mais taints são aplicados em um nó; isso define que o nó não deve aceitar nenhum pod que não tolera essas taints. |
Kubernetes taints e tolerations permitem que você crie nós especiais que são reservados para usos especÃficos ou apenas execute processos especÃficos (pods) que correspondem ao nó. Você pode querer manter as cargas de trabalho desligadas ou seus nós de gerenciamento e nós de contaminação do Kubernetes para que nenhum pod de carga de trabalho tenha tolerâncias correspondentes, evitando que sejam programados para esses nós. Você pode ter nós com hardware especializado para trabalhos especÃficos (por exemplo, GPUs) e contaminar esses nós pode reservá-lo para que os Pods que precisam especificamente desse tipo de recurso possam ser programados para esses nós quando necessário.
Portanto dizemos que no Kubernetes, node taints e tolerations funcionam de maneira semelhante as regras de afinidade de nó, embora adotam em sua execução uma abordagem quase oposta.
Regras de afinidade são definidas para pods para atraÃ-los para nós especÃficos. Um node taint repele pods que não têm tolerância para o conjuto de nodes.
Juntos, taints e tolerations garantem que os pods não sejam programados em nodes inadequados. Uma contaminação produz três efeitos possÃveis, como comentado acima. Esses efeitos são:
NoSchedule: O Kubernetes só agendará pods que toleram o taint - contaminação - do nodePreferNoSchedule: O Kubernetes evitará agendar pods não tolerantes nos nós, mas ainda pode fazer issoNoExecute: O Kubernetes removerá todos os pods não tolerantes em execução que já estejam em execução em um nó contaminado
Pods que não toleram essa contaminação (esse Taint) não são programados no Node. Os Pods atuais não são removidos do Node.
O Kubernetes não programará o pod se pelo menos um contaminação não tolerado tiver um efeito NoSchedule .
O Kubernetes evita o agendamento de Pods que não toleram essa contaminação (esse Taint) no Node. Este basicamente significa: faça, mas só se possÃvel.
Podemos dizer que simplesmente significa que tentará evitar o agendamento do Pod naquele Node, mas isso pode acontecer às vezes (por exemplo, se todos os outros Nodes estiverem cheios).
O Kubernetes tentará não programar o pod no nó se pelo menos uma mancha não tolerada tiver um efeito PreferNoSchedule.
o Pod é removido do Node caso já esteja em execução nele e não é programado no Node caso ainda não esteja em execução nele.
Um contaminação NoExecute fará com que o Kubernetes despeje o pod se ele estiver em execução no nó ou não programará o pod do nó.
Observe que a diferente entre NoSchedule e NoExecute é que o primeiro ele não agendará um Pod, mas se estiver em execução, não o matará. Com o último, ele irá matar o Pod e reprogramar em outro Node.
Alguns pods do sistema (por exemplo, kube-proxy e fluentd) toleram todos os taints NoExecute e NoSchedule e não serão removidos.
## Node labels for pod assignment
## Ref: https://kubernetes.io/docs/user-guide/node-selection/
#
nodeSelector:
# Example: The gitlab runner manager should not run on spot instances so you can assign
# them to the regular worker nodes only.
# node-role.kubernetes.io/worker: "true"
dedicated: "performance"
## List of node taints to tolerate (requires Kubernetes >= 1.6)
## Ref: https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/
#
tolerations:
# Example: Regular worker nodes may have a taint, thus you need to tolerate the taint
# when you assign the gitlab runner manager with nodeSelector or affinity to the nodes.
# - key: "dedicated"
# operator: "Equal"
# value: "gitlab-runner"
# effect: "NoExecute"
- key: "dedicated"
operator: "Equal"
value: "performance"
effect: "NoExecute"$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
ip-192-168-10-19.ec2.internal Ready <none> 3h21m v1.14.7-eks-1861c5
ip-192-168-10-194.ec2.internal Ready <none> 3h23m v1.14.7-eks-1861c5
ip-192-168-34-39.ec2.internal Ready <none> 11d v1.14.7-eks-1861c5
ip-192-168-35-131.ec2.internal Ready <none> 170m v1.14.7-eks-1861c5
ip-192-168-37-55.ec2.internal Ready <none> 4h27m v1.14.7-eks-1861c5
ip-192-168-60-43.ec2.internal Ready <none> 4h35m v1.14.7-eks-1861c5
ip-192-168-63-146.ec2.internal Ready <none> 3h22m v1.14.7-eks-1861c5
$ kubectl taint nodes ip-192-168-38-136.ec2.internal dedicated=gitlab:NoExecute
node/ip-192-168-38-136.ec2.internal tainted
$ kubectl taint nodes ip-192-168-38-136.ec2.internal dedicated=gitlab:NoExecute-
node/ip-192-168-38-136.ec2.internal untainted
$ kubectl taint nodes ip-192-168-38-136.ec2.internal dedicated=gitlab-runner:NoExecute