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
+83-84Lines changed: 83 additions & 84 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -11,35 +11,35 @@ weight: 60
11
11
<!-- overview -->
12
12
Esta guía es para los dueños de aplicaciones que quieren crear
13
13
aplicaciones con alta disponibilidad y que necesitan entender
14
-
que tipos de interrupciones pueden suceder en los Pods.
14
+
qué tipos de interrupciones pueden suceder en los Pods.
15
15
16
-
También es para los administradores de clústers que quieren aplicar acciones
17
-
automatizadas en sus clústers, cómo actualizar o autoescalar los clústers.
16
+
También es para los administradores de clústeres que quieren aplicar acciones
17
+
automatizadas en sus clústeres, como actualizar o autoescalar los clústeres.
18
18
19
19
<!-- body -->
20
20
21
21
## Interrupciones voluntarias e involuntarias
22
22
23
23
Los Pods no desaparecen hasta que algo (una persona o un controlador) los destruye
24
-
ó hay problemas de hardware ó software que son inevitables.
24
+
o hay problemas de hardware o software que son inevitables.
25
25
26
26
Nosotros llamamos a esos casos inevitables *interrupciones involuntarias* de
27
27
una aplicación. Algunos ejemplos:
28
28
29
-
- Una falla en hardware de la máquina física del nodo
30
-
- Un administrador del clúster borra una VM (instancia) por error
31
-
- El proveedor de la nube o el hipervisor falla y hace desaparecer la VM
32
-
- Un kernel panic
33
-
- El nodo desaparece del clúster por un problema de red que lo separa del clúster
29
+
- Una falla en el hardware de la máquina física del nodo.
30
+
- Un administrador del clúster borra una VM (instancia) por error.
31
+
- El proveedor de la nube o el hipervisor falla y hace desaparecer la VM.
32
+
- Un kernel panic.
33
+
- El nodo desaparece del clúster por un problema de red que lo separa del clúster.
34
34
- Una remoción del Pod porque el nodo [no tiene recursos suficientes](/docs/concepts/scheduling-eviction/node-pressure-eviction/).
35
35
36
36
A excepción de la condición sin recursos suficientes, todas estas condiciones
37
37
deben ser familiares para la mayoría de los usuarios, no son específicas
38
-
de Kubernetes
38
+
de Kubernetes.
39
39
40
40
Nosotros llamamos a los otros casos *interrupciones voluntarias*. Estas incluyen
41
41
las acciones iniciadas por el dueño de la aplicación y aquellas iniciadas por el Administrador
42
-
del Clúster. Las acciones típicas de los dueños de la aplicación incluye:
42
+
del Clúster. Las acciones típicas de los dueños de la aplicación incluyen:
43
43
44
44
- borrar el Deployment u otro controlador que maneja el Pod
45
45
- actualizar el Deployment del Pod que causa un reinicio
@@ -48,15 +48,14 @@ del Clúster. Las acciones típicas de los dueños de la aplicación incluye:
48
48
Las acciones del administrador del clúster incluyen:
49
49
50
50
-[Drenar un nodo](/docs/tasks/administer-cluster/safely-drain-node/) para reparar o actualizar.
51
-
- Drenar un nodo del clúster para reducir el clúster (aprenda acerca de [Autoescalamiento de Clúster](https://github.com/kubernetes/autoscaler/#readme)
52
-
).
51
+
- Drenar un nodo del clúster para reducir el clúster (aprenda acerca de [Autoescalamiento de Clúster](https://github.com/kubernetes/autoscaler/#readme)).
53
52
- Remover un Pod de un nodo para permitir que otra cosa pueda ingresar a ese nodo.
54
53
55
54
Estas acciones pueden ser realizadas directamente por el administrador del clúster, por
56
-
tareas automatizadas del administrador del clúster ó por el proveedor del clúster.
55
+
tareas automatizadas del administrador del clúster o por el proveedor del clúster.
57
56
58
-
Consulte al administrador de su clúster, a su proveedor de la nube ó a la documentación de su distribución
59
-
para determinar si alguna de estas interrupciones voluntarias están habilitadas en su clúster.
57
+
Consulte al administrador de su clúster, a su proveedor de la nube o a la documentación de su distribución
58
+
para determinar si alguna de estas interrupciones voluntarias está habilitada en su clúster.
60
59
Si ninguna se encuentra habilitada, puede omitir la creación del presupuesto de Interrupción de Pods.
61
60
62
61
{{< caution >}}
@@ -104,46 +103,46 @@ asegurarse que el número de réplicas atendiendo al tráfico nunca puede caer b
104
103
porcentaje del total.
105
104
106
105
Los administradores del clúster y proveedores de hosting pueden usar herramientas que
107
-
respeten el presupuesto de interrupción de Pods utilizando la [API de Desalojo](/docs/tasks/administer-clúster/safely-drain-node/#eviction-api)
106
+
respeten el presupuesto de interrupción de Pods utilizando la [API de Desalojo](/docs/tasks/administer-cluster/safely-drain-node/#eviction-api)
108
107
en vez de directamente borrar Pods o Deployments.
109
108
110
109
Por ejemplo, el subcomando `kubectl drain` le permite marcar un nodo a un modo fuera de
111
110
servicio. Cuando se ejecuta `kubectl drain`, la herramienta trata de quitar a todos los Pods en
112
111
el nodo que se esta dejando fuera de servicio. La petición de desalojo que `kubectl` solicita en
113
112
su nombre puede ser temporalmente denegado, entonces la herramienta periodicamente reintenta todas las
114
-
peticiones fallidas hasta que todos los Pods en el nodo afectado son terminados ó hasta que el tiempo de espera,
113
+
peticiones fallidas hasta que todos los Pods en el nodo afectado son terminados o hasta que el tiempo de espera,
115
114
que puede ser configurado, es alcanzado.
116
115
117
116
Un PDB especifica el número de réplicas que una aplicación puede tolerar, relativo a cuantas
118
117
se pretende tener. Por ejemplo, un Deployment que tiene un `.spec.replicas: 5` se
119
118
supone que tiene 5 Pods en cualquier momento. Si su PDB permite tener 4 a la vez,
120
-
entonces la API de Desalojo va a permitir interrupciones voluntarias de un (pero no a dos) Pod a la vez.
119
+
entonces la API de Desalojo va a permitir interrupciones voluntarias de uno (pero no de dos) Pod a la vez.
121
120
122
-
El grupo de Pods que comprende a la aplicación esta especificada usando una etiqueta selectora, la misma
121
+
El grupo de Pods que comprende a la aplicación está especificado usando una etiqueta selectora, la misma
123
122
que es usada por el controlador de aplicación (deployment, stateful-set, etc).
124
123
125
-
El numero de Pods "deseado" es calculado a partir de `.spec.replicas`de el recurso de Workload
126
-
que es manejado para esos Pods. El plano de control descubre el recurso Workload perteneciente a el
127
-
examinando las `.metadata.ownerReferences` del Pod.
124
+
El número de Pods "deseado" es calculado a partir de `.spec.replicas`del recurso de Workload
125
+
que es manejado para esos Pods. El plano de control descubre el recurso Workload perteneciente al
126
+
examinar las `.metadata.ownerReferences` del Pod.
128
127
129
128
Las [Interrupciones Involuntarias](#voluntary-and-involuntary-disruptions) no pueden ser prevenidas por los PDB; pero si
130
-
son contabilizadas a partir este presupuesto.
129
+
son contabilizadas a partir de este presupuesto.
131
130
132
-
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)
131
+
Los Pods que son borrados o no están 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)
133
132
no están limitados por los PDBs cuando se hacen actualizaciones continuas. En cambio, la administración de fallas
134
-
durante la actualización de la aplicación es configurada en la especificación para este recurso Workload específico.
133
+
durante la actualización de la aplicación está configurada en la especificación para este recurso Workload específico.
135
134
136
-
Cuando un Pod es quitado usando la API de desalojo, este es
137
-
[terminado](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination) correctamente, haciendo honor al
138
-
`terminationGracePeriodSeconds` configurado en su [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core).
135
+
Cuando un Pod es eliminado usando la API de desalojo, este es
136
+
[terminado](/docs/concepts/workloads/Pods/pod-lifecycle/#pod-termination) correctamente, haciendo honor al
137
+
`terminationGracePeriodSeconds` configurado en su [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#Podspec-v1-core).
139
138
140
139
## Ejemplo de Presupuesto de Interrupción de POD {#pdb-example}
141
140
142
141
Considere un clúster con 3 nodos, `nodo-1` hasta `nodo-3`.
143
-
El clúster esta corriendo varias aplicaciones. Uno de ellos tiene 3 replicas, que llamaremos
142
+
El clúster está ejecutando varias aplicaciones. Uno de ellos tiene 3 replicas, que llamaremos
144
143
`pod-a`, `pod-b`, y `pod-c`. Otro Pod no relacionado y sin PDB, llamado `pod-x`, también se muestra.
145
144
146
-
Inicialmente los pods estan distribuidos de esta manera:
145
+
Inicialmente los Pods están distribuidos de esta manera:
147
146
148
147
149
148
| nodo-1 | nodo-2 | nodo-3 |
@@ -152,110 +151,110 @@ Inicialmente los pods estan distribuidos de esta manera:
152
151
| pod-x *available*|||
153
152
154
153
Los 3 Pods son parte de un Deployment, ellos colectivamente tienen un PDB que requiere
155
-
que por lo menos 2 de los 3 Pods esten disponibles todo el tiempo.
154
+
que por lo menos 2 de los 3 Pods estén disponibles en todo momento.
156
155
157
-
Por ejemplo, supongamos que el administrador del clúster quiere reiniciar para actualizar el kernel y arreglar un bug.
158
-
El administrador del clúster primero intenta desocupar el `nodo-1` usando el comando `kubectl drain`.
159
-
La herramienta intenta desalojar a los pods`pod-a` y `pod-x`. Esto tiene éxito inmediatamente.
160
-
Ambos Pods van al estado `terminating` al mismo tiempo.
161
-
Pone al clúster en el siguiente estado:
156
+
Por ejemplo, supongamos que el administrador del clúster quiere reiniciar para actualizar el kernel y solucionar un error.
157
+
El administrador del clúster primero intenta drenar el `nodo-1` usando el comando `kubectl drain`.
158
+
La herramienta intenta drenar los Pods`pod-a` y `pod-x`. Esto tiene éxito inmediatamente.
159
+
Ambos Pods pasan al estado `terminating` al mismo tiempo.
El Deployment detecta que uno de los Pods esta terminando, entonces crea un reemplazo
169
-
llamado `pod-d`. Como el `nodo-1`esta bloqueado, el pod termina en otro nodo. Algo más, adicionalmente
170
-
a creado el pod `pod-y` como un reemplazo del`pod-x` .
167
+
El Deployment detecta que uno de los Pods está terminando, entonces crea un reemplazo
168
+
llamado `pod-d`. Dado que el `nodo-1`está bloqueado, el pod se inicia en otro nodo. Además,
169
+
se crea el pod `pod-y` como reemplazo de`pod-x`.
171
170
172
-
(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.)
171
+
(Nota: para un StatefulSet, `pod-a`, que debería llamarse algo como `pod-0`, debe terminar completamente antes de su reemplazo, que también se llama`pod-0` pero tiene un UID diferente, puede ser creado. De lo contrario, el ejemplo también se aplica a un StatefulSet).
0 commit comments