You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* 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
[RuntimeClass](/docs/concepts/containers/runtime-class/) do _Pod_.
25
+
[RuntimeClass](/docs/concepts/containers/runtime-class/) do Pod.
30
26
31
27
Quando é ativada a Sobrecarga de Pod, a sobrecarga é considerada adicionalmente à soma das
32
-
solicitações de recursos do _container_ ao agendar um Pod. Semelhantemente, o _kubelet_
28
+
solicitações de recursos do contêiner ao agendar um Pod. Semelhantemente, o _kubelet_
33
29
incluirá a sobrecarga do Pod ao dimensionar o cgroup do Pod e ao
34
-
executar a classificação de despejo do Pod.
30
+
executar a classificação de prioridade de migração do Pod em caso de _drain_ do Node.
35
31
36
-
## Possibilitando a Sobrecarga do Pod {#set-up}
32
+
## Habilitando a Sobrecarga de Pod {#set-up}
37
33
38
-
Terá de garantir que o [portão de funcionalidade](/docs/reference/command-line-tools-reference/feature-gates/)
39
-
`PodOverhead`está ativo (está ativo por defeito a partir da versão 1.18)
40
-
por todo o cluster, e uma `RuntimeClass` é utilizada que defina o campo `overhead`.
34
+
Terá de garantir que o [Feature Gate](/docs/reference/command-line-tools-reference/feature-gates/)
35
+
`PodOverhead`esteja ativo (está ativo por padrão a partir da versão 1.18)
36
+
em todo o cluster, e uma `RuntimeClass` utilizada que defina o campo `overhead`.
41
37
42
38
## Exemplo de uso
43
39
44
40
Para usar a funcionalidade PodOverhead, é necessário uma RuntimeClass que define o campo `overhead`.
45
-
Por exemplo, poderia usar a definição da RuntimeClass abaixo com um _container runtime_ virtualizado
46
-
que usa cerca de 120MiB por Pod para a máquina virtual e o sistema operativo convidado:
41
+
Por exemplo, poderia usar a definição da RuntimeClass abaixo com um agente de execução de contêiner virtualizado
42
+
que use cerca de 120MiB por Pod para a máquina virtual e o sistema operacional convidado:
47
43
48
44
```yaml
49
45
---
@@ -88,9 +84,9 @@ spec:
88
84
memory: 100Mi
89
85
```
90
86
91
-
Na altura de admissão o [controlador de admissão](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/) RuntimeClass
87
+
No tempo de admissão o [controlador de admissão](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/) RuntimeClass
92
88
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
93
-
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
89
+
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
94
90
incluir um `overhead`.
95
91
96
92
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
99
95
kubectl get pod test-pod -o jsonpath='{.spec.overhead}'
100
96
```
101
97
102
-
O output é:
98
+
A saída é:
103
99
```
104
100
map[cpu:250m memory:120Mi]
105
101
```
106
102
107
-
Se for definido um _ResourceQuota_, a soma dos pedidos dos _containers_ assim como o campo `overhead` são contados.
103
+
Se for definido um _ResourceQuota_, a soma das requisições dos contêineres assim como o campo `overhead` são contados.
108
104
109
-
Quando o kube-scheduler está a decidir que nó deve executar um novo _Pod_, o agendador considera o `overhead` do _Pod_,
110
-
assim como a soma de pedidos aos _containers_ para esse _Pod_. Para este exemplo, o agendador adiciona os
111
-
pedidos e a sobrecarga, depois procura um nó com 2.25 CPU e 320 MiB de memória disponível.
105
+
Quando o kube-scheduler está decidindo que nó deve executar um novo Pod, o agendador considera o `overhead` do pod,
106
+
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.
112
107
113
-
Assim que um _Pod_ é agendado a um nó, o kubelet nesse nó cria um novo {{< glossary_tooltip text="cgroup" term_id="cgroup" >}}
114
-
para o _Pod_. É dentro deste _pod_ que o _container runtime_ subjacente vai criar _containers_.
108
+
Assim que um Pod é agendado a um nó, o kubelet nesse nó cria um novo {{< glossary_tooltip text="cgroup" term_id="cgroup" >}}
109
+
para o Pod. É dentro deste Pod que o agente de execução de contêiners subjacente vai criar contêineres.
115
110
116
-
Se o recurso tiver um limite definido para cada _container_ (_QoS_ garantida ou _Burstrable QoS_ com limites definidos),
117
-
o kubelet definirá um limite superior para o cgroup do _pod_ associado a esse recurso (cpu.cfs_quota_us para CPU
118
-
e memory.limit_in_bytes de memória). Este limite superior é baseado na soma dos limites do _container_ mais o `overhead`
111
+
Se o recurso tiver um limite definido para cada contêiner (_QoS_ garantida ou _Burstrable QoS_ com limites definidos),
112
+
o kubelet definirá um limite superior para o cgroup do Pod associado a esse recurso (cpu.cfs_quota_us para CPU
113
+
e memory.limit_in_bytes de memória). Este limite superior é baseado na soma dos limites do contêiner mais o `overhead`
119
114
definido no _PodSpec_.
120
115
121
-
Para o CPU, se o _Pod_ for QoS garantida ou _Burstrable QoS_, o kubelet vai definir `cpu.shares` baseado na soma dos
122
-
pedidos ao _container_ mais o `overhead` definido no _PodSpec_.
116
+
Para CPU, se o Pod for QoS garantida ou _Burstrable QoS_, o kubelet vai definir `cpu.shares` baseado na soma dos
117
+
pedidos ao contêiner mais o `overhead` definido no _PodSpec_.
123
118
124
-
Olhando para o nosso exemplo, verifique os pedidos ao _container_ para a carga de trabalho:
119
+
Olhando para o nosso exemplo, verifique as requisições ao contêiner para a carga de trabalho:
125
120
```bash
126
121
kubectl get pod test-pod -o jsonpath='{.spec.containers[*].resources.limits}'
127
122
```
128
123
129
-
O total de pedidos ao _container_ são 2000m CPU e 200MiB de memória:
124
+
O total de requisições ao contêiner são 2000m CPU e 200MiB de memória:
@@ -145,12 +140,12 @@ O output mostra que 2250m CPU e 320MiB de memória são solicitados, que inclui
145
140
146
141
## Verificar os limites cgroup do Pod
147
142
148
-
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)
149
-
é usado no nó, que fornece uma CLI para _container runtimes_ compatíveis com CRI. Isto é um
150
-
exemplo avançado para mostrar o comportamento do _PodOverhead_, e não é esperado que os utilizadores precisem de verificar
143
+
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)
144
+
é usado no nó, que fornece uma CLI para agentes de execução compatíveis com CRI. Isto é um
145
+
exemplo avançado para mostrar o comportamento do _PodOverhead_, e não é esperado que os usuários precisem verificar
151
146
cgroups diretamente no nó.
152
147
153
-
Primeiro, no nó em particular, determine o identificador do _Pod_:
148
+
Primeiro, no nó em particular, determine o identificador do Pod:
154
149
155
150
```bash
156
151
# Execute no nó onde o Pod está agendado
@@ -163,15 +158,15 @@ A partir disto, pode determinar o caminho do cgroup para o _Pod_:
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:
166
+
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:
172
167
```bash
173
168
# Execute no nó onde o Pod está agendado
174
-
# Mude também o nome do cgroup de forma a combinar com o cgroup alocado ao pod.
169
+
# Mude também o nome do cgroup para combinar com o cgroup alocado ao Pod.
0 commit comments