Skip to content

Commit

Permalink
Refazendo Labels, Taints
Browse files Browse the repository at this point in the history
  • Loading branch information
@badtuxx
badtuxx committed Jan 24, 2024
1 parent 93f8877 commit a42723a
Showing 1 changed file with 224 additions and 6 deletions.
230 changes: 224 additions & 6 deletions pt/day-12/README.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -9,6 +9,8 @@
- [O que vamos ver no dia de hoje?](#o-que-vamos-ver-no-dia-de-hoje)
- [O Nosso cluster de exemplo](#o-nosso-cluster-de-exemplo)
- [O que são Taints?](#o-que-são-taints)
- [O que são Tolerations?](#o-que-são-tolerations)
- [O que são Affinity e Antiaffinity?](#o-que-são-affinity-e-antiaffinity)



Expand All @@ -28,13 +30,13 @@ Para que possamos ter alguns exemplos mais divertido, vamos imaginar que temos u
kubectl get nodes
NAME STATUS ROLES AGE VERSION
strigus-control-plane1 Ready control-plane 65d v1.27.3
strigus-control-plane2 Ready control-plane 61d v1.27.3
strigus-control-plane2 Ready control-plane 65d v1.27.3
strigus-control-plane3 Ready control-plane 65d v1.27.3
strigus-control-plane4 Ready control-plane 65d v1.27.3
strigus-worker1 Ready <none> 61d v1.27.3
strigus-worker2 Ready <none> 62d v1.27.3
strigus-worker3 Ready <none> 61d v1.27.3
strigus-worker4 Ready <none> 62d v1.27.3
strigus-worker1 Ready <none> 65d v1.27.3
strigus-worker2 Ready <none> 65d v1.27.3
strigus-worker3 Ready <none> 65d v1.27.3
strigus-worker4 Ready <none> 65d v1.27.3
```

A nossa missão é criar as Labels e Taints necessárias para que nosso cluster fique organizado, seguro e com alta disponibilidade. E com isso, com alguns ajustes em nossos deployments, garantir que nossos Pods sejam agendados nos Nodes corretos e distribuídos entre os datacenters corretamente.
Expand Down Expand Up @@ -303,5 +305,221 @@ O que vemos na saída do comando é que o Kube-Scheduler agendou os Pods em outr

O Kube-scheduler somente irá agendar novos pods no Node `strigus-worker1` se não houver nenhum outro Node disponível. Simples demais, não?!?

### O que são Tolerations?

Agora que entendemos como os Taints funcionam e como eles influenciam o agendamento de Pods nos Nodes, vamos mergulhar no mundo das Tolerations. As Tolerations são como o "antídoto" para os Taints. Elas permitem que um Pod seja agendado em um Node que possui um Taint específico. Em outras palavras, elas "toleram" as Taints.

Vamos voltar ao nosso cluster da Strigus para entender melhor como isso funciona.

Imagine que temos um workload crítico que precisa ser executado em um Node com GPU. Já marcamos nossos Nodes com GPU com a label `gpu=true`, e agora vamos usar Tolerations para garantir que nosso Pod possa ser agendado nesses Nodes. Isso não faz com que o Pod seja agendado nesses Nodes, mas permite que ele seja agendado nesses Nodes. Entendeu a diferença?

Primeiro, vamos criar um Taint no Node `strigus-worker1`, que possui uma GPU.

```bash
kubectl taint nodes strigus-worker1 gpu=true:NoSchedule
```

Com esse Taint, estamos dizendo que nenhum Pod será agendado nesse Node, a menos que ele tenha uma Toleration específica para a Taint `gpu=true`.

Vamos criar um Deployment com 5 réplicas do Nginx e ver o que acontece.

```bash
kubectl create deployment nginx --image=nginx --replicas=5
```

Agora vamos verificar se os Pods foram criados e se estão em execução.

```bash
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx-77b4fdf86c-274jk 1/1 Running 0 5s 10.244.6.31 strigus-worker2 <none> <none>
nginx-77b4fdf86c-97r8d 1/1 Running 0 5s 10.244.5.25 strigus-worker4 <none> <none>
nginx-77b4fdf86c-cm96h 1/1 Running 0 5s 10.244.6.30 strigus-worker2 <none> <none>
nginx-77b4fdf86c-rhdmh 1/1 Running 0 5s 10.244.4.29 strigus-worker3 <none> <none>
nginx-77b4fdf86c-ttqzg 1/1 Running 0 5s 10.244.4.30 strigus-worker3 <none> <none>
```

Como esperado, nenhum Pod foi agendado no Node `strigus-worker1`, que é o Node que aplicamos o Taint.

Agora, vamos modificar o nosso Deployment do Nginx para que ele tenha uma Toleration para a Taint `gpu=true`.

Para ficar mais fácil, vamos criar um manifesto para o nosso Deployment utilizando o comando `kubectl create deployment nginx --image=nginx --replicas=5 --dry-run=client -o yaml > gpu-deployment.yaml`.

Agora vamos editar o arquivo `gpu-deployment.yaml` e adicionar a Toleration para a Taint `gpu=true`.

```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: nginx
name: nginx
spec:
replicas: 5
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- image: nginx
name: nginx
tolerations:
- key: gpu
operator: Equal
value: "true"
effect: NoSchedule
```
Vamos entender o que adicionamos no arquivo.
```yaml
tolerations:
- key: gpu
operator: Equal
value: "true"
effect: NoSchedule
```
Onde:
- `key` é a chave do Taint que queremos tolerar.
- `operator` é o operador que queremos utilizar. Nesse caso, estamos utilizando o operador `Equal`, que significa que o valor do Taint precisa ser igual ao valor da Toleration.
- `value` é o valor do Taint que queremos tolerar.
- `effect` é o efeito do Taint que queremos tolerar. Nesse caso, estamos utilizando o efeito `NoSchedule`, que significa que o Kubernetes não irá agendar nenhum Pod nesse Node a menos que ele tenha uma Toleration correspondente.

Vamos aplicar esse Deployment e ver o que acontece.

```bash
kubectl apply -f gpu-deployment.yaml
```

Se verificarmos os Pods agora, veremos que o nosso Pod `gpu-pod` está rodando no Node `strigus-worker1`.

```bash
kubectl get pods -o wide
```

A saída mostrará algo como:

```bash
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx-7b68fffb4-czrpt 1/1 Running 0 11s 10.244.5.24 strigus-worker4 <none> <none>
nginx-7b68fffb4-d577x 1/1 Running 0 11s 10.244.4.28 strigus-worker3 <none> <none>
nginx-7b68fffb4-g2kxr 1/1 Running 0 11s 10.244.3.10 strigus-worker1 <none> <none>
nginx-7b68fffb4-m5kln 1/1 Running 0 11s 10.244.6.29 strigus-worker2 <none> <none>
nginx-7b68fffb4-n6kck 1/1 Running 0 11s 10.244.3.11 strigus-worker1 <none> <none>
```

Isso demonstra o poder das Tolerations em combinação com os Taints. Podemos controlar com precisão onde nossos Pods são agendados, garantindo que workloads críticos tenham os recursos que necessitam.

Para remover o Taint do Node `strigus-worker1`, basta usar o comando `kubectl taint nodes strigus-worker1 gpu=true:NoSchedule-`.

Mas lembrando mais uma vez, as Tolerations não fazem com que o Pod seja agendado nesses Nodes, mas permite que ele seja agendado nesses Nodes.

Então, caso você queira garantir que determinado Pod seja executado em determinado Node, você precisa utilizar o conceito de Affinity, que veremos agora.


### O que são Affinity e Antiaffinity?

Affinity e Antiaffinity são conceitos que permitem que você defina regras para o agendamento de Pods em determinados Nodes. Com eles você pode definir regras para que Pods sejam agendados em Nodes específicos, ou até mesmo para que Pods não sejam agendados em Nodes específicos.

Vamos entender como isso funciona na prática.

Você se lembra que adicionamos a label `gpu=true` nos Nodes que possuem GPU? Então, vamos utilizar essa label para garantir que o nosso Pod seja agendado somente neles. Para isso, vamos utilizar o conceito de Affinity.

Vamos criar um Deployment com 5 réplicas do Nginx com a seguinte configuração:

```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: nginx
name: nginx
spec:
replicas: 5
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- image: nginx
name: nginx
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: gpu
operator: In
values:
- "true"
```

Vamos entender o que temos de novo:

```yaml
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: gpu
operator: In
values:
- "true"
```

Onde:

- `affinity` é o início da configuração de Affinity.
- `nodeAffinity` é o conceito de Affinity para Nodes.
- `requiredDuringSchedulingIgnoredDuringExecution` é usado para indicar que o Pod só pode ser agendado em um Node que atenda aos requisitos de Affinity, está falando que essa regra é obrigatória no momento do agendamento do Pod, mas que pode ser ignorada durante a execução do Pod.
- `nodeSelectorTerms` é usado para indicar os termos de seleção de Nodes, que será usado para selecionar os Nodes que atendem aos requisitos de Affinity.
- `matchExpressions` é usado para indicar as expressões de seleção de Nodes, ou seja, o nome da label, o operador e o valor da label.
- `key` é o nome da label que queremos utilizar para selecionar os Nodes.
- `operator` é o operador que queremos utilizar. Nesse caso, estamos utilizando o operador `In`, que significa que o valor da label precisa estar dentro dos valores que estamos informando.
- `values` é o valor da label que queremos utilizar para selecionar os Nodes.

Sendo assim, estamos falando para o Kubernetes que o nosso Pod só pode ser agendado em um Node que tenha a label `gpu=true`. Simples assim!

Vamos aplicar esse Deployment e ver o que acontece.

```bash
kubectl apply -f gpu-deployment.yaml
```

Se verificarmos os Pods agora, veremos que os nossos Pods estão rodando somente nos Nodes que possuem a label `gpu=true`.

```bash
kubectl get pods -o wide
```

A saída mostrará algo como:

```bash
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx-5dd89c4b9b-hwzcx 1/1 Running 0 4s 10.244.3.13 strigus-worker1 <none> <none>
nginx-5dd89c4b9b-m4fj2 1/1 Running 0 4s 10.244.5.37 strigus-worker4 <none> <none>
nginx-5dd89c4b9b-msnv8 1/1 Running 0 4s 10.244.3.14 strigus-worker1 <none> <none>
nginx-5dd89c4b9b-nlcgs 1/1 Running 0 4s 10.244.5.36 strigus-worker4 <none> <none>
nginx-5dd89c4b9b-trgw7 1/1 Running 0 4s 10.244.3.12 strigus-worker1 <none> <none>
```

Isso demonstra o poder do Affinity. Podemos controlar com precisão onde nossos Pods são agendados, garantindo que workloads críticos tenham os recursos que necessitam. Sensacional demais!

Agora vamos entender o conceito de Antiaffinity.


TBD




TBD

0 comments on commit a42723a

Please sign in to comment.