From ba4cf5f99e7c559071a7f3c5bdf05d2366046ec6 Mon Sep 17 00:00:00 2001 From: "Edson (aka tuxpilgrim)" Date: Fri, 12 Mar 2021 10:08:18 -0300 Subject: [PATCH] Update content/pt/docs/concepts/scheduling-eviction/ (#26924) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * Move pod-overhead.md to schedulling-eviction * Add pod-overhead.md translation * Update content/pt/docs/concepts/scheduling-eviction/pod-overhead.md * Fix name: test-Pod to name: test-pod * Small fixes * remove reviewers * change 'fonte' to 'código fonte' * Add the suggestion by code review * Update the references with the original doc * Update the _index.md --- .../concepts/scheduling-eviction/_index.md | 8 ++ .../kube-scheduler.md | 5 +- .../pod-overhead.md | 87 +++++++++---------- content/pt/docs/concepts/scheduling/_index.md | 5 -- 4 files changed, 53 insertions(+), 52 deletions(-) create mode 100644 content/pt/docs/concepts/scheduling-eviction/_index.md rename content/pt/docs/concepts/{scheduling => scheduling-eviction}/kube-scheduler.md (93%) rename content/pt/docs/concepts/{configuration => scheduling-eviction}/pod-overhead.md (54%) delete mode 100644 content/pt/docs/concepts/scheduling/_index.md diff --git a/content/pt/docs/concepts/scheduling-eviction/_index.md b/content/pt/docs/concepts/scheduling-eviction/_index.md new file mode 100644 index 0000000000..e9e036f0c3 --- /dev/null +++ b/content/pt/docs/concepts/scheduling-eviction/_index.md @@ -0,0 +1,8 @@ +--- +title: "Escalonamento" +weight: 90 +description: > + No Kubernetes, agendamento refere-se a garantia de que os pods correspondam aos nós para que o kubelet possa executá-los. + Remoção é o processo de falha proativa de um ou mais pods em nós com falta de recursos. +--- + diff --git a/content/pt/docs/concepts/scheduling/kube-scheduler.md b/content/pt/docs/concepts/scheduling-eviction/kube-scheduler.md similarity index 93% rename from content/pt/docs/concepts/scheduling/kube-scheduler.md rename to content/pt/docs/concepts/scheduling-eviction/kube-scheduler.md index 575a8e7839..8c8b0ec39a 100644 --- a/content/pt/docs/concepts/scheduling/kube-scheduler.md +++ b/content/pt/docs/concepts/scheduling-eviction/kube-scheduler.md @@ -91,4 +91,7 @@ do escalonador: * 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/) - +* Saiba mais sobre o agendamento de pods que usam volumes em: + * [Suporte de topologia de volume](/docs/concepts/storage/storage-classes/#volume-binding-mode) + * [Rastreamento de capacidade de armazenamento](/docs/concepts/storage/storage-capacity/) + * [Limites de volumes específicos do nó](/docs/concepts/storage/storage-limits/) \ No newline at end of file diff --git a/content/pt/docs/concepts/configuration/pod-overhead.md b/content/pt/docs/concepts/scheduling-eviction/pod-overhead.md similarity index 54% rename from content/pt/docs/concepts/configuration/pod-overhead.md rename to content/pt/docs/concepts/scheduling-eviction/pod-overhead.md index 78ba1d6ffd..c3788b22fa 100644 --- a/content/pt/docs/concepts/configuration/pod-overhead.md +++ b/content/pt/docs/concepts/scheduling-eviction/pod-overhead.md @@ -1,9 +1,5 @@ --- -reviewers: -- dchen1107 -- egernst -- tallclair -title: Pod Overhead +title: Sobrecarga de Pod content_type: concept weight: 50 --- @@ -12,10 +8,10 @@ weight: 50 {{< feature-state for_k8s_version="v1.18" state="beta" >}} -Quando executa um Pod num nó, o próprio Pod usa uma quantidade de recursos do sistema. Estes -recursos são adicionais aos recursos necessários para executar o(s) _container(s)_ dentro do Pod. +Quando você executa um Pod num nó, o próprio Pod usa uma quantidade de recursos do sistema. Estes +recursos são adicionais aos recursos necessários para executar o(s) contêiner(s) dentro do Pod. Sobrecarga de Pod, do inglês _Pod Overhead_, é uma funcionalidade que serve para contabilizar os recursos consumidos pela -infraestrutura do Pod para além das solicitações e limites do _container_. +infraestrutura do Pod para além das solicitações e limites do contêiner. @@ -23,27 +19,27 @@ infraestrutura do Pod para além das solicitações e limites do _container_. -No Kubernetes, a sobrecarga de _Pods_ é definido no tempo de +No Kubernetes, a sobrecarga de Pods é definido no tempo de [admissão](/docs/reference/access-authn-authz/extensible-admission-controllers/#what-are-admission-webhooks) de acordo com a sobrecarga associada à -[RuntimeClass](/docs/concepts/containers/runtime-class/) do _Pod_. +[RuntimeClass](/docs/concepts/containers/runtime-class/) do Pod. Quando é ativada a Sobrecarga de Pod, a sobrecarga é considerada adicionalmente à soma das -solicitações de recursos do _container_ ao agendar um Pod. Semelhantemente, o _kubelet_ +solicitações de recursos do contêiner ao agendar um Pod. Semelhantemente, o _kubelet_ incluirá a sobrecarga do Pod ao dimensionar o cgroup do Pod e ao -executar a classificação de despejo do Pod. +executar a classificação de prioridade de migração do Pod em caso de _drain_ do Node. -## Possibilitando a Sobrecarga do Pod {#set-up} +## Habilitando a Sobrecarga de Pod {#set-up} -Terá de garantir que o [portão de funcionalidade](/docs/reference/command-line-tools-reference/feature-gates/) -`PodOverhead` está ativo (está ativo por defeito a partir da versão 1.18) -por todo o cluster, e uma `RuntimeClass` é utilizada que defina o campo `overhead`. +Terá de garantir que o [Feature Gate](/docs/reference/command-line-tools-reference/feature-gates/) +`PodOverhead` esteja ativo (está ativo por padrão a partir da versão 1.18) +em todo o cluster, e uma `RuntimeClass` utilizada que defina o campo `overhead`. ## Exemplo de uso Para usar a funcionalidade PodOverhead, é necessário uma RuntimeClass que define o campo `overhead`. -Por exemplo, poderia usar a definição da RuntimeClass abaixo com um _container runtime_ virtualizado -que usa cerca de 120MiB por Pod para a máquina virtual e o sistema operativo convidado: +Por exemplo, poderia usar a definição da RuntimeClass abaixo com um agente de execução de contêiner virtualizado +que use cerca de 120MiB por Pod para a máquina virtual e o sistema operacional convidado: ```yaml --- @@ -88,9 +84,9 @@ spec: memory: 100Mi ``` -Na altura de admissão o [controlador de admissão](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/) RuntimeClass +No tempo de admissão o [controlador de admissão](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/) RuntimeClass atualiza o _PodSpec_ da carga de trabalho de forma a incluir o `overhead` como descrito na RuntimeClass. Se o _PodSpec_ já tiver este campo definido -o _Pod_ será rejeitado. No exemplo dado, como apenas o nome do RuntimeClass é especificado, o controlador de admissão muda o _Pod_ de forma a +o Pod será rejeitado. No exemplo dado, como apenas o nome do RuntimeClass é especificado, o controlador de admissão muda o Pod de forma a incluir um `overhead`. Depois do controlador de admissão RuntimeClass, pode verificar o _PodSpec_ atualizado: @@ -99,44 +95,43 @@ Depois do controlador de admissão RuntimeClass, pode verificar o _PodSpec_ atua kubectl get pod test-pod -o jsonpath='{.spec.overhead}' ``` -O output é: +A saída é: ``` map[cpu:250m memory:120Mi] ``` -Se for definido um _ResourceQuota_, a soma dos pedidos dos _containers_ assim como o campo `overhead` são contados. +Se for definido um _ResourceQuota_, a soma das requisições dos contêineres assim como o campo `overhead` são contados. -Quando o kube-scheduler está a decidir que nó deve executar um novo _Pod_, o agendador considera o `overhead` do _Pod_, -assim como a soma de pedidos aos _containers_ para esse _Pod_. Para este exemplo, o agendador adiciona os -pedidos e a sobrecarga, depois procura um nó com 2.25 CPU e 320 MiB de memória disponível. +Quando o kube-scheduler está decidindo que nó deve executar um novo Pod, o agendador considera o `overhead` do pod, +assim como a soma de pedidos aos contêineres para esse _Pod_. Para este exemplo, o agendador adiciona as requisições e a sobrecarga, depois procura um nó com 2.25 CPU e 320 MiB de memória disponível. -Assim que um _Pod_ é agendado a um nó, o kubelet nesse nó cria um novo {{< glossary_tooltip text="cgroup" term_id="cgroup" >}} -para o _Pod_. É dentro deste _pod_ que o _container runtime_ subjacente vai criar _containers_. +Assim que um Pod é agendado a um nó, o kubelet nesse nó cria um novo {{< glossary_tooltip text="cgroup" term_id="cgroup" >}} +para o Pod. É dentro deste Pod que o agente de execução de contêiners subjacente vai criar contêineres. -Se o recurso tiver um limite definido para cada _container_ (_QoS_ garantida ou _Burstrable QoS_ com limites definidos), -o kubelet definirá um limite superior para o cgroup do _pod_ associado a esse recurso (cpu.cfs_quota_us para CPU -e memory.limit_in_bytes de memória). Este limite superior é baseado na soma dos limites do _container_ mais o `overhead` +Se o recurso tiver um limite definido para cada contêiner (_QoS_ garantida ou _Burstrable QoS_ com limites definidos), +o kubelet definirá um limite superior para o cgroup do Pod associado a esse recurso (cpu.cfs_quota_us para CPU +e memory.limit_in_bytes de memória). Este limite superior é baseado na soma dos limites do contêiner mais o `overhead` definido no _PodSpec_. -Para o CPU, se o _Pod_ for QoS garantida ou _Burstrable QoS_, o kubelet vai definir `cpu.shares` baseado na soma dos -pedidos ao _container_ mais o `overhead` definido no _PodSpec_. +Para CPU, se o Pod for QoS garantida ou _Burstrable QoS_, o kubelet vai definir `cpu.shares` baseado na soma dos +pedidos ao contêiner mais o `overhead` definido no _PodSpec_. -Olhando para o nosso exemplo, verifique os pedidos ao _container_ para a carga de trabalho: +Olhando para o nosso exemplo, verifique as requisições ao contêiner para a carga de trabalho: ```bash kubectl get pod test-pod -o jsonpath='{.spec.containers[*].resources.limits}' ``` -O total de pedidos ao _container_ são 2000m CPU e 200MiB de memória: +O total de requisições ao contêiner são 2000m CPU e 200MiB de memória: ``` map[cpu: 500m memory:100Mi] map[cpu:1500m memory:100Mi] ``` -Verifique isto contra o que é observado pelo nó: +Verifique isto comparado ao que é observado pelo nó: ```bash kubectl describe node | grep test-pod -B2 ``` -O output mostra que 2250m CPU e 320MiB de memória são solicitados, que inclui _PodOverhead_: +A saída mostra que 2250m CPU e 320MiB de memória são solicitados, que inclui _PodOverhead_: ``` Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits AGE --------- ---- ------------ ---------- --------------- ------------- --- @@ -145,12 +140,12 @@ O output mostra que 2250m CPU e 320MiB de memória são solicitados, que inclui ## Verificar os limites cgroup do Pod -Verifique os cgroups de memória do Pod no nó onde a carga de trabalho está em execução. No seguinte exemplo, [`crictl`] (https://github.com/kubernetes-sigs/cri-tools/blob/master/docs/crictl.md) -é usado no nó, que fornece uma CLI para _container runtimes_ compatíveis com CRI. Isto é um -exemplo avançado para mostrar o comportamento do _PodOverhead_, e não é esperado que os utilizadores precisem de verificar +Verifique os cgroups de memória do Pod no nó onde a carga de trabalho está em execução. No seguinte exemplo, [`crictl`](https://github.com/kubernetes-sigs/cri-tools/blob/master/docs/crictl.md) +é usado no nó, que fornece uma CLI para agentes de execução compatíveis com CRI. Isto é um +exemplo avançado para mostrar o comportamento do _PodOverhead_, e não é esperado que os usuários precisem verificar cgroups diretamente no nó. -Primeiro, no nó em particular, determine o identificador do _Pod_: +Primeiro, no nó em particular, determine o identificador do Pod: ```bash # Execute no nó onde o Pod está agendado @@ -163,15 +158,15 @@ A partir disto, pode determinar o caminho do cgroup para o _Pod_: sudo crictl inspectp -o=json $POD_ID | grep cgroupsPath ``` -O caminho do cgroup resultante inclui o _container_ `pause` do _Pod_. O cgroup no nível do _Pod_ está um diretório acima. +O caminho do cgroup resultante inclui o contêiner `pause` do Pod. O cgroup no nível do Pod está um diretório acima. ``` "cgroupsPath": "/kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2/7ccf55aee35dd16aca4189c952d83487297f3cd760f1bbf09620e206e7d0c27a" ``` -Neste caso especifico, o caminho do cgroup do pod é `kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2`. Verifique a configuração cgroup de nível do _Pod_ para a memória: +Neste caso especifico, o caminho do cgroup do Pod é `kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2`. Verifique a configuração cgroup de nível do Pod para a memória: ```bash # Execute no nó onde o Pod está agendado -# Mude também o nome do cgroup de forma a combinar com o cgroup alocado ao pod. +# Mude também o nome do cgroup para combinar com o cgroup alocado ao Pod. cat /sys/fs/cgroup/memory/kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2/memory.limit_in_bytes ``` @@ -182,10 +177,10 @@ Isto é 320 MiB, como esperado: ### Observabilidade -Uma métrica `kube_pod_overhead` está disponível em [kube-state-metrics] (https://github.com/kubernetes/kube-state-metrics) -para ajudar a identificar quando o _PodOverhead_ está a ser utilizado e para ajudar a observar a estabilidade das cargas de trabalho +Uma métrica `kube_pod_overhead` está disponível em [kube-state-metrics](https://github.com/kubernetes/kube-state-metrics) +para ajudar a identificar quando o _PodOverhead_ está sendo utilizado e para ajudar a observar a estabilidade das cargas de trabalho em execução com uma sobrecarga (_Overhead_) definida. Esta funcionalidade não está disponível na versão 1.9 do kube-state-metrics, -mas é esperado num próximo _release_. Os utilizadores necessitarão entretanto de construir kube-state-metrics a partir da fonte. +mas é esperado em uma próxima versão. Os usuários necessitarão entretanto construir o kube-state-metrics a partir do código fonte. diff --git a/content/pt/docs/concepts/scheduling/_index.md b/content/pt/docs/concepts/scheduling/_index.md deleted file mode 100644 index 577dbb8c87..0000000000 --- a/content/pt/docs/concepts/scheduling/_index.md +++ /dev/null @@ -1,5 +0,0 @@ ---- -title: "Escalonamento" -weight: 90 ---- -