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