diff --git a/content/pt/docs/concepts/scheduling/_index.md b/content/pt/docs/concepts/scheduling/_index.md
new file mode 100644
index 0000000000..577dbb8c87
--- /dev/null
+++ b/content/pt/docs/concepts/scheduling/_index.md
@@ -0,0 +1,5 @@
+---
+title: "Escalonamento"
+weight: 90
+---
+
diff --git a/content/pt/docs/concepts/scheduling/kube-scheduler.md b/content/pt/docs/concepts/scheduling/kube-scheduler.md
new file mode 100644
index 0000000000..b822c04932
--- /dev/null
+++ b/content/pt/docs/concepts/scheduling/kube-scheduler.md
@@ -0,0 +1,93 @@
+---
+title: Escalonador do Kubernetes
+date: 2020-04-19
+content_template: templates/concept
+weight: 50
+---
+
+{{% capture overview %}}
+
+No Kubernetes, _escalonamento_ refere-se a garantir que os {{< glossary_tooltip text="Pods" term_id="pod" >}}
+sejam correspondidos aos {{< glossary_tooltip text="Nodes" term_id="node" >}} para que o
+{{< glossary_tooltip text="Kubelet" term_id="kubelet" >}} possa executá-los.
+
+{{% /capture %}}
+
+{{% capture body %}}
+
+## Visão geral do Escalonamento {#escalonamento}
+
+Um escalonador observa Pods recém-criados que não possuem um Node atribuído. 
+Para cada Pod que o escalonador descobre, ele se torna responsável por 
+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.
+
+Se você quiser entender por que os Pods são alocados em um Node específico 
+ou se planeja implementar um escalonador personalizado, esta página ajudará você a 
+aprender sobre escalonamento.
+
+## kube-scheduler
+
+[kube-scheduler](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-scheduler/)
+é o escalonador padrão do Kubernetes e é executado como parte do 
+{{< glossary_tooltip text="control plane" term_id="control-plane" >}}.
+O kube-scheduler é projetado para que, se você quiser e precisar, possa
+escrever seu próprio componente de escalonamento e usá-lo.
+
+Para cada Pod recém-criado ou outros Pods não escalonados, o kube-scheduler 
+seleciona um Node ideal para execução. No entanto, todos os contêineres nos Pods 
+têm requisitos diferentes de recursos e cada Pod também possui requisitos diferentes. 
+Portanto, os Nodes existentes precisam ser filtrados de acordo com os requisitos de 
+escalonamento específicos.
+
+Em um cluster, Nodes que atendem aos requisitos de escalonamento para um Pod
+são chamados de Nodes _viáveis_. Se nenhum dos Nodes for adequado, o Pod
+permanece não escalonado até que o escalonador possa alocá-lo.
+
+O escalonador encontra Nodes viáveis para um Pod e, em seguida, executa um conjunto de
+funções para pontuar os Nodes viáveis e escolhe um Node com a maior
+pontuação entre os possíveis para executar o Pod. O escalonador então notifica
+o servidor da API sobre essa decisão em um processo chamado _binding_.
+
+Fatores que precisam ser levados em consideração para decisões de escalonamento incluem
+requisitos individuais e coletivos de recursos,
+restrições de hardware / software / política, especificações de afinidade e anti-afinidade,
+localidade de dados, interferência entre cargas de trabalho e assim por diante.
+
+### Seleção do Node no kube-scheduler {#implementação-kube-scheduler}
+
+O kube-scheduler seleciona um Node para o Pod em uma operação que consiste em duas etapas:
+
+1. Filtragem
+1. Pontuação
+
+A etapa de _filtragem_ localiza o conjunto de Nodes onde é possível
+alocar o Pod. Por exemplo, o filtro PodFitsResources verifica se um Node 
+candidato possui recursos disponíveis suficientes para atender às solicitações 
+de recursos específicas de um Pod. Após esta etapa, a lista de Nodes contém 
+quaisquer Nodes adequados; frequentemente, haverá mais de um. Se a lista estiver vazia, 
+esse Pod (ainda) não é escalonável.
+
+Na etapa de _pontuação_, o escalonador classifica os Nodes restantes para escolher
+o mais adequado. O escalonador atribui uma pontuação a cada Node
+que sobreviveu à filtragem, baseando essa pontuação nas regras de pontuação ativa.
+
+Por fim, o kube-scheduler atribui o Pod ao Node com a classificação mais alta.
+Se houver mais de um Node com pontuações iguais, o kube-scheduler seleciona
+um deles aleatoriamente.
+
+Existem duas maneiras suportadas de configurar o comportamento de filtragem e pontuação
+do escalonador:
+
+1. [Políticas de Escalonamento](/docs/reference/scheduling/policies) permitem configurar _Predicados_ para filtragem e _Prioridades_ para pontuação.
+
+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.
+
+{{% /capture %}}
+{{% capture whatsnext %}}
+* Leia sobre [ajuste de desempenho do escalonador](/docs/concepts/scheduling/scheduler-perf-tuning/)
+* Leia sobre [restrições de propagação da topologia de pod](/docs/concepts/workloads/pods/pod-topology-spread-constraints/)
+* Leia a [documentação de referência](/docs/reference/command-line-tools-reference/kube-scheduler/) para o kube-scheduler
+* Aprenda como [configurar vários escalonadores](/docs/tasks/administer-cluster/configure-multiple-schedulers/)
+* Aprenda sobre [políticas de gerenciamento de topologia](/docs/tasks/administer-cluster/topology-manager/)
+* Aprenda sobre [Pod Overhead](/docs/concepts/configuration/pod-overhead/)
+{{% /capture %}}
diff --git a/content/pt/docs/reference/glossary/control-plane.md b/content/pt/docs/reference/glossary/control-plane.md
new file mode 100644
index 0000000000..4befb3bb05
--- /dev/null
+++ b/content/pt/docs/reference/glossary/control-plane.md
@@ -0,0 +1,13 @@
+---
+title: Control Plane
+id: control-plane
+date: 2020-04-19
+full_link:
+short_description: >
+  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.
+
+aka:
+tags:
+- fundamental
+---
+ 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.
diff --git a/content/pt/docs/reference/glossary/kubelet.md b/content/pt/docs/reference/glossary/kubelet.md
new file mode 100755
index 0000000000..16b55527fb
--- /dev/null
+++ b/content/pt/docs/reference/glossary/kubelet.md
@@ -0,0 +1,18 @@
+---
+title: Kubelet
+id: kubelet
+date: 2020-04-19
+full_link: /docs/reference/generated/kubelet
+short_description: >
+  Um agente que é executado em cada node no cluster. Ele garante que os contêineres estejam sendo executados em um pod.
+
+aka: 
+tags:
+- fundamental
+- core-object
+---
+ 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" >}}.
+
+<!--more--> 
+
+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.
diff --git a/content/pt/docs/reference/glossary/node.md b/content/pt/docs/reference/glossary/node.md
new file mode 100755
index 0000000000..37c88c0343
--- /dev/null
+++ b/content/pt/docs/reference/glossary/node.md
@@ -0,0 +1,17 @@
+---
+title: Node
+id: node
+date: 2020-04-19
+full_link: /docs/concepts/architecture/nodes/
+short_description: >
+  Um Node é uma máquina de trabalho no Kubernetes.
+
+aka: 
+tags:
+- fundamental
+---
+ Um Node é uma máquina de trabalho no Kubernetes.
+
+<!--more--> 
+
+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" >}}.
\ No newline at end of file
diff --git a/content/pt/docs/reference/glossary/pod.md b/content/pt/docs/reference/glossary/pod.md
new file mode 100755
index 0000000000..9f6e21d6b3
--- /dev/null
+++ b/content/pt/docs/reference/glossary/pod.md
@@ -0,0 +1,17 @@
+---
+title: Pod
+id: pod
+date: 2020-04-19
+full_link: /docs/concepts/workloads/pods/pod-overview/
+short_description: >
+  O menor e mais simples objeto Kubernetes. Um Pod representa um conjunto de contêineres em execução no seu cluster.
+aka: 
+tags:
+- core-object
+- fundamental
+---
+ 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.
+
+<!--more--> 
+
+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" >}}.
\ No newline at end of file