From 8ba1d5a6831250471a8721b982826def3238ce7c Mon Sep 17 00:00:00 2001 From: Anyul Rivas Date: Fri, 16 Aug 2024 13:20:41 +0200 Subject: [PATCH] docs: Localize pod lifecycle to Spanish fix pod phase link Update content with #46529 solves #45708 --- .../concepts/workloads/pods/pod-lifecycle.md | 22 +++++++++---------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/content/es/docs/concepts/workloads/pods/pod-lifecycle.md b/content/es/docs/concepts/workloads/pods/pod-lifecycle.md index c1ae1b00a826e..80dbeb7557686 100644 --- a/content/es/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/es/docs/concepts/workloads/pods/pod-lifecycle.md @@ -33,7 +33,7 @@ También puedes inyectar [información de readiness personalizada](#pod-readines Los Pods solo se [programan](/docs/concepts/scheduling-eviction/) una vez en su ciclo de vida; asignar un Pod a un nodo específico se llama _vincular_ (binding, en inglés), y el proceso de seleccionar cuál Pod usar se llama _programar_. Una vez que un Pod está vinculado a un nodo, Kubernetes intenta ejecutar el Pod en ese nodo. -El Pod se ejecuta en ese nodo hasta que termina, o hasta que es [terminado](#pod-termination); if Kubernetes no es capaz de iniciar el Pod en el nodo seleccionado (por ejemplo, si el nodo falla antes que el Pod inicie), entonces ese Pod en particular nunca inicia. +El Pod se ejecuta en ese nodo hasta que termina, o hasta que es [terminado](#pod-termination); si Kubernetes no es capaz de iniciar el Pod en el nodo seleccionado (por ejemplo, si el nodo falla antes que el Pod inicie), entonces ese Pod en particular nunca inicia. Puedes usar [readiness de programación del Pod](/docs/concepts/scheduling-eviction/pod-scheduling-readiness/) para retrasar la programación de un Pod hasta que todas sus _puertas de programación_ sean removidas. Por ejemplo, podrías querer definir un conjunto de Pods, pero solo lanzar la programación una vez que todos los Pods hayan sido creados. @@ -44,12 +44,12 @@ Si falla uno de los contenedores en el Pod, Kubernetes puede intentar reiniciar Para saber más, lea [cómo los Pods manejan los errores del contenedor](#container-restarts). Sin embargo, los Pods pueden fallar de una manera que el clúster no puede recuperar, y en ese caso -Kubernetes no intenta sanar el Pod más; en su lugar, Kubernetes elimina el +Kubernetes no intenta más sanar el Pod; en su lugar, Kubernetes elimina el Pod y confía en otros componentes para proporcionar una curación automática. Si un Pod está programado para un {{< glossary_tooltip text="nodo" term_id="node" >}} y ese nodo luego falla, el Pod se trata como no saludable y Kubernetes eventualmente elimina el Pod. -Un Pod no sobrevivirá a una {{< glossary_tooltip text="evicción" term_id="eviction" >}} debido +Un Pod no sobrevivirá a una {{< glossary_tooltip text="evacuación" term_id="eviction" >}} debido a la falta de recursos o al mantenimiento del Nodo. Kubernetes utiliza una abstracción de nivel superior, llamada @@ -63,20 +63,20 @@ tener el mismo nombre (como en `.metadata.name`) que tenía el Pod antiguo, pero tendría un `.metadata.uid` diferente del Pod antiguo. Kubernetes no garantiza que un reemplazo de un Pod existente sea programado -en el mismo nodo que el antiguo Pod que estaba siendo reemplazado. +en el mismo nodo en el que el antiguo Pod estaba siendo reemplazado. ### Ciclo de vida asociados Cuando se dice que algo tiene la misma vida útil que un Pod, como un -{{< glossary_tooltip term_id="volume" text="volumen" >}}, +{{< glossary_tooltip term_id="volume" text="volúmen" >}}, eso significa que el objeto existe mientras ese Pod específico (con ese UID exacto) exista. Si ese Pod se elimina por cualquier razón, e incluso si se crea un reemplazo idéntico, el objeto relacionado (un volumen, en este ejemplo) también se destruye y se crea nuevamente. -{{< figure src="/images/docs/pod.svg" title="Figura 1." class="diagram-medium" caption="Un Pod de varios contenedores que contiene un extractor de archivos sidecar y un servidor web. El Pod utiliza un volumen efímero emptyDir para almacenamiento compartido entre los contenedores." >}} +{{< figure src="/images/docs/pod.svg" title="Figura 1." class="diagram-medium" caption="Un Pod de varios contenedores que contiene un extractor de archivos sidecar y un servidor web. El Pod utiliza un volumen efímero `emptyDir` para almacenamiento compartido entre los contenedores." >}} -## Fase del Pod +## Fase del Pod {##pod-phase } El campo `status` de un Pod es un objeto [PodStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core) @@ -136,7 +136,7 @@ contenedor. Una vez que el {{< glossary_tooltip text="programador" term_id="kube-scheduler" >}} asigna un Pod a un Nodo, el kubelet inicia creando los contenedores para ese Pod usando un -{{< glossary_tooltip text="espacio de ejecución del contenedor" term_id="container-runtime" >}}. +{{< glossary_tooltip text="runtime del contenedor" term_id="container-runtime" >}}. Hay 3 estados posibles para un contenedor: `Waiting`(esperando), `Running`(en ejecución), y `Terminated`(terminado). Para revisar el estado de los contenedores de un Pod, @@ -177,7 +177,7 @@ de que el contenedor entre en estado `Terminated`. ## Cómo los Pods manejan los problemas con los contenedores {#container-restarts} Kubernetes maneja los fallos de los contenedores dentro de los Pods usando una [política de reinicio, `restartPolicy` en inglés](#restart-policy) definida en la especificación `spec` del Pod. -Esta política determina cómo reacciona Kubernetes cuando los contenedores salen debido a errores u otras razones, lo que sigue la siguiente secuencia: +Esta política determina cómo reacciona Kubernetes cuando los contenedores salen debido a errores u otras razones, que sigue la siguiente secuencia: 1. **Fallo inicial**: Kubernetes intenta un reinicio inmediato basado en la `restartPolicy` del Pod. 1. **Fallos repetidos**: @@ -221,10 +221,10 @@ Los [contenedores sidecar](/docs/concepts/workloads/pods/sidecar-containers/) ignoran el campo `restartPolicy`: en Kubernetes, un sidecar se define como una entrada dentro de `initContainers` que tiene su `restartPolicy` a nivel del contenedor establecido en `Always`. Para contenedores de inicio que finalizan con un error, el kubelet reinicia el -contenedor de inicio if el nivel del Pod `restartPolicy` es `OnFailure` +contenedor de inicio si el nivel del Pod `restartPolicy` es `OnFailure` o `Always`. -Cuando el kubelet está manejando el contenedor se reinicia de acuerdo con la política de reinicio configurada, que solo se aplica a los reinicios que realizan contenedores de +Cuando el kubelet está manejando el contenedor, se reinicia de acuerdo con la política de reinicio configurada, que solo se aplica a los reinicios que realizan contenedores de reemplazo dentro del mismo Pod y ejecutándose en el mismo nodo. Después de que los contenedores en un Pod terminan, el kubelet