From a42723a3093157e20ef06bd73e5bf37a13ca01d7 Mon Sep 17 00:00:00 2001 From: Jeferson Fernando Date: Wed, 24 Jan 2024 14:15:11 +0100 Subject: [PATCH] Refazendo Labels, Taints --- pt/day-12/README.md | 230 ++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 224 insertions(+), 6 deletions(-) diff --git a/pt/day-12/README.md b/pt/day-12/README.md index 4cc35a41..25df20ad 100644 --- a/pt/day-12/README.md +++ b/pt/day-12/README.md @@ -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) @@ -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 61d v1.27.3 -strigus-worker2 Ready 62d v1.27.3 -strigus-worker3 Ready 61d v1.27.3 -strigus-worker4 Ready 62d v1.27.3 +strigus-worker1 Ready 65d v1.27.3 +strigus-worker2 Ready 65d v1.27.3 +strigus-worker3 Ready 65d v1.27.3 +strigus-worker4 Ready 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. @@ -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 +nginx-77b4fdf86c-97r8d 1/1 Running 0 5s 10.244.5.25 strigus-worker4 +nginx-77b4fdf86c-cm96h 1/1 Running 0 5s 10.244.6.30 strigus-worker2 +nginx-77b4fdf86c-rhdmh 1/1 Running 0 5s 10.244.4.29 strigus-worker3 +nginx-77b4fdf86c-ttqzg 1/1 Running 0 5s 10.244.4.30 strigus-worker3 +``` + +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 +nginx-7b68fffb4-d577x 1/1 Running 0 11s 10.244.4.28 strigus-worker3 +nginx-7b68fffb4-g2kxr 1/1 Running 0 11s 10.244.3.10 strigus-worker1 +nginx-7b68fffb4-m5kln 1/1 Running 0 11s 10.244.6.29 strigus-worker2 +nginx-7b68fffb4-n6kck 1/1 Running 0 11s 10.244.3.11 strigus-worker1 +``` + +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 +nginx-5dd89c4b9b-m4fj2 1/1 Running 0 4s 10.244.5.37 strigus-worker4 +nginx-5dd89c4b9b-msnv8 1/1 Running 0 4s 10.244.3.14 strigus-worker1 +nginx-5dd89c4b9b-nlcgs 1/1 Running 0 4s 10.244.5.36 strigus-worker4 +nginx-5dd89c4b9b-trgw7 1/1 Running 0 4s 10.244.3.12 strigus-worker1 +``` + +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 \ No newline at end of file