whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Apply suggestions from code review

Browse Source 
Co-authored-by: Diego W. Antunes <devlware@gmail.com>
This commit is contained in:
Joao Luna
2020-05-21 20:34:46 +01:00
committed by GitHub
parent 39babc1845
commit d41fda9939
1 changed files with 5 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/pt/docs/concepts/configuration/pod-overhead.md
+5 -5
View File
@@ -58,8 +58,8 @@ overhead:
cpu: "250m" cpu: "250m"
``` ```
As cargas de trabalho que são criadas que especifiquem o manipulador RuntimeClass `kata-fc` irão As cargas de trabalho que são criadas e que especificam 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, 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. assim como dimensionamento do cgroup do Pod.
Considere executar a seguinte carga de trabalho de exemplo, test-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 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 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`. incluir um `overhead`.
Depois do controlador de admissão RuntimeClass, pode verificar o _PodSpec_ atualizado: 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. 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 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. 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 exemplo avançado para mostrar o comportamento do _PodOverhead_, e não é esperado que os utilizadores precisem de verificar
cgroups diretamente no nó. cgroups diretamente no nó.
Primeiro, no nó particular, determine o identificador do _Pod_: Primeiro, no nó em particular, determine o identificador do _Pod_:
```bash ```bash
# Execute no nó onde o Pod está agendado # Execute no nó onde o Pod está agendado