[es] Correción documentación Network Policy fix

Author: jonathino2590

content/es/docs/concepts/workloads/pods/disruptions.md

@@ -94,7 +94,7 @@ en las especificaciones de su Pod pueden también causar interrupciones voluntar
 Kubernetes ofrece carácteristicas para ayudar a ejecutar aplicaciones con alta disponibliidad, incluso cuando usted
 introduce interrupciones voluntarias frecuentes.
 
-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.
+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
@@ -103,68 +103,68 @@ asegurarse que el número de réplicas atendiendo al tráfico nunca puede caer b
 porcentaje del total.
 
 Los administradores del clúster y proveedores de hosting pueden usar herramientas que
-respeten el presupuesto de interrupción de pods utilizando la [API de Desalojo](/docs/tasks/administer-cluster/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-cluster/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
+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. 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 o hasta que el tiempo de espera,
+peticiones fallidas hasta que todos los Pods en el nodo afectado son terminados o 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 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 a la vez,
+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 uno (pero no de dos) Pod a la vez.
 
-El grupo de pods que comprende a la aplicación está especificado usando una etiqueta selectora, la misma
+El grupo de Pods que comprende a la aplicación está especificado usando una etiqueta selectora, la misma
 que es usada por el controlador de aplicación (deployment, stateful-set, etc).
 
-El número de pods "deseado" es calculado a partir de `.spec.replicas` del recurso de Workload
-que es manejado para esos pods. El plano de control descubre el recurso Workload perteneciente al
+El número de Pods "deseado" es calculado a partir de `.spec.replicas` del recurso de Workload
+que es manejado para esos Pods. El plano de control descubre el recurso Workload perteneciente al
 examinar las `.metadata.ownerReferences` del Pod.
 
 Las [Interrupciones Involuntarias](#voluntary-and-involuntary-disruptions) no pueden ser prevenidas por los PDB; pero si
 son contabilizadas a partir de este presupuesto.
 
-Los pods que son borrados o no están disponibles debido a una actualización continua de una aplicación forman parte del presupuesto de interrupciones, pero los recursos Workload (como los Deployments y StatefulSet)
+Los Pods que son borrados o no están disponibles debido a una actualización continua de una aplicación forman parte del presupuesto de interrupciones, pero los recursos Workload (como los Deployments y StatefulSet)
 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 está configurada en la especificación para este recurso Workload específico.
 
 Cuando un Pod es eliminado 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).
+[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).
 
 ## 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 está ejecutando varias aplicaciones. Uno de ellos tiene 3 replicas, que llamaremos
 `pod-a`, `pod-b`, y `pod-c`. Otro Pod no relacionado y sin PDB, llamado `pod-x`, también se muestra.
 
-Inicialmente los pods están distribuidos de esta manera:
+Inicialmente los Pods están distribuidos de esta manera:
 
 
 |       nodo-1         |       nodo-2        |       nodo-3       |
 |:--------------------:|:-------------------:|:------------------:|
 | 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 estén disponibles en todo momento.
+Los 3 Pods son parte de un Deployment, ellos colectivamente tienen un PDB que requiere
+que por lo menos 2 de los 3 Pods estén disponibles en todo momento.
 
 Por ejemplo, supongamos que el administrador del clúster quiere reiniciar para actualizar el kernel y solucionar un error.
 El administrador del clúster primero intenta drenar el `nodo-1` usando el comando `kubectl drain`.
-La herramienta intenta drenar los pods `pod-a` y `pod-x`. Esto tiene éxito inmediatamente.
-Ambos pods pasan al estado `terminating` al mismo tiempo.
+La herramienta intenta drenar los Pods `pod-a` y `pod-x`. Esto tiene éxito inmediatamente.
+Ambos Pods pasan al estado `terminating` al mismo tiempo.
 Esto pone al clúster en el siguiente estado:
 
 | nodo-1 *draining* |       nodo-2        |       nodo-3       |
 |:--------------------:|:-------------------:|:------------------:|
 | pod-a  *terminating* | pod-b *available*   | pod-c *available*  |
 | pod-x  *terminating* |                     |                    |
 
-El Deployment detecta que uno de los pods está terminando, entonces crea un reemplazo
+El Deployment detecta que uno de los Pods está terminando, entonces crea un reemplazo
 llamado `pod-d`. Dado que el `nodo-1` está bloqueado, el pod se inicia en otro nodo. Además,
 se crea el pod `pod-y` como reemplazo de `pod-x`.
 
@@ -177,15 +177,15 @@ Ahora el clúster está en este estado:
 | pod-a  *terminating* | pod-b *available*   | pod-c *available*  |
 | pod-x  *terminating* | pod-d *starting*    | pod-y *starting*   |
 
-En algún momento, los pods terminan y el clúster se ve así:
+En algún momento, los Pods terminan y el clúster se ve así:
 
 |  nodo-1 *drained* |       nodo-2        |       nodo-3       |
 |:--------------------:|:-------------------:|:------------------:|
 |                      | pod-b *available*   | pod-c *available*  |
 |                      | pod-d *starting*    | pod-y *starting*   |
 
 En este estado, si un administrador del clúster impaciente intenta drenar el `nodo-2` o el 
-`nodo-3`, el comando de drenado será bloqueado, porque solo hay 2 pods disponibles para
+`nodo-3`, el comando de drenado será bloqueado, porque solo hay 2 Pods disponibles para
 el Deployment y el PDB requiere al menos 2. Después de un tiempo, `pod-d` y `pod-y` están disponibles.
 
 El estado del clúster ahora se ve así:
@@ -196,7 +196,7 @@ El estado del clúster ahora se ve así:
 |                      | pod-d *available*   | pod-y *available*  |
 
 Ahora, el administrador del clúster drena el `nodo-2`.
-El comando de drenado intentará drenar los 2 pods en algún orden, digamos
+El comando de drenado intentará drenar los 2 Pods en algún orden, digamos
 primero `pod-b` y luego `pod-d`. Tendrá éxito en eliminar `pod-b`.
 Pero cuando intente drenar `pod-d`, será rechazado porque eso dejará
 solo un Pod disponible para el Deployment. 
@@ -234,11 +234,11 @@ puede tener sentido en estos escenarios:
   hay una especialización natural de roles
 - Cuando se usa una herramienta de terceros o un servicio para automatizar el control del clúster
 
-El presupuesto de interrupción de pods respalda esta separación de roles, proporcionando
+El presupuesto de interrupción de Pods respalda esta separación de roles, proporcionando
 una interfaz entre los roles.
 
 Si no hay tal separación de responsabilidades en la organización,
-es posible que no sea necesario el Presupuesto de Interrupción de pods.
+es posible que no sea necesario el Presupuesto de Interrupción de Pods.
 
 ## Cómo realizar Acciones Disruptivas en el Clúster
 
@@ -263,7 +263,7 @@ los nodos del clúster, como una actualización de nodo o de software, estas son
 ## {{% heading "whatsnext" %}}
 
 
-* Siga los pasos para proteger su aplicación con [configurar el Presupuesto de Interrupciones de pods](/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/).
 
 * Aprenda más sobre [drenar nodos](/docs/tasks/administer-cluster/safely-drain-node/).