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
Copy file name to clipboardExpand all lines: content/es/docs/concepts/workloads/pods/disruptions.md
+64-75Lines changed: 64 additions & 75 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -13,142 +13,134 @@ aplicaciones con alta disponibilidad y que necesitan entender
13
13
que tipos de interrupciones pueden suceder en los Pods.
14
14
15
15
También es para los administradores de clústers que quieren aplicar acciones
16
-
automáticas en sus clústers, cómo actualizar o autoescalar los clústers.
16
+
automatizadas en sus clústers, cómo actualizar o autoescalar los clústers.
17
17
18
18
<!-- body -->
19
19
20
20
## Interrupciones voluntarias e involuntarias
21
21
22
-
Los pods no desaparecen hasta que algo (una persona o un controlador) los destruye
23
-
ó hay problemas de hardware ó del software que son inevitables.
22
+
Los Pods no desaparecen hasta que algo (una persona o un controlador) los destruye
23
+
ó hay problemas de hardware ó software que son inevitables.
24
24
25
25
Nosotros llamamos a esos casos inevitables *interrupciones involuntarias* de
26
26
una aplicación. Algunos ejemplos:
27
27
28
-
- Una falla en en hardware de la máquina física del nodo
28
+
- Una falla en hardware de la máquina física del nodo
29
29
- Un administrador del clúster borra una VM (instancia) por error
30
-
- El proveedor cloud o el hypervisor falla y hace desaparecer la VM
30
+
- El proveedor de la nube o el hipervisor falla y hace desaparecer la VM
31
31
- Un kernel panic
32
32
- El nodo desaparece del clúster por un problema de red que lo separa del clúster
33
-
- Una remoción del pod porque el nodo esta [sin-recursos-suficientes](/docs/concepts/scheduling-eviction/node-pressure-eviction/).
33
+
- Una remoción del Pod porque el nodo [no tiene recursossuficientes](/docs/concepts/scheduling-eviction/node-pressure-eviction/).
34
34
35
-
A excepción de la condición sin-recursos-suficientes, todas estas condiciones
35
+
A excepción de la condición sinrecursossuficientes, todas estas condiciones
36
36
deben ser familiares para la mayoría de los usuarios, no son específicas
37
37
de Kubernetes
38
38
39
39
Nosotros llamamos a los otros casos *interrupciones voluntarias*. Estas incluyen
40
40
las acciones iniciadas por el dueño de la aplicación y aquellas iniciadas por el Administrador
41
41
del Clúster. Las acciones típicas de los dueños de la aplicación incluye:
42
42
43
-
- borrar el deployment o otro controlador que maneja el pod
44
-
- actualizar el deployment del pod que causa un reinicio
45
-
- borrar un pod (por ejemplo por accidente)
43
+
- borrar el Deployment u otro controlador que maneja el Pod
44
+
- actualizar el Deployment del Pod que causa un reinicio
45
+
- borrar un Pod (por ejemplo, por accidente)
46
46
47
47
Las acciones del administrador del clúster incluyen:
48
48
49
-
-[Drenar un nodo](/docs/tasks/administer-clúster/safely-drain-node/) para reparar o actualizar.
49
+
-[Drenar un nodo](/docs/tasks/administer-cluster/safely-drain-node/) para reparar o actualizar.
50
50
- Drenar un nodo del clúster para reducir el clúster (aprenda acerca de [Autoescalamiento de Clúster](https://github.com/kubernetes/autoscaler/#readme)
51
51
).
52
-
- Remover un pod de un nodo para permitir que otra cosa pueda ingresar a ese nodo.
52
+
- Remover un Pod de un nodo para permitir que otra cosa pueda ingresar a ese nodo.
53
53
54
54
Estas acciones pueden ser realizadas directamente por el administrador del clúster, por
55
-
tareas automaticas del administrador del clúster ó por el proveedor del clúster.
56
-
```Si puden revisar esta frase de arriba sería muy bueno, no me gusta como ha quedado```
55
+
tareas automatizadas del administrador del clúster ó por el proveedor del clúster.
57
56
58
-
Consulte al administrador de su clúster, a su proveedor cloud ó la documentación de su distribución
57
+
Consulte al administrador de su clúster, a su proveedor de la nube ó a la documentación de su distribución
59
58
para determinar si alguna de estas interrupciones voluntarias están habilitadas en su clúster.
60
-
Si no estan habilitadas, puede saltear la creación del presupuesto de Interrupción de Pods.
61
-
```Si puden revisar esta frase de arriba sería muy bueno, no me gusta como ha quedado```
59
+
Si ninguna se encuentra habilitada, puede omitir la creación del presupuesto de Interrupción de Pods.
62
60
63
61
{{< caution >}}
64
62
No todas las interrupciones voluntarias son consideradas por el presupuesto de interrupción de Pods. Por ejemplo,
65
-
borrar un deployment o pods que evitan el uso del presupuesto.
63
+
borrar un Deployment o Pods que evitan el uso del presupuesto.
66
64
{{< /caution >}}
67
65
68
66
## Tratando con las interrupciones
69
67
70
68
Estas son algunas de las maneras para mitigar las interrupciones involuntarias:
71
69
72
-
- Asegurarse que el pod[solicite los recursos](/docs/tasks/configure-pod-container/assign-memory-resource) que necesita.
73
-
- Replique su aplicación su usted necesita alta disponiblidad. (Aprenda sobre correr aplicaciones replicadas
70
+
- Asegurarse que el Pod[solicite los recursos](/docs/tasks/configure-pod-container/assign-memory-resource) que necesita.
71
+
- Replique su aplicación si usted necesita alta disponibilidad. (Aprenda sobre correr aplicaciones replicadas
Kubernetes ofrece carácteristicas para ayudar a ejecutar aplicaciones con alta disponibliidad, incluso cuando usted
97
-
introduce frecuentes interrupciones voluntarias.
95
+
introduce interrupciones voluntarias frecuentes.
98
96
99
-
```Necesito que me digan si aca ponemos en ingles PodDisruptionBudget o se hace la tradución```
100
-
Como dueño de la aplicación, usted puede crear un presupuesto de interrupcion de pods (PDB por su sigla en inglés) para cada aplicación.
101
-
Un PDB limita el numero de Pods de una aplicación replicada, que estan caídos de manera simultánea por
97
+
Como dueño de la aplicación, usted puede crear un presupuesto de interrupción de Pods (PDB por sus siglas en inglés) para cada aplicación.
98
+
Un PDB limita el numero de Pods de una aplicación replicada, que estan caídos de manera simultánea por
102
99
interrupciones voluntarias. Por ejemplo, una aplicación basada en quórum puede
103
100
asegurarse que el número de réplicas corriendo nunca es menor al
104
-
número necesitado para obtener el quórum. Un front de una web puede querer
101
+
número necesitado para obtener el quórum. Una web de tipo front end puede querer
105
102
asegurarse que el número de réplicas atendiendo al tráfico nunca puede caer bajo un cierto
106
103
porcentaje del total.
107
104
108
105
Los administradores del clúster y proveedores de hosting pueden usar herramientas que
109
-
repeten el presupuesto de interrupción de pods utilizando la [API de Desalojo](/docs/tasks/administer-clúster/safely-drain-node/#eviction-api)
110
-
en vez de directamente borrar pods o deployments.
106
+
respeten el presupuesto de interrupción de Pods utilizando la [API de Desalojo](/docs/tasks/administer-clúster/safely-drain-node/#eviction-api)
107
+
en vez de directamente borrar Pods o Deployments.
111
108
112
109
Por ejemplo, el subcomando `kubectl drain` le permite marcar un nodo a un modo fuera de
113
110
servicio. Cuando se ejecuta `kubectl drain`, la herramienta trata de quitar a todos los Pods en
114
-
el nodo que se esta dejando fuera de servicio. El pedido de desalojo que `kubectl` solicita en
111
+
el nodo que se esta dejando fuera de servicio. La petición de desalojo que `kubectl` solicita en
115
112
su nombre puede ser temporalmente denegado, entonces la herramienta periodicamente reintenta todas las
116
113
peticiones fallidas hasta que todos los Pods en el nodo afectado son terminados ó hasta que el tiempo de espera,
117
114
que puede ser configurado, es alcanzado.
118
115
119
-
Un PDB especifica el número de réplicas que una aplicación puede tener, relativo a cuantos
116
+
Un PDB especifica el número de réplicas que una aplicación puede tolerar, relativo a cuantas
120
117
se pretende tener. Por ejemplo, un Deployment que tiene un `.spec.replicas: 5` se
121
-
supone que tiene 5 pods en cualquier momento. Si su PDB permite tener 4 por a la vez,
122
-
entonces la API de Desalojo va a permitir interrupciones voluntarias a uno (pero no a dos) pods.
118
+
supone que tiene 5 Pods en cualquier momento. Si su PDB permite tener 4 a la vez,
119
+
entonces la API de Desalojo va a permitir interrupciones voluntarias de un (pero no a dos) Pod a la vez.
123
120
124
-
El grupo de pods que comprende a la aplicación esta especificada usando una etiqueta selectora, la mismma
121
+
El grupo de Pods que comprende a la aplicación esta especificada usando una etiqueta selectora, la misma
125
122
que es usada por el controlador de aplicación (deployment, stateful-set, etc).
126
123
127
-
```No puedo darle sentido a estas lineas, necesito ayuda```
128
-
The "intended" number of pods is computed from the `.spec.replicas` of the workload resource
129
-
that is managing those pods. The control plane discovers the owning workload resource by
130
-
examining the `.metadata.ownerReferences` of the Pod.
124
+
El numero de Pods "deseado" es calculado a partir de `.spec.replicas` de el recurso de Workload
125
+
que es manejado para esos Pods. El plano de control descubre el recurso Workload perteneciente a el
126
+
examinando las `.metadata.ownerReferences` del Pod.
131
127
132
128
Las [Interrupciones Involuntarias](#voluntary-and-involuntary-disruptions) no pueden ser prevenidas por los PDB; pero si
133
-
son contabilizadas contra este presupuesto.
129
+
son contabilizadas a partir este presupuesto.
134
130
135
-
Los Pods que son borrados o no estan disponibles por una actualización continua de una aplicación cuentan
136
-
contra el presupuesto de interrupciones, pero los recursos de trabajo (como los Deployments y StatefulSet)
137
-
no están limitados por los PDBs cuando hacen actualizaciones continuas. En cambio, el manejo de fallas
138
-
mientras dura la actualización de la aplicación es configurado en el spec de este recurso específico.
139
-
```La ultima frase de arriba no me gusta como queda, quisiera agregar algo como que el rollout no se contabiliza, pero no se si es correcto
140
-
o hace falta```
131
+
Los Pods que son borrados o no estan disponibles debido a una actualización continua de una aplicación forman parte del presupuesto de interrupciones, pero los recursos Workload (como los Deployments y StatefulSet)
132
+
no están limitados por los PDBs cuando se hacen actualizaciones continuas. En cambio, la administración de fallas
133
+
durante la actualización de la aplicación es configurada en la especificación para este recurso Workload específico.
141
134
142
-
Cuando un pod es quitado usando la API de desarolojo, este es
135
+
Cuando un Pod es quitado usando la API de desalojo, este es
143
136
[terminado](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination) correctamente, haciendo honor al
144
137
`terminationGracePeriodSeconds` configurado en su [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core).
145
-
```Arriba no hago la traducción de PodeSpec porque no se si sería necesario```
146
138
147
139
## Ejemplo de Presupuesto de Interrupción de POD {#pdb-example}
148
140
149
141
Considere un clúster con 3 nodos, `nodo-1` hasta `nodo-3`.
150
142
El clúster esta corriendo varias aplicaciones. Uno de ellos tiene 3 replicas, que llamaremos
151
-
`pod-a`, `pod-b`, and `pod-c`. Otro pod no relacionado y sin PDB, llamado `pod-x`, tambien se muestra.
143
+
`pod-a`, `pod-b`, y`pod-c`. Otro Pod no relacionado y sin PDB, llamado `pod-x`, también se muestra.
152
144
153
145
Inicialmente los pods estan distribuidos de esta manera:
154
146
@@ -158,28 +150,25 @@ Inicialmente los pods estan distribuidos de esta manera:
El deployment detecta que uno de los pods esta terminando, entonces crea un reemplazo
167
+
El Deployment detecta que uno de los Pods esta terminando, entonces crea un reemplazo
176
168
llamado `pod-d`. Como el `nodo-1` esta bloqueado, el pod termina en otro nodo. Algo más, adicionalmente
177
169
a creado el pod `pod-y` como un reemplazo del `pod-x` .
178
170
179
-
```Necesita revisión```
180
-
(Note: for a StatefulSet, `pod-a`, which would be called something like `pod-0`, would need
181
-
to terminate completely before its replacement, which is also called `pod-0` but has a
182
-
different UID, could be created. Otherwise, the example applies to a StatefulSet as well.)
171
+
(Nota: para un StatefulSet, `pod-a`, el cual debería ser llamado algo como `pod-0`, necesitaría ser terminado completamente antes de su remplazo, el cual también es llamado `pod-0` pero tiene un UID diferente, podría ser creado. De lo contrario, el ejemplo también aplica a un StatefulSet.)
183
172
184
173
Ahora el clúster esta en este estado:
185
174
@@ -188,16 +177,16 @@ Ahora el clúster esta en este estado:
0 commit comments