Skip to content

Commit 7bf9754

Browse files
authored
Merge pull request #20460 from viniciusbds/translate-scheduling-topic-ptbr
Add content/pt/docs/concepts/scheduling/kube-scheduler.md
2 parents 7d05b90 + dea0dec commit 7bf9754

File tree

6 files changed

+163
-0
lines changed

6 files changed

+163
-0
lines changed
Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,5 @@
1+
---
2+
title: "Escalonamento"
3+
weight: 90
4+
---
5+
Lines changed: 93 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,93 @@
1+
---
2+
title: Escalonador do Kubernetes
3+
date: 2020-04-19
4+
content_template: templates/concept
5+
weight: 50
6+
---
7+
8+
{{% capture overview %}}
9+
10+
No Kubernetes, _escalonamento_ refere-se a garantir que os {{< glossary_tooltip text="Pods" term_id="pod" >}}
11+
sejam correspondidos aos {{< glossary_tooltip text="Nodes" term_id="node" >}} para que o
12+
{{< glossary_tooltip text="Kubelet" term_id="kubelet" >}} possa executá-los.
13+
14+
{{% /capture %}}
15+
16+
{{% capture body %}}
17+
18+
## Visão geral do Escalonamento {#escalonamento}
19+
20+
Um escalonador observa Pods recém-criados que não possuem um Node atribuído.
21+
Para cada Pod que o escalonador descobre, ele se torna responsável por
22+
encontrar o melhor Node para execução do Pod. O escalonador chega a essa decisão de alocação levando em consideração os princípios de programação descritos abaixo.
23+
24+
Se você quiser entender por que os Pods são alocados em um Node específico
25+
ou se planeja implementar um escalonador personalizado, esta página ajudará você a
26+
aprender sobre escalonamento.
27+
28+
## kube-scheduler
29+
30+
[kube-scheduler](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-scheduler/)
31+
é o escalonador padrão do Kubernetes e é executado como parte do
32+
{{< glossary_tooltip text="control plane" term_id="control-plane" >}}.
33+
O kube-scheduler é projetado para que, se você quiser e precisar, possa
34+
escrever seu próprio componente de escalonamento e usá-lo.
35+
36+
Para cada Pod recém-criado ou outros Pods não escalonados, o kube-scheduler
37+
seleciona um Node ideal para execução. No entanto, todos os contêineres nos Pods
38+
têm requisitos diferentes de recursos e cada Pod também possui requisitos diferentes.
39+
Portanto, os Nodes existentes precisam ser filtrados de acordo com os requisitos de
40+
escalonamento específicos.
41+
42+
Em um cluster, Nodes que atendem aos requisitos de escalonamento para um Pod
43+
são chamados de Nodes _viáveis_. Se nenhum dos Nodes for adequado, o Pod
44+
permanece não escalonado até que o escalonador possa alocá-lo.
45+
46+
O escalonador encontra Nodes viáveis para um Pod e, em seguida, executa um conjunto de
47+
funções para pontuar os Nodes viáveis e escolhe um Node com a maior
48+
pontuação entre os possíveis para executar o Pod. O escalonador então notifica
49+
o servidor da API sobre essa decisão em um processo chamado _binding_.
50+
51+
Fatores que precisam ser levados em consideração para decisões de escalonamento incluem
52+
requisitos individuais e coletivos de recursos,
53+
restrições de hardware / software / política, especificações de afinidade e anti-afinidade,
54+
localidade de dados, interferência entre cargas de trabalho e assim por diante.
55+
56+
### Seleção do Node no kube-scheduler {#implementação-kube-scheduler}
57+
58+
O kube-scheduler seleciona um Node para o Pod em uma operação que consiste em duas etapas:
59+
60+
1. Filtragem
61+
1. Pontuação
62+
63+
A etapa de _filtragem_ localiza o conjunto de Nodes onde é possível
64+
alocar o Pod. Por exemplo, o filtro PodFitsResources verifica se um Node
65+
candidato possui recursos disponíveis suficientes para atender às solicitações
66+
de recursos específicas de um Pod. Após esta etapa, a lista de Nodes contém
67+
quaisquer Nodes adequados; frequentemente, haverá mais de um. Se a lista estiver vazia,
68+
esse Pod (ainda) não é escalonável.
69+
70+
Na etapa de _pontuação_, o escalonador classifica os Nodes restantes para escolher
71+
o mais adequado. O escalonador atribui uma pontuação a cada Node
72+
que sobreviveu à filtragem, baseando essa pontuação nas regras de pontuação ativa.
73+
74+
Por fim, o kube-scheduler atribui o Pod ao Node com a classificação mais alta.
75+
Se houver mais de um Node com pontuações iguais, o kube-scheduler seleciona
76+
um deles aleatoriamente.
77+
78+
Existem duas maneiras suportadas de configurar o comportamento de filtragem e pontuação
79+
do escalonador:
80+
81+
1. [Políticas de Escalonamento](/docs/reference/scheduling/policies) permitem configurar _Predicados_ para filtragem e _Prioridades_ para pontuação.
82+
83+
1. [Perfis de Escalonamento](/docs/reference/scheduling/profiles) permitem configurar Plugins que implementam diferentes estágios de escalonamento, incluindo: `QueueSort`, `Filter`, `Score`, `Bind`, `Reserve`, `Permit`, e outros. Você também pode configurar o kube-scheduler para executar diferentes perfis.
84+
85+
{{% /capture %}}
86+
{{% capture whatsnext %}}
87+
* Leia sobre [ajuste de desempenho do escalonador](/docs/concepts/scheduling/scheduler-perf-tuning/)
88+
* Leia sobre [restrições de propagação da topologia de pod](/docs/concepts/workloads/pods/pod-topology-spread-constraints/)
89+
* Leia a [documentação de referência](/docs/reference/command-line-tools-reference/kube-scheduler/) para o kube-scheduler
90+
* Aprenda como [configurar vários escalonadores](/docs/tasks/administer-cluster/configure-multiple-schedulers/)
91+
* Aprenda sobre [políticas de gerenciamento de topologia](/docs/tasks/administer-cluster/topology-manager/)
92+
* Aprenda sobre [Pod Overhead](/docs/concepts/configuration/pod-overhead/)
93+
{{% /capture %}}
Lines changed: 13 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,13 @@
1+
---
2+
title: Control Plane
3+
id: control-plane
4+
date: 2020-04-19
5+
full_link:
6+
short_description: >
7+
A camada de orquestração de contêiner que expõe a API e as interfaces para definir, implantar e gerenciar o ciclo de vida dos contêineres.
8+
9+
aka:
10+
tags:
11+
- fundamental
12+
---
13+
A camada de orquestração de contêiner que expõe a API e as interfaces para definir, implantar e gerenciar o ciclo de vida dos contêineres.
Lines changed: 18 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,18 @@
1+
---
2+
title: Kubelet
3+
id: kubelet
4+
date: 2020-04-19
5+
full_link: /docs/reference/generated/kubelet
6+
short_description: >
7+
Um agente que é executado em cada node no cluster. Ele garante que os contêineres estejam sendo executados em um pod.
8+
9+
aka:
10+
tags:
11+
- fundamental
12+
- core-object
13+
---
14+
Um agente que é executado em cada {{< glossary_tooltip text="node" term_id="node" >}} no cluster. Ele garante que os {{< glossary_tooltip text="contêineres" term_id="container" >}} estejam sendo executados em um {{< glossary_tooltip text="Pod" term_id="pod" >}}.
15+
16+
<!--more-->
17+
18+
O kubelet utiliza um conjunto de PodSpecs que são fornecidos por vários mecanismos e garante que os contêineres descritos nesses PodSpecs estejam funcionando corretamente. O kubelet não gerencia contêineres que não foram criados pelo Kubernetes.
Lines changed: 17 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,17 @@
1+
---
2+
title: Node
3+
id: node
4+
date: 2020-04-19
5+
full_link: /docs/concepts/architecture/nodes/
6+
short_description: >
7+
Um Node é uma máquina de trabalho no Kubernetes.
8+
9+
aka:
10+
tags:
11+
- fundamental
12+
---
13+
Um Node é uma máquina de trabalho no Kubernetes.
14+
15+
<!--more-->
16+
17+
Um Node pode ser uma máquina virtual ou física, dependendo do cluster. Possui daemons ou serviços locais necessários para executar {{< glossary_tooltip text="Pods" term_id="pod" >}} e é gerenciado pelo {{< glossary_tooltip text="plano de controle" term_id="control-plane" >}}. Os daemons em um Node incluem {{< glossary_tooltip text="kubelet" term_id="kubelet" >}}, {{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}} e um contêiner runtime implementando o {{< glossary_tooltip text="CRI" term_id="cri" >}} como por exemplo o {{< glossary_tooltip term_id="docker" >}}.
Lines changed: 17 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,17 @@
1+
---
2+
title: Pod
3+
id: pod
4+
date: 2020-04-19
5+
full_link: /docs/concepts/workloads/pods/pod-overview/
6+
short_description: >
7+
O menor e mais simples objeto Kubernetes. Um Pod representa um conjunto de contêineres em execução no seu cluster.
8+
aka:
9+
tags:
10+
- core-object
11+
- fundamental
12+
---
13+
O menor e mais simples objeto Kubernetes. Um Pod representa um conjunto de {{< glossary_tooltip text="contêineres" term_id="container" >}} em execução no seu cluster.
14+
15+
<!--more-->
16+
17+
Um Pod é normalmente configurado para executar um único contêiner primário. Ele também pode executar contêineres opcionais que adicionam recursos adicionais, como registro em log. Os pods são geralmente gerenciados por um {{< glossary_tooltip term_id="deployment" >}}.

0 commit comments

Comments
 (0)