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

more changes and final revision done

Browse Source
This commit is contained in:
gamba47
2022-01-02 23:18:31 -03:00
parent eab7b6cbdc
commit 2eb10e943c
1 changed files with 144 additions and 137 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/es/docs/concepts/workloads/pods/disruptions.md
+143 -136
View File
@@ -12,58 +12,57 @@ Esta guía es para los dueños de aplicaciones que quieren crear
aplicaciones con alta disponibilidad y que necesitan entender aplicaciones con alta disponibilidad y que necesitan entender
que tipos de interrupciones pueden suceder en los Pods. que tipos de interrupciones pueden suceder en los Pods.
Tambien es para los administradores de clusters que quieren aplicacar acciones También es para los administradores de clústers que quieren aplicar acciones
automáticas en sus clusters, como actualizar o autoescalar los clusters. automáticas en sus clústers, cómo actualizar o autoescalar los clústers.
<!-- body --> <!-- body -->
## Interrupciones voluntarias e involuntarias ## Interrupciones voluntarias e involuntarias
Los pods no desaparecen hasta que algo (una persona o un controlador) los destruye Los pods no desaparecen hasta que algo (una persona o un controlador) los destruye
ó hay problemas de hardware o del software que son inevitables. ó hay problemas de hardware ó del software que son inevitables.
Nosotros llamamos esos casos inevitables *interrupciones involuntarias* a Nosotros llamamos a esos casos inevitables *interrupciones involuntarias* de
una aplicación. Algunos ejemplos: una aplicación. Algunos ejemplos:
- Una falla en en hardware de la máquina fisica del nodo - Una falla en en hardware de la máquina física del nodo
- Un administrador del cluster borra una VM (instancia) por error - Un administrador del clúster borra una VM (instancia) por error
- El proveedor cloud o el hypervisor falla y hace desaparecer la VM - El proveedor cloud o el hypervisor falla y hace desaparecer la VM
- Un kernel panic - Un kernel panic
- El nodo desaparece del cluster por un problema de red que lo separa del cluster - El nodo desaparece del clúster por un problema de red que lo separa del clúster
- Una remoción del pod porque el nodo esta [fuera-de-recursos](/docs/concepts/scheduling-eviction/node-pressure-eviction/). - Una remoción del pod porque el nodo esta [sin-recursos-suficientes](/docs/concepts/scheduling-eviction/node-pressure-eviction/).
```No se si es correcto el termino remoción, porque la traducción sería desalojo pero no me gusta tanto```
A excepción de la condición fuera-de-recursos, todas estas condiciones A excepción de la condición sin-recursos-suficientes, todas estas condiciones
deben ser familiares para la mayoría de los usuarios, no son específicas deben ser familiares para la mayoría de los usuarios, no son específicas
de Kubernetes de Kubernetes
Nosotros llamamos a los otros casos *interrupciones voluntarias*. Estas incluyen Nosotros llamamos a los otros casos *interrupciones voluntarias*. Estas incluyen
las acciones iniciadas por el dueño de la aplicación y aquellas iniciadas por el Administrador las acciones iniciadas por el dueño de la aplicación y aquellas iniciadas por el Administrador
del Cluster. Las acciones típicas de los dueños de la aplicación incluye: del Clúster. Las acciones típicas de los dueños de la aplicación incluye:
- borrar el deployment o otro controlador que maneja el pod - borrar el deployment o otro controlador que maneja el pod
- actualizar el deployment del pod que causa un reinicio - actualizar el deployment del pod que causa un reinicio
- borrar un pod (por ejemplo por accidente) - borrar un pod (por ejemplo por accidente)
Las acciones del administrador del cluster incluyen: Las acciones del administrador del clúster incluyen:
- [Drenar un nodo](/docs/tasks/administer-cluster/safely-drain-node/) para reparar o actualizar. - [Drenar un nodo](/docs/tasks/administer-clúster/safely-drain-node/) para reparar o actualizar.
- Drenar un nodo del cluster para reducir el cluster (aprenda acerca de [Autoescalamiento de Cluster](https://github.com/kubernetes/autoscaler/#readme) - Drenar un nodo del clúster para reducir el clúster (aprenda acerca de [Autoescalamiento de Clúster](https://github.com/kubernetes/autoscaler/#readme)
). ).
- Remover un pod de un nodo para permitir que otra cosa pueda ingresar a ese nodo. - Remover un pod de un nodo para permitir que otra cosa pueda ingresar a ese nodo.
Estas acciones pueden ser realizadas directamente por el administrador del cluster, por Estas acciones pueden ser realizadas directamente por el administrador del clúster, por
tareas automaticas del administrador del cluster ó por el proveedor del cluster. tareas automaticas del administrador del clúster ó por el proveedor del clúster.
```Si puden revisar esta frase de arriba sería muy bueno, no me gusta como ha quedado``` ```Si puden revisar esta frase de arriba sería muy bueno, no me gusta como ha quedado```
Consulte al administrador de su cluster, a su proveedor cloud ó la documentación de su distribución Consulte al administrador de su clúster, a su proveedor cloud ó la documentación de su distribución
para determinar si alguno de estas interrupciones voluntarias están habilitadas en su cluster. para determinar si alguna de estas interrupciones voluntarias están habilitadas en su clúster.
Si no estan habilitadas, puede saltear la creación del presupuesto de Interrupción de Pods. Si no estan habilitadas, puede saltear la creación del presupuesto de Interrupción de Pods.
```Si puden revisar esta frase de arriba sería muy bueno, no me gusta como ha quedado``` ```Si puden revisar esta frase de arriba sería muy bueno, no me gusta como ha quedado```
{{< caution >}} {{< caution >}}
Not all voluntary disruptions are constrained by Pod Disruption Budgets. For example, No todas las interrupciones voluntarias son consideradas por el presupuesto de interrupción de Pods. Por ejemplo,
deleting deployments or pods bypasses Pod Disruption Budgets. borrar un deployment o pods que evitan el uso del presupuesto.
{{< /caution >}} {{< /caution >}}
## Tratando con las interrupciones ## Tratando con las interrupciones
@@ -73,193 +72,201 @@ Estas son algunas de las maneras para mitigar las interrupciones involuntarias:
- Asegurarse que el pod [solicite los recursos](/docs/tasks/configure-pod-container/assign-memory-resource) que necesita. - Asegurarse que el pod [solicite los recursos](/docs/tasks/configure-pod-container/assign-memory-resource) que necesita.
- Replique su aplicación su usted necesita alta disponiblidad. (Aprenda sobre correr aplicaciones replicadas - Replique su aplicación su usted necesita alta disponiblidad. (Aprenda sobre correr aplicaciones replicadas
[stateless](/docs/tasks/run-application/run-stateless-application-deployment/) [stateless](/docs/tasks/run-application/run-stateless-application-deployment/)
y [stateful](/docs/tasks/run-application/run-replicated-stateful-application/) applications.) y [stateful](/docs/tasks/run-application/run-replicated-stateful-application/)
- Incluso, para alta disponiblidad cuando corre aplicaciones replicadas, - Incluso, para alta disponiblidad cuando corre aplicaciones replicadas,
extendia aplicaciones por varios racks (usando extendia aplicaciones por varios racks (usando
[anti-affinity](/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity)) [anti-affinity](/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity))
o usando zonas (si usa un [cluster multi-zona](/docs/setup/multiple-zones).) o usando zonas (si usa un [clúster multi-zona](/docs/setup/multiple-zones).)
La frecuencia de las interrupciones voluntarias varía. En un cluster basico de Kubernetes, no hay La frecuencia de las interrupciones voluntarias varía. En un clúster basico de Kubernetes, no hay
interrupciones voluntarias automáticas (solo el usuario las genera). Sin embargo, su administrador del cluster o proveedor de hosting interrupciones voluntarias automáticas (solo el usuario las genera). Sin embargo, su administrador del clúster o proveedor de hosting
puede correr algun servicio adicional que pueda causar estas interrupciones voluntarias. Por ejemplo, puede correr algun servicio adicional que pueda causar estas interrupciones voluntarias. Por ejemplo,
desplegando una actualización de software en los nodos puede causar interrupciones. También, algunas implementaciones desplegando una actualización de software en los nodos puede causar interrupciones. También, algunas implementaciones
de clusters con autoescalamiento de nodos puede causar interrupciones para defragmentar o compactar los nodos. de clústers con autoescalamiento de nodos puede causar interrupciones para defragmentar o compactar los nodos.
Su administrador de cluster o proveedor de hosting debe tener documentado cual es el nivel de interrupciones Su administrador de clúster o proveedor de hosting debe tener documentado cuál es el nivel de interrupciones
voluntarias esperadas, si las hay. Ciertas opciones de configuración, como ser voluntarias esperadas, sí las hay. Ciertas opciones de configuración, como ser
[usar PriorityClasses](/docs/concepts/scheduling-eviction/pod-priority-preemption/) [usar PriorityClasses](/docs/concepts/scheduling-eviction/pod-priority-preemption/)
en las spec de su pod pueden tambien causar interrupciones voluntarias (o involuntarias). en las spec de su pod pueden tambien causar interrupciones voluntarias (o involuntarias).
## Pod disruption budgets ## Presupuesto de Interrupción de Pods
{{< feature-state for_k8s_version="v1.21" state="stable" >}} {{< feature-state for_k8s_version="v1.21" state="stable" >}}
Kubernetes offers features to help you run highly available applications even when you Kubernetes ofrece carácteristicas para ayudar a ejecutar aplicaciones con alta disponibliidad, incluso cuando usted
introduce frequent voluntary disruptions. introduce frecuentes interrupciones voluntarias.
As an application owner, you can create a PodDisruptionBudget (PDB) for each application. ```Necesito que me digan si aca ponemos en ingles PodDisruptionBudget o se hace la tradución```
A PDB limits the number of Pods of a replicated application that are down simultaneously from 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.
voluntary disruptions. For example, a quorum-based application would Un PDB limita el numero de Pods de una aplicación replicada, que estan caídos de manera simultánea por
like to ensure that the number of replicas running is never brought below the interrupciones voluntarias. Por ejemplo, una aplicación basada en quórum puede
number needed for a quorum. A web front end might want to asegurarse que el número de réplicas corriendo nunca es menor al
ensure that the number of replicas serving load never falls below a certain número necesitado para obtener el quórum. Un front de una web puede querer
percentage of the total. asegurarse que el número de réplicas atendiendo al tráfico nunca puede caer bajo un cierto
porcentaje del total.
Cluster managers and hosting providers should use tools which Los administradores del clúster y proveedores de hosting pueden usar herramientas que
respect PodDisruptionBudgets by calling the [Eviction API](/docs/tasks/administer-cluster/safely-drain-node/#eviction-api) repeten el presupuesto de interrupción de pods utilizando la [API de Desalojo](/docs/tasks/administer-clúster/safely-drain-node/#eviction-api)
instead of directly deleting pods or deployments. en vez de directamente borrar pods o deployments.
For example, the `kubectl drain` subcommand lets you mark a node as going out of Por ejemplo, el subcomando `kubectl drain` le permite marcar un nodo a un modo fuera de
service. When you run `kubectl drain`, the tool tries to evict all of the Pods on servicio. Cuando se ejecuta `kubectl drain`, la herramienta trata de quitar a todos los Pods en
the Node you're taking out of service. The eviction request that `kubectl` submits on el nodo que se esta dejando fuera de servicio. El pedido de desalojo que `kubectl` solicita en
your behalf may be temporarily rejected, so the tool periodically retries all failed su nombre puede ser temporalmente denegado, entonces la herramienta periodicamente reintenta todas las
requests until all Pods on the target node are terminated, or until a configurable timeout peticiones fallidas hasta que todos los Pods en el nodo afectado son terminados ó hasta que el tiempo de espera,
is reached. que puede ser configurado, es alcanzado.
A PDB specifies the number of replicas that an application can tolerate having, relative to how Un PDB especifica el número de réplicas que una aplicación puede tener, relativo a cuantos
many it is intended to have. For example, a Deployment which has a `.spec.replicas: 5` is se pretende tener. Por ejemplo, un Deployment que tiene un `.spec.replicas: 5` se
supposed to have 5 pods at any given time. If its PDB allows for there to be 4 at a time, supone que tiene 5 pods en cualquier momento. Si su PDB permite tener 4 por a la vez,
then the Eviction API will allow voluntary disruption of one (but not two) pods at a time. entonces la API de Desalojo va a permitir interrupciones voluntarias a uno (pero no a dos) pods.
The group of pods that comprise the application is specified using a label selector, the same El grupo de pods que comprende a la aplicación esta especificada usando una etiqueta selectora, la mismma
as the one used by the application's controller (deployment, stateful-set, etc). que es usada por el controlador de aplicación (deployment, stateful-set, etc).
```No puedo darle sentido a estas lineas, necesito ayuda```
The "intended" number of pods is computed from the `.spec.replicas` of the workload resource The "intended" number of pods is computed from the `.spec.replicas` of the workload resource
that is managing those pods. The control plane discovers the owning workload resource by that is managing those pods. The control plane discovers the owning workload resource by
examining the `.metadata.ownerReferences` of the Pod. examining the `.metadata.ownerReferences` of the Pod.
[Involuntary disruptions](#voluntary-and-involuntary-disruptions) cannot be prevented by PDBs; however they Las [Interrupciones Involuntarias](#voluntary-and-involuntary-disruptions) no pueden ser prevenidas por los PDB; pero si
do count against the budget. son contabilizadas contra este presupuesto.
Pods which are deleted or unavailable due to a rolling upgrade to an application do count Los Pods que son borrados o no estan disponibles por una actualización continua de una aplicación cuentan
against the disruption budget, but workload resources (such as Deployment and StatefulSet) contra el presupuesto de interrupciones, pero los recursos de trabajo (como los Deployments y StatefulSet)
are not limited by PDBs when doing rolling upgrades. Instead, the handling of failures no están limitados por los PDBs cuando hacen actualizaciones continuas. En cambio, el manejo de fallas
during application updates is configured in the spec for the specific workload resource. mientras dura la actualización de la aplicación es configurado en el spec de este recurso específico.
```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
o hace falta```
When a pod is evicted using the eviction API, it is gracefully Cuando un pod es quitado usando la API de desarolojo, este es
[terminated](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination), honoring the [terminado](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination) correctamente, haciendo honor al
`terminationGracePeriodSeconds` setting in its [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core). `terminationGracePeriodSeconds` configurado en su [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core).
```Arriba no hago la traducción de PodeSpec porque no se si sería necesario```
## PodDisruptionBudget example {#pdb-example} ## Ejemplo de Presupuesto de Interrupción de POD {#pdb-example}
Consider a cluster with 3 nodes, `node-1` through `node-3`. Considere un clúster con 3 nodos, `nodo-1` hasta `nodo-3`.
The cluster is running several applications. One of them has 3 replicas initially called El clúster esta corriendo varias aplicaciones. Uno de ellos tiene 3 replicas, que llamaremos
`pod-a`, `pod-b`, and `pod-c`. Another, unrelated pod without a PDB, called `pod-x`, is also shown. `pod-a`, `pod-b`, and `pod-c`. Otro pod no relacionado y sin PDB, llamado `pod-x`, tambien se muestra.
Initially, the pods are laid out as follows:
| node-1 | node-2 | node-3 | Inicialmente los pods estan distribuidos de esta manera:
| nodo-1 | nodo-2 | nodo-3 |
|:--------------------:|:-------------------:|:------------------:| |:--------------------:|:-------------------:|:------------------:|
| pod-a *available* | pod-b *available* | pod-c *available* | | pod-a *available* | pod-b *available* | pod-c *available* |
| pod-x *available* | | | | pod-x *available* | | |
All 3 pods are part of a deployment, and they collectively have a PDB which requires Los 3 pods son parte de un deployment, ellos colectivamente tienen un PDB que requiere
there be at least 2 of the 3 pods to be available at all times. que por lo menos 2 de los 3 pods esten disponibles todo el tiempo.
For example, assume the cluster administrator wants to reboot into a new kernel version to fix a bug in the kernel. Por ejemplo, supongamos que el administrador del clúster quiere reiniciar para actualizar el kernel y arreglar un bug.
The cluster administrator first tries to drain `node-1` using the `kubectl drain` command. El administrador del clúster primero intenta desocupar el `nodo-1` usando el comando `kubectl drain`.
That tool tries to evict `pod-a` and `pod-x`. This succeeds immediately. La herramienta intenta desalojar a los pods `pod-a` y `pod-x`. Esto tiene éxito inmediatamente.
Both pods go into the `terminating` state at the same time. Ambos pods van al estado `terminating` al mismo tiempo.
This puts the cluster in this state: Pone al clúster en el siguiente estado:
| node-1 *draining* | node-2 | node-3 | | nodo-1 *desalojando* | nodo-2 | nodo-3 |
|:--------------------:|:-------------------:|:------------------:| |:--------------------:|:-------------------:|:------------------:|
| pod-a *terminating* | pod-b *available* | pod-c *available* | | pod-a *terminating* | pod-b *available* | pod-c *available* |
| pod-x *terminating* | | | | pod-x *terminating* | | |
The deployment notices that one of the pods is terminating, so it creates a replacement El deployment detecta que uno de los pods esta terminando, entonces crea un reemplazo
called `pod-d`. Since `node-1` is cordoned, it lands on another node. Something has llamado `pod-d`. Como el `nodo-1` esta bloqueado, el pod termina en otro nodo. Algo más, adicionalmente
also created `pod-y` as a replacement for `pod-x`. a creado el pod `pod-y` como un reemplazo del `pod-x` .
```Necesita revisión```
(Note: for a StatefulSet, `pod-a`, which would be called something like `pod-0`, would need (Note: for a StatefulSet, `pod-a`, which would be called something like `pod-0`, would need
to terminate completely before its replacement, which is also called `pod-0` but has a to terminate completely before its replacement, which is also called `pod-0` but has a
different UID, could be created. Otherwise, the example applies to a StatefulSet as well.) different UID, could be created. Otherwise, the example applies to a StatefulSet as well.)
Now the cluster is in this state: Ahora el clúster esta en este estado:
| node-1 *draining* | node-2 | node-3 | | nodo-1 *desalojando* | nodo-2 | nodo-3 |
|:--------------------:|:-------------------:|:------------------:| |:--------------------:|:-------------------:|:------------------:|
| pod-a *terminating* | pod-b *available* | pod-c *available* | | pod-a *terminating* | pod-b *available* | pod-c *available* |
| pod-x *terminating* | pod-d *starting* | pod-y | | pod-x *terminating* | pod-d *starting* | pod-y |
At some point, the pods terminate, and the cluster looks like this: En algún punto, los pods finalizan y el clúster se ve de esta forma:
| node-1 *drained* | node-2 | node-3 | | nodo-1 *desalojado* | nodo-2 | nodo-3 |
|:--------------------:|:-------------------:|:------------------:| |:--------------------:|:-------------------:|:------------------:|
| | pod-b *available* | pod-c *available* | | | pod-b *available* | pod-c *available* |
| | pod-d *starting* | pod-y | | | pod-d *starting* | pod-y |
At this point, if an impatient cluster administrator tries to drain `node-2` or En este estado, si un administrador del clúster impaciente intenta desalojar el `nodo-2` ó al
`node-3`, the drain command will block, because there are only 2 available `nodo-3`, el comando drain va a ser bloqueado, porque hay solamente 2 pods disponibles para
pods for the deployment, and its PDB requires at least 2. After some time passes, `pod-d` becomes available. el deployment y el PDB requiere por lo menos 2. Después de pasado un tiempo el `pod-d` esta disponible.
The cluster state now looks like this: El estado del clúster ahora se ve así:
| node-1 *drained* | node-2 | node-3 | | nodo-1 *desalojado* | nodo-2 | nodo-3 |
|:--------------------:|:-------------------:|:------------------:| |:--------------------:|:-------------------:|:------------------:|
| | pod-b *available* | pod-c *available* | | | pod-b *available* | pod-c *available* |
| | pod-d *available* | pod-y | | | pod-d *available* | pod-y |
Now, the cluster administrator tries to drain `node-2`. Ahora, el administrador del clúster desaloja el `nodo-2`.
The drain command will try to evict the two pods in some order, say El comando drain tratará de desalojar a los 2 pods con algún orden, digamos
`pod-b` first and then `pod-d`. It will succeed at evicting `pod-b`. primero el `pod-b` y después el `pod-d`. Va a tener éxito en quitar el `pod-b`.
But, when it tries to evict `pod-d`, it will be refused because that would leave only Pero cuando intente desalojar al `pod-d`, va a ser rechazado porque esto va a dejar solamente
one pod available for the deployment. un pod disponible para el deployment.
The deployment creates a replacement for `pod-b` called `pod-e`. El deployment crea un reemplazo para el `pod-b` llamando `pod-e`.
Because there are not enough resources in the cluster to schedule Porque no hay recursos suficientes disponibles en el clúster para programar
`pod-e` the drain will again block. The cluster may end up in this el `pod-e` el desalojo será bloqueado nuevamente. El clúster va a terminar en este
state: estado:
| node-1 *drained* | node-2 | node-3 | *no node* | | nodo-1 *drained* | nodo-2 | nodo-3 | *sin nodo* |
|:--------------------:|:-------------------:|:------------------:|:------------------:| |:--------------------:|:-------------------:|:------------------:|:------------------:|
| | pod-b *terminating* | pod-c *available* | pod-e *pending* | | | pod-b *terminating* | pod-c *available* | pod-e *pending* |
| | pod-d *available* | pod-y | | | | pod-d *available* | pod-y | |
At this point, the cluster administrator needs to Ahora, el administrador del clúster necesita
add a node back to the cluster to proceed with the upgrade. agregar un nodo de nuevo en el clúster para continuar con la actualización.
You can see how Kubernetes varies the rate at which disruptions Ustede puede ver como Kubernetes varia la tasa a la que las interrupciones
can happen, according to: pueden suceder, en función de:
- how many replicas an application needs - cuantas réplicas una aplicación necesita
- how long it takes to gracefully shutdown an instance - cuanto toma apagar una instancia de manera correcta
- how long it takes a new instance to start up - cuanto tiempo toma que una nueva instancia inicie
- the type of controller - el tipo de controlador
- the cluster's resource capacity - la capacidad de recursos del clúster
## Separating Cluster Owner and Application Owner Roles ## Separando al dueño del Clúster y los roles de dueños de la Aplicación
Often, it is useful to think of the Cluster Manager Muchas veces es útil pensar en el Administrador del Clúster
and Application Owner as separate roles with limited knowledge y al dueño de la aplicación como roles separados con conocimiento limitado
of each other. This separation of responsibilities el uno del otro. Esta separación de responsabilidades
may make sense in these scenarios: puede tener sentido en estos escenarios:
- when there are many application teams sharing a Kubernetes cluster, and - Cuando hay muchas equipos con aplicaciones compartiendo un clúster de Kubernetes y
there is natural specialization of roles hay una especialización natural de roles
- when third-party tools or services are used to automate cluster management - Cuando una herramienta de terceros o servicio es usado para automatizar el control del clúster
Pod Disruption Budgets support this separation of roles by providing an El presupuesto de interrupción de pods soporta esta separación de roles, proveyendo
interface between the roles. una interface entre los roles.
If you do not have such a separation of responsibilities in your organization, Si no se tiene tal separación de responsabilidades en la organización,
you may not need to use Pod Disruption Budgets. posiblemente no se necesite el Presupuesto de Interrupción de Pods.
## How to perform Disruptive Actions on your Cluster ## Como realizar Acciones Disruptivas en el Clúster
If you are a Cluster Administrator, and you need to perform a disruptive action on all Si usted es el Administrador del Clúster y necesita realizar una acción disruptiva en todos
the nodes in your cluster, such as a node or system software upgrade, here are some options: los nodos en el clúster, como ser un upgrade de nodo o de software, estas son algunas de las opciones:
- Accept downtime during the upgrade. - Aceptar el tiempo sin funcionar mientras dura el upgrade.
- Failover to another complete replica cluster. - Conmutar a otra replica completa del clúster.
- No downtime, but may be costly both for the duplicated nodes - No hay tiempo sin funcionar, pero puede ser costoso tener duplicados los nodos
and for human effort to orchestrate the switchover. y tambien un esfuerzo humano para orquestar dicho cambio.
- Write disruption tolerant applications and use PDBs. - Escribir la toleracia a la falla de la aplicación y usar PDBs.
- No downtime. - No hay tiempo sin funcionar.
- Minimal resource duplication. - Duplicación de recursos mínimo.
- Allows more automation of cluster administration. - Permite mucha más automatización de la administración del clúster.
- Writing disruption-tolerant applications is tricky, but the work to tolerate voluntary - Escribir aplicaciones que tengan tolerancia a fallas es complicado, pero el trabajo para tolerar interrupciones
disruptions largely overlaps with work to support autoscaling and tolerating involuntarias, largamente se sobrepone con el trabajo que es dar soporte a autoescalamientos y tolerar
involuntary disruptions. interrupciones involuntarias.
@@ -267,10 +274,10 @@ the nodes in your cluster, such as a node or system software upgrade, here are s
## {{% heading "whatsnext" %}} ## {{% heading "whatsnext" %}}
* Follow steps to protect your application by [configuring a Pod Disruption Budget](/docs/tasks/run-application/configure-pdb/). * Siga los pasos para proteger su aplicación con [configurar el Presupuesto de Interrupciones de Pods](/docs/tasks/run-application/configure-pdb/).
* Learn more about [draining nodes](/docs/tasks/administer-cluster/safely-drain-node/) * Aprenda más sobre [desalojar nodos](/docs/tasks/administer-clúster/safely-drain-node/)
* Learn about [updating a deployment](/docs/concepts/workloads/controllers/deployment/#updating-a-deployment) * Aprenda sobre [actualizar un deployment](/docs/concepts/workloads/controllers/deployment/#updating-a-deployment)
including steps to maintain its availability during the rollout. incluyendo los pasos para mantener su disponibilidad mientras dura la actualización.