From d72f2022db7f8350ad33b31371cd309295dbe13c Mon Sep 17 00:00:00 2001 From: Joao Luna Date: Tue, 19 May 2020 20:24:14 +0100 Subject: [PATCH 1/8] Add docs/concepts/configuration/pod-overhead.md --- .../pt/docs/concepts/configuration/_index.md | 5 + .../concepts/configuration/pod-overhead.md | 197 ++++++++++++++++++ 2 files changed, 202 insertions(+) create mode 100644 content/pt/docs/concepts/configuration/_index.md create mode 100644 content/pt/docs/concepts/configuration/pod-overhead.md diff --git a/content/pt/docs/concepts/configuration/_index.md b/content/pt/docs/concepts/configuration/_index.md new file mode 100644 index 0000000000..f833471a5c --- /dev/null +++ b/content/pt/docs/concepts/configuration/_index.md @@ -0,0 +1,5 @@ +--- +title: "Configuração" +weight: 80 +--- + diff --git a/content/pt/docs/concepts/configuration/pod-overhead.md b/content/pt/docs/concepts/configuration/pod-overhead.md new file mode 100644 index 0000000000..357312dd46 --- /dev/null +++ b/content/pt/docs/concepts/configuration/pod-overhead.md @@ -0,0 +1,197 @@ +--- +reviewers: +- dchen1107 +- egernst +- tallclair +title: Pod Overhead +content_template: templates/concept +weight: 50 +--- + +{{% capture overview %}} + +{{< 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. +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_. + + +{{% /capture %}} + + +{{% capture body %}} + +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_. + +Quando é ativada a Sobrecarga de Pod, a sobrecarga é considerada adicionalmente à soma dos +pedidos de recursos do _container_ aquando do agendamento de um Pod. Semelhantemente, o _kubelet_ +vai incluir a sobrecarga do Pod aquando do dimensionamento do cgroup do Pod, e aquando de +levar a cabo a classificação de despejo do Pod. + +## Possibilitando a Sobrecarga do 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`. + +## 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 virutal e o sistema operativo convidado: + +```yaml +--- +kind: RuntimeClass +apiVersion: node.k8s.io/v1beta1 +metadata: + name: kata-fc +handler: kata-fc +overhead: + podFixed: + memory: "120Mi" + cpu: "250m" +``` + +As cargas de trabalho que são criadas que especifiquem o manipulador RuntimeClass `kata-fc` irão +ter a sobrecarga de memoria e cpu em conta para os calculos da quota de recursos, agendamento de nós, +assim como dimensionamento do cgroup do Pod. + +Considere executar a seguinte carga de trabalho de exemplo, test-pod: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: test-pod +spec: + runtimeClassName: kata-fc + containers: + - name: busybox-ctr + image: busybox + stdin: true + tty: true + resources: + limits: + cpu: 500m + memory: 100Mi + - name: nginx-ctr + image: nginx + resources: + limits: + cpu: 1500m + memory: 100Mi +``` + +Na altura 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_ irá ser rejeitado. No exemplo dado, como apenas o nome 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: + +```bash +kubectl get pod test-pod -o jsonpath='{.spec.overhead}' +``` + +O output é: +``` +map[cpu:250m memory:120Mi] +``` + +Se for definido um _ResourceQuota_, a soma dos pedidos aos _containers_ 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 que 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. + +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_. + +Se o recurso tiver um limite definido para cada _container_ (_QoS_ garantida ou _Bustrable 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` +definido no _PodSpec_. + +Para o CPU, se o _Pod_ for QoS garantida ou _Bustrable QoS_, o kubelet vai definir `cpu.shares` baseado na soma dos +pedidos ao _container_ mais o `overhead` definido no _PodSpec_. + +Olhando para o nosso exemplo, verifique os pedidos ao _container_ 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 and 200MiB de memória: +``` +map[cpu: 500m memory:100Mi] map[cpu:1500m memory:100Mi] +``` + +Verifique isto contra o 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_: +``` + Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits AGE + --------- ---- ------------ ---------- --------------- ------------- --- + default test-pod 2250m (56%) 2250m (56%) 320Mi (1%) 320Mi (1%) 36m +``` + +## 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 +cgroups diretamente no nó. + +Primeiro, no nó particular, determine o identificador do _Pod_: + +```bash +# Execute no nó onde o Pod está agendado +POD_ID="$(sudo crictl pods --name test-pod -q)" +``` + +A partir disto, pode determinar o caminho do cgroup para o _Pod_: +```bash +# Execute no nó onde o Pod está agendado +sudo crictl inspectp -o=json $POD_ID | grep cgroupsPath +``` + +O caminho do cgroup resultante inclui o _container_ `pause` do _Pod_. O cgroup de nivel do _Pod_ está uma diretoria 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 nivel 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. + cat /sys/fs/cgroup/memory/kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2/memory.limit_in_bytes +``` + +Isto é 320 MiB, como esperado: +``` +335544320 +``` + +### 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 +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. + +{{% /capture %}} + +{{% capture whatsnext %}} + +* [RuntimeClass](/docs/concepts/containers/runtime-class/) +* [PodOverhead Design](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md) + +{{% /capture %}} From 2021de39f295444a987789b46d873f9392cd348c Mon Sep 17 00:00:00 2001 From: Joao Luna Date: Tue, 19 May 2020 20:53:44 +0100 Subject: [PATCH 2/8] Fix typos --- .../pt/docs/concepts/configuration/pod-overhead.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/content/pt/docs/concepts/configuration/pod-overhead.md b/content/pt/docs/concepts/configuration/pod-overhead.md index 357312dd46..4847a8a115 100644 --- a/content/pt/docs/concepts/configuration/pod-overhead.md +++ b/content/pt/docs/concepts/configuration/pod-overhead.md @@ -59,7 +59,7 @@ overhead: ``` As cargas de trabalho que são criadas que especifiquem o manipulador RuntimeClass `kata-fc` irão -ter a sobrecarga de memoria e cpu em conta para os calculos da quota de recursos, agendamento de nós, +ter a sobrecarga de memoria e cpu em conta para os cálculos da quota de recursos, agendamento de nós, assim como dimensionamento do cgroup do Pod. Considere executar a seguinte carga de trabalho de exemplo, test-pod: @@ -113,12 +113,12 @@ pedidos e a sobrecarga, depois procura um nó com 2.25 CPU e 320 MiB de memória 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_. -Se o recurso tiver um limite definido para cada _container_ (_QoS_ garantida ou _Bustrable QoS_ com limites definidos), +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` definido no _PodSpec_. -Para o CPU, se o _Pod_ for QoS garantida ou _Bustrable QoS_, o kubelet vai definir `cpu.shares` baseado na soma dos +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_. Olhando para o nosso exemplo, verifique os pedidos ao _container_ para a carga de trabalho: @@ -126,7 +126,7 @@ Olhando para o nosso exemplo, verifique os pedidos ao _container_ para a carga d kubectl get pod test-pod -o jsonpath='{.spec.containers[*].resources.limits}' ``` -O total de pedidos ao _container_ são 2000m CPU and 200MiB de memória: +O total de pedidos ao _container_ são 2000m CPU e 200MiB de memória: ``` map[cpu: 500m memory:100Mi] map[cpu:1500m memory:100Mi] ``` @@ -163,12 +163,12 @@ 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 de nivel do _Pod_ está uma diretoria acima. +O caminho do cgroup resultante inclui o _container_ `pause` do _Pod_. O cgroup de nível do _Pod_ está uma directoria 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 nivel 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. From 2b0e08adc744bf3519a4e286be0c2af58057c4a7 Mon Sep 17 00:00:00 2001 From: Joao Luna Date: Tue, 19 May 2020 21:07:52 +0100 Subject: [PATCH 3/8] Small typo in pod-overhead.md --- content/en/docs/concepts/configuration/pod-overhead.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/concepts/configuration/pod-overhead.md b/content/en/docs/concepts/configuration/pod-overhead.md index 9661264820..ad14817c49 100644 --- a/content/en/docs/concepts/configuration/pod-overhead.md +++ b/content/en/docs/concepts/configuration/pod-overhead.md @@ -113,7 +113,7 @@ requests and the overhead, then looks for a node that has 2.25 CPU and 320 MiB o Once a Pod is scheduled to a node, the kubelet on that node creates a new {{< glossary_tooltip text="cgroup" term_id="cgroup" >}} for the Pod. It is within this pod that the underlying container runtime will create containers. -If the resource has a limit defined for each container (Guaranteed QoS or Bustrable QoS with limits defined), +If the resource has a limit defined for each container (Guaranteed QoS or Burstable QoS with limits defined), the kubelet will set an upper limit for the pod cgroup associated with that resource (cpu.cfs_quota_us for CPU and memory.limit_in_bytes memory). This upper limit is based on the sum of the container limits plus the `overhead` defined in the PodSpec. From 2bee076fb8122310e4dfe0a78b85e0d09948e936 Mon Sep 17 00:00:00 2001 From: Joao Luna Date: Tue, 19 May 2020 21:14:28 +0100 Subject: [PATCH 4/8] Revert "Small typo in pod-overhead.md" This reverts commit 2b0e08adc744bf3519a4e286be0c2af58057c4a7. --- content/en/docs/concepts/configuration/pod-overhead.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/concepts/configuration/pod-overhead.md b/content/en/docs/concepts/configuration/pod-overhead.md index ad14817c49..9661264820 100644 --- a/content/en/docs/concepts/configuration/pod-overhead.md +++ b/content/en/docs/concepts/configuration/pod-overhead.md @@ -113,7 +113,7 @@ requests and the overhead, then looks for a node that has 2.25 CPU and 320 MiB o Once a Pod is scheduled to a node, the kubelet on that node creates a new {{< glossary_tooltip text="cgroup" term_id="cgroup" >}} for the Pod. It is within this pod that the underlying container runtime will create containers. -If the resource has a limit defined for each container (Guaranteed QoS or Burstable QoS with limits defined), +If the resource has a limit defined for each container (Guaranteed QoS or Bustrable QoS with limits defined), the kubelet will set an upper limit for the pod cgroup associated with that resource (cpu.cfs_quota_us for CPU and memory.limit_in_bytes memory). This upper limit is based on the sum of the container limits plus the `overhead` defined in the PodSpec. From 7f3650794dfea876425aef221e5de4daed7a66e4 Mon Sep 17 00:00:00 2001 From: Joao Luna Date: Wed, 20 May 2020 18:05:27 +0100 Subject: [PATCH 5/8] Apply suggestions from code review Co-authored-by: Jhon Mike --- content/pt/docs/concepts/configuration/pod-overhead.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/content/pt/docs/concepts/configuration/pod-overhead.md b/content/pt/docs/concepts/configuration/pod-overhead.md index 4847a8a115..193c5fb83d 100644 --- a/content/pt/docs/concepts/configuration/pod-overhead.md +++ b/content/pt/docs/concepts/configuration/pod-overhead.md @@ -28,10 +28,10 @@ No Kubernetes, a sobrecarga de _Pods_ é definido no tempo de de acordo com a sobrecarga associada à [RuntimeClass](/docs/concepts/containers/runtime-class/) do _Pod_. -Quando é ativada a Sobrecarga de Pod, a sobrecarga é considerada adicionalmente à soma dos -pedidos de recursos do _container_ aquando do agendamento de um Pod. Semelhantemente, o _kubelet_ -vai incluir a sobrecarga do Pod aquando do dimensionamento do cgroup do Pod, e aquando de -levar a cabo a classificação de despejo 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_ +incluirá a sobrecarga do Pod ao dimensionar o cgroup do Pod e ao +executar a classificação de despejo do Pod. ## Possibilitando a Sobrecarga do Pod {#set-up} @@ -163,7 +163,7 @@ 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 de nível do _Pod_ está uma directoria acima. +O caminho do cgroup resultante inclui o _container_ `pause` do _Pod_. O cgroup no nível do _Pod_ está um diretório acima. ``` "cgroupsPath": "/kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2/7ccf55aee35dd16aca4189c952d83487297f3cd760f1bbf09620e206e7d0c27a" ``` From 39babc18453e13a06d606e747ded19018891de3a Mon Sep 17 00:00:00 2001 From: Joao Luna Date: Wed, 20 May 2020 18:06:33 +0100 Subject: [PATCH 6/8] Fix typo --- content/pt/docs/concepts/configuration/pod-overhead.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/pt/docs/concepts/configuration/pod-overhead.md b/content/pt/docs/concepts/configuration/pod-overhead.md index 193c5fb83d..880871bba0 100644 --- a/content/pt/docs/concepts/configuration/pod-overhead.md +++ b/content/pt/docs/concepts/configuration/pod-overhead.md @@ -43,7 +43,7 @@ por todo o cluster, e uma `RuntimeClass` é utilizada que defina o campo `overhe 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 virutal e o sistema operativo convidado: +que usa cerca de 120MiB por Pod para a máquina virtual e o sistema operativo convidado: ```yaml --- From d41fda99398f6cc17b69ec0629f2839a4519eb78 Mon Sep 17 00:00:00 2001 From: Joao Luna Date: Thu, 21 May 2020 20:34:46 +0100 Subject: [PATCH 7/8] Apply suggestions from code review Co-authored-by: Diego W. Antunes --- content/pt/docs/concepts/configuration/pod-overhead.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/content/pt/docs/concepts/configuration/pod-overhead.md b/content/pt/docs/concepts/configuration/pod-overhead.md index 880871bba0..745a6c1877 100644 --- a/content/pt/docs/concepts/configuration/pod-overhead.md +++ b/content/pt/docs/concepts/configuration/pod-overhead.md @@ -58,8 +58,8 @@ overhead: cpu: "250m" ``` -As cargas de trabalho que são criadas que especifiquem o manipulador RuntimeClass `kata-fc` irão -ter a sobrecarga de memoria e cpu em conta para os cálculos da quota de recursos, agendamento de nós, +As cargas de trabalho que são criadas e que especificam o manipulador RuntimeClass `kata-fc` irão +usar a sobrecarga de memória e cpu em conta para os cálculos da quota de recursos, agendamento de nós, assim como dimensionamento do cgroup do Pod. Considere executar a seguinte carga de trabalho de exemplo, test-pod: @@ -90,7 +90,7 @@ spec: Na altura 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_ irá ser rejeitado. No exemplo dado, como apenas o nome 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: @@ -106,7 +106,7 @@ map[cpu:250m memory:120Mi] Se for definido um _ResourceQuota_, a soma dos pedidos aos _containers_ 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 que o `overhead` do _Pod_, +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. @@ -150,7 +150,7 @@ Verifique os cgroups de memória do Pod no nó onde a carga de trabalho está em exemplo avançado para mostrar o comportamento do _PodOverhead_, e não é esperado que os utilizadores precisem de verificar cgroups diretamente no nó. -Primeiro, no nó 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 From 52adcbfd82e9828284c7eccbff84e05de12ec240 Mon Sep 17 00:00:00 2001 From: Joao Luna Date: Sat, 23 May 2020 19:50:49 +0100 Subject: [PATCH 8/8] Update content/pt/docs/concepts/configuration/pod-overhead.md Co-authored-by: Diego W. Antunes --- content/pt/docs/concepts/configuration/pod-overhead.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/pt/docs/concepts/configuration/pod-overhead.md b/content/pt/docs/concepts/configuration/pod-overhead.md index 745a6c1877..5a18b11f09 100644 --- a/content/pt/docs/concepts/configuration/pod-overhead.md +++ b/content/pt/docs/concepts/configuration/pod-overhead.md @@ -104,7 +104,7 @@ O output é: map[cpu:250m memory:120Mi] ``` -Se for definido um _ResourceQuota_, a soma dos pedidos aos _containers_ assim como o campo `overhead` são contados. +Se for definido um _ResourceQuota_, a soma dos pedidos dos _containers_ 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