From 05a4ab128adf9dd905a5cb69e88960e4d1e014cc Mon Sep 17 00:00:00 2001 From: Aditya Samant Date: Wed, 10 Jan 2024 08:59:02 +0530 Subject: [PATCH 01/33] Remove hostPort field from the liveness probe examples to align with Kubernetes best practices. --- .../configure-liveness-readiness-startup-probes.md | 3 --- 1 file changed, 3 deletions(-) diff --git a/content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md b/content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md index 4d0b744d7d..9615568d92 100644 --- a/content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md +++ b/content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md @@ -294,7 +294,6 @@ For example: ports: - name: liveness-port containerPort: 8080 - hostPort: 8080 livenessProbe: httpGet: @@ -318,7 +317,6 @@ So, the previous example would become: ports: - name: liveness-port containerPort: 8080 - hostPort: 8080 livenessProbe: httpGet: @@ -542,7 +540,6 @@ spec: ports: - name: liveness-port containerPort: 8080 - hostPort: 8080 livenessProbe: httpGet: From 07438fc7bf9f9e793e231820b2f36a856620f325 Mon Sep 17 00:00:00 2001 From: Junya Okabe Date: Sat, 3 Feb 2024 19:06:35 +0900 Subject: [PATCH 02/33] feat: translate content/ja/releases/notes.md --- content/ja/releases/notes.md | 15 +++++++++++++++ 1 file changed, 15 insertions(+) create mode 100644 content/ja/releases/notes.md diff --git a/content/ja/releases/notes.md b/content/ja/releases/notes.md new file mode 100644 index 0000000000..e3e5d2d9ba --- /dev/null +++ b/content/ja/releases/notes.md @@ -0,0 +1,15 @@ +--- +linktitle: リリースノート +title: ノート +type: docs +description: > + Kubernetesのリリースノート +sitemap: + priority: 0.5 +--- + +リリースノートは、使用しているKubernetesのバージョンに合った[Changelog](https://github.com/kubernetes/kubernetes/tree/master/CHANGELOG)を読むことで確認できます。 +{{< skew currentVersionAddMinor 0 >}}のchangelogを見るには[GitHub](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-{{< skew currentVersionAddMinor 0 >}}.md)を参照してください。 + +またリリースノートは、[relnotes.k8s.io](https://relnotes.k8s.io)上で検索してフィルタリングすることもできます。 +{{< skew currentVersionAddMinor 0 >}}のフィルタリングされたリリースノートを見るには[relnotes.k8s.io](https://relnotes.k8s.io/?releaseVersions={{< skew currentVersionAddMinor 0 >}}.0)を参照してください。 From c771c5da19a16cfdde71c58065e7b7a059dea795 Mon Sep 17 00:00:00 2001 From: jorge-oduber <56175237+jorge-oduber@users.noreply.github.com> Date: Sat, 24 Feb 2024 12:55:48 -0600 Subject: [PATCH 03/33] Create force-delete-stateful-set-pod.md EN to ES --- .../force-delete-stateful-set-pod.md | 109 ++++++++++++++++++ 1 file changed, 109 insertions(+) create mode 100644 content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md diff --git a/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md b/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md new file mode 100644 index 0000000000..80292da3be --- /dev/null +++ b/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md @@ -0,0 +1,109 @@ +--- +reviewers: +- ramrodo +title: Eliminación Forzosa de Pods de StatefulSet +content_type: task +weight: 70 +--- + + +Esta página muestra cómo eliminar Pods que son parte de un +{{< glossary_tooltip text="stateful set" term_id="StatefulSet" >}}, +y explica las consideraciones a tener en cuenta al hacerlo. + +## {{% heading "prerequisitos" %}} + +- Esta es una tarea bastante avanzada y tiene el potencial de violar algunas de las propiedades + inherentes a StatefulSet. +- Antes de proceder, familiarízate con las consideraciones enumeradas a continuación. + + + +## Consideraciones de StatefulSet + +En la operación normal de un StatefulSet, **nunca** hay necesidad de eliminar forzosamente un Pod de StatefulSet. +El [controlador de StatefulSet](/docs/concepts/workloads/controllers/statefulset/) es responsable de +crear, escalar y eliminar miembros del StatefulSet. Intenta asegurar que el número especificado +de Pods desde el ordinal 0 hasta N-1 estén vivos y listos. StatefulSet asegura que, en cualquier momento, +hay como máximo un Pod con una identidad dada corriendo en un clúster. Esto se refiere a la semántica de +*como máximo uno* proporcionada por un StatefulSet. + +La eliminación forzada manual debe realizarse con precaución, ya que tiene el potencial de violar la +semántica de como máximo uno inherente a StatefulSet. Los StatefulSets pueden usarse para ejecutar aplicaciones distribuidas y +agrupadas que necesitan una identidad de red estable y almacenamiento estable. +Estas aplicaciones a menudo tienen configuraciones que dependen de un conjunto de un número fijo de +miembros con identidades fijas. Tener múltiples miembros con la misma identidad puede ser desastroso +y puede llevar a pérdida de datos (por ejemplo, escenario de cerebro dividido en sistemas basados en quórum). + +## Eliminar Pods + +Puedes realizar una eliminación de pod grácil con el siguiente comando: + +```shell +kubectl delete pods +``` + +Para que lo anterior conduzca a una terminación grácil, el Pod no debe especificar un +`pod.Spec.TerminationGracePeriodSeconds` de 0. La práctica de establecer un +`pod.Spec.TerminationGracePeriodSeconds` de 0 segundos es insegura y se desaconseja fuertemente +para los Pods de StatefulSet. La eliminación grácil es segura y garantizará que el Pod +se apague de [manera grácil](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination), antes de que el kubelet elimine el nombre del apiserver. + +Un Pod no se elimina automáticamente cuando un nodo no es accesible. +Los Pods que se ejecutan en un Nodo inaccesible entran en el estado 'Terminating' o 'Unknown' después de un +[tiempo de espera](/docs/concepts/architecture/nodes/#condition). +Los Pods también pueden entrar en estos estados cuando el usuario intenta la eliminación grácil de un Pod +en un Nodo inaccesible. +Las únicas formas en que un Pod en tal estado puede ser eliminado del apiserver son las siguientes: + +- El objeto Node es eliminado (ya sea por ti, o por el [Controlador de Nodo](/docs/concepts/architecture/nodes/#node-controller)).). +- El kubelet en el Nodo no responsivo comienza a responder, mata el Pod y elimina la entrada del apiserver. +- Eliminación forzada del Pod por el usuario. +- +La mejor práctica recomendada es usar el primer o segundo enfoque. Si un Nodo está confirmado +como muerto (por ejemplo, desconectado permanentemente de la red, apagado, etc.), entonces elimina +el objeto Node. Si el Nodo está sufriendo de una partición de red, entonces trata de resolver esto +o espera a que se resuelva. Cuando la partición se cure, el kubelet completará la eliminación +del Pod y liberará su nombre en el apiserver. + +Normalmente, el sistema completa la eliminación una vez que el Pod ya no se está ejecutando en un Nodo, o +el Nodo es eliminado por un administrador. Puedes anular esto forzando la eliminación del Pod. + +### Eliminación Forzosa + +Las eliminaciones forzosas **no** esperan confirmación del kubelet de que el Pod ha sido terminado. +Independientemente de si una eliminación forzosa tiene éxito en matar un Pod, inmediatamente +liberará el nombre del apiserver. Esto permitiría que el controlador de StatefulSet cree un Pod de reemplazo +con esa misma identidad; esto puede llevar a la duplicación de un Pod que aún está en ejecución, +y si dicho Pod todavía puede comunicarse con los otros miembros del StatefulSet, +violará la semántica de como máximo uno que StatefulSet está diseñado para garantizar. + +Cuando eliminas forzosamente un pod de StatefulSet, estás afirmando que el Pod en cuestión nunca +volverá a hacer contacto con otros Pods en el StatefulSet y su nombre puede ser liberado de forma segura para que +se cree un reemplazo. + + +Si quieres eliminar un Pod de forma forzosa usando la versión de kubectl >= 1.5, haz lo siguiente: + +```shell +kubectl delete pods --grace-period=0 --force +``` + +Si estás usando cualquier versión de kubectl <= 1.4, deberías omitir la opción `--force` y usar: + +```shell +kubectl delete pods --grace-period=0 +``` + +Si incluso después de estos comandos el pod está atascado en el estado `Unknown`, usa el siguiente comando para +eliminar el pod del clúster: + +```shell +kubectl patch pod -p '{"metadata":{"finalizers":null}}' +``` + +Siempre realiza la eliminación forzosa de Pods de StatefulSet con cuidado y con pleno conocimiento de los riesgos involucrados. + +## {{% heading "whatsnext" %}} + +Aprende más sobre [depurar un StatefulSet](/docs/tasks/debug/debug-application/debug-statefulset/). From aee81d646df802922de9dacec271c4612f5c7609 Mon Sep 17 00:00:00 2001 From: jorge-oduber <56175237+jorge-oduber@users.noreply.github.com> Date: Sat, 24 Feb 2024 13:07:55 -0600 Subject: [PATCH 04/33] Update force-delete-stateful-set-pod.md --- .../run-application/force-delete-stateful-set-pod.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md b/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md index 80292da3be..38b86cd72d 100644 --- a/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md +++ b/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md @@ -37,22 +37,22 @@ y puede llevar a pérdida de datos (por ejemplo, escenario de cerebro dividido e ## Eliminar Pods -Puedes realizar una eliminación de pod grácil con el siguiente comando: +Puedes realizar una eliminación de pod paulatina con el siguiente comando: ```shell kubectl delete pods ``` -Para que lo anterior conduzca a una terminación grácil, el Pod no debe especificar un +Para que lo anterior conduzca a una terminación paulatina, el Pod no debe especificar un `pod.Spec.TerminationGracePeriodSeconds` de 0. La práctica de establecer un `pod.Spec.TerminationGracePeriodSeconds` de 0 segundos es insegura y se desaconseja fuertemente -para los Pods de StatefulSet. La eliminación grácil es segura y garantizará que el Pod -se apague de [manera grácil](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination), antes de que el kubelet elimine el nombre del apiserver. +para los Pods de StatefulSet. La eliminación paulatina es segura y garantizará que el Pod +se apague de [manera paulatina](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination), antes de que el kubelet elimine el nombre del apiserver. Un Pod no se elimina automáticamente cuando un nodo no es accesible. Los Pods que se ejecutan en un Nodo inaccesible entran en el estado 'Terminating' o 'Unknown' después de un [tiempo de espera](/docs/concepts/architecture/nodes/#condition). -Los Pods también pueden entrar en estos estados cuando el usuario intenta la eliminación grácil de un Pod +Los Pods también pueden entrar en estos estados cuando el usuario intenta la eliminación paulatina de un Pod en un Nodo inaccesible. Las únicas formas en que un Pod en tal estado puede ser eliminado del apiserver son las siguientes: From 4451040c8edf22a260211240ffd144f63689523c Mon Sep 17 00:00:00 2001 From: jorge-oduber <56175237+jorge-oduber@users.noreply.github.com> Date: Mon, 26 Feb 2024 14:22:51 -0600 Subject: [PATCH 05/33] Update content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md Co-authored-by: Victor Morales --- .../docs/tasks/run-application/force-delete-stateful-set-pod.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md b/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md index 38b86cd72d..3a2fa58576 100644 --- a/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md +++ b/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md @@ -8,7 +8,7 @@ weight: 70 Esta página muestra cómo eliminar Pods que son parte de un -{{< glossary_tooltip text="stateful set" term_id="StatefulSet" >}}, +{{< glossary_tooltip text="StatefulSet" term_id="StatefulSet" >}}, y explica las consideraciones a tener en cuenta al hacerlo. ## {{% heading "prerequisitos" %}} From 83c58ad6726d35b6c032f68339c8a16c7e91cd61 Mon Sep 17 00:00:00 2001 From: jorge-oduber <56175237+jorge-oduber@users.noreply.github.com> Date: Mon, 26 Feb 2024 14:23:04 -0600 Subject: [PATCH 06/33] Update content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md Co-authored-by: Victor Morales --- .../docs/tasks/run-application/force-delete-stateful-set-pod.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md b/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md index 3a2fa58576..7b920ed225 100644 --- a/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md +++ b/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md @@ -14,7 +14,7 @@ y explica las consideraciones a tener en cuenta al hacerlo. ## {{% heading "prerequisitos" %}} - Esta es una tarea bastante avanzada y tiene el potencial de violar algunas de las propiedades - inherentes a StatefulSet. + inherentes de StatefulSet. - Antes de proceder, familiarízate con las consideraciones enumeradas a continuación. From a2a6d5ce498345072d914a3118870352f8f3efd5 Mon Sep 17 00:00:00 2001 From: jorge-oduber <56175237+jorge-oduber@users.noreply.github.com> Date: Mon, 26 Feb 2024 14:23:43 -0600 Subject: [PATCH 07/33] Update content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md Co-authored-by: Victor Morales --- .../docs/tasks/run-application/force-delete-stateful-set-pod.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md b/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md index 7b920ed225..f0a9a527c0 100644 --- a/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md +++ b/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md @@ -24,7 +24,7 @@ y explica las consideraciones a tener en cuenta al hacerlo. En la operación normal de un StatefulSet, **nunca** hay necesidad de eliminar forzosamente un Pod de StatefulSet. El [controlador de StatefulSet](/docs/concepts/workloads/controllers/statefulset/) es responsable de crear, escalar y eliminar miembros del StatefulSet. Intenta asegurar que el número especificado -de Pods desde el ordinal 0 hasta N-1 estén vivos y listos. StatefulSet asegura que, en cualquier momento, +de Pods, desde el ordinal 0 hasta N-1, estén vivos y listos. StatefulSet asegura que, en cualquier momento, hay como máximo un Pod con una identidad dada corriendo en un clúster. Esto se refiere a la semántica de *como máximo uno* proporcionada por un StatefulSet. From ea42e59df6e9bb72624f240ce994206c1a02d128 Mon Sep 17 00:00:00 2001 From: jorge-oduber <56175237+jorge-oduber@users.noreply.github.com> Date: Mon, 26 Feb 2024 14:24:07 -0600 Subject: [PATCH 08/33] Update content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md Co-authored-by: Victor Morales --- .../docs/tasks/run-application/force-delete-stateful-set-pod.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md b/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md index f0a9a527c0..838ce8248e 100644 --- a/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md +++ b/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md @@ -25,7 +25,7 @@ En la operación normal de un StatefulSet, **nunca** hay necesidad de eliminar f El [controlador de StatefulSet](/docs/concepts/workloads/controllers/statefulset/) es responsable de crear, escalar y eliminar miembros del StatefulSet. Intenta asegurar que el número especificado de Pods, desde el ordinal 0 hasta N-1, estén vivos y listos. StatefulSet asegura que, en cualquier momento, -hay como máximo un Pod con una identidad dada corriendo en un clúster. Esto se refiere a la semántica de +exista como máximo un Pod con una identidad dada, corriendo en un clúster. Esto se refiere a la semántica de *como máximo uno* proporcionada por un StatefulSet. La eliminación forzada manual debe realizarse con precaución, ya que tiene el potencial de violar la From a918be3bd6b9f0615b8f94e6fde85175f7e2dc54 Mon Sep 17 00:00:00 2001 From: jorge-oduber <56175237+jorge-oduber@users.noreply.github.com> Date: Mon, 26 Feb 2024 14:24:24 -0600 Subject: [PATCH 09/33] Update content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md Co-authored-by: Victor Morales --- .../tasks/run-application/force-delete-stateful-set-pod.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md b/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md index 838ce8248e..9b78c1e5fe 100644 --- a/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md +++ b/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md @@ -66,8 +66,8 @@ el objeto Node. Si el Nodo está sufriendo de una partición de red, entonces tr o espera a que se resuelva. Cuando la partición se cure, el kubelet completará la eliminación del Pod y liberará su nombre en el apiserver. -Normalmente, el sistema completa la eliminación una vez que el Pod ya no se está ejecutando en un Nodo, o -el Nodo es eliminado por un administrador. Puedes anular esto forzando la eliminación del Pod. +Normalmente, el sistema completa la eliminación una vez que el Pod ya no se está ejecutando en un nodo, o +el nodo es eliminado por un administrador. Puedes anular esto forzando la eliminación del Pod. ### Eliminación Forzosa From ae0a344dea81813e78ad92b1f523fe48c7f64f39 Mon Sep 17 00:00:00 2001 From: jorge-oduber <56175237+jorge-oduber@users.noreply.github.com> Date: Mon, 26 Feb 2024 14:24:32 -0600 Subject: [PATCH 10/33] Update content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md Co-authored-by: Victor Morales --- .../docs/tasks/run-application/force-delete-stateful-set-pod.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md b/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md index 9b78c1e5fe..94b3974f9e 100644 --- a/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md +++ b/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md @@ -78,7 +78,7 @@ con esa misma identidad; esto puede llevar a la duplicación de un Pod que aún y si dicho Pod todavía puede comunicarse con los otros miembros del StatefulSet, violará la semántica de como máximo uno que StatefulSet está diseñado para garantizar. -Cuando eliminas forzosamente un pod de StatefulSet, estás afirmando que el Pod en cuestión nunca +Cuando eliminas forzosamente un Pod de StatefulSet, estás afirmando que el Pod en cuestión nunca volverá a hacer contacto con otros Pods en el StatefulSet y su nombre puede ser liberado de forma segura para que se cree un reemplazo. From 4ee8e7fe6f740bed70c4b0de80e9f442ebc5952b Mon Sep 17 00:00:00 2001 From: jorge-oduber <56175237+jorge-oduber@users.noreply.github.com> Date: Mon, 26 Feb 2024 14:24:41 -0600 Subject: [PATCH 11/33] Update content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md Co-authored-by: Victor Morales --- .../docs/tasks/run-application/force-delete-stateful-set-pod.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md b/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md index 94b3974f9e..b4177457e5 100644 --- a/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md +++ b/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md @@ -28,7 +28,7 @@ de Pods, desde el ordinal 0 hasta N-1, estén vivos y listos. StatefulSet asegur exista como máximo un Pod con una identidad dada, corriendo en un clúster. Esto se refiere a la semántica de *como máximo uno* proporcionada por un StatefulSet. -La eliminación forzada manual debe realizarse con precaución, ya que tiene el potencial de violar la +La eliminación manual forzada debe realizarse con precaución, ya que tiene el potencial de violar la semántica de como máximo uno inherente a StatefulSet. Los StatefulSets pueden usarse para ejecutar aplicaciones distribuidas y agrupadas que necesitan una identidad de red estable y almacenamiento estable. Estas aplicaciones a menudo tienen configuraciones que dependen de un conjunto de un número fijo de From f4d5fbd8dd089e559fd6322fb3fa03470f5e8573 Mon Sep 17 00:00:00 2001 From: jorge-oduber <56175237+jorge-oduber@users.noreply.github.com> Date: Mon, 26 Feb 2024 14:24:55 -0600 Subject: [PATCH 12/33] Update content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md Co-authored-by: Victor Morales --- .../docs/tasks/run-application/force-delete-stateful-set-pod.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md b/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md index b4177457e5..51ef9e5272 100644 --- a/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md +++ b/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md @@ -63,7 +63,7 @@ Las únicas formas en que un Pod en tal estado puede ser eliminado del apiserver La mejor práctica recomendada es usar el primer o segundo enfoque. Si un Nodo está confirmado como muerto (por ejemplo, desconectado permanentemente de la red, apagado, etc.), entonces elimina el objeto Node. Si el Nodo está sufriendo de una partición de red, entonces trata de resolver esto -o espera a que se resuelva. Cuando la partición se cure, el kubelet completará la eliminación +o espera a que se resuelva. Cuando la partición se solucione, kubelet completará la eliminación del Pod y liberará su nombre en el apiserver. Normalmente, el sistema completa la eliminación una vez que el Pod ya no se está ejecutando en un nodo, o From 9260a1104712467e8c600467703cc506af333a7c Mon Sep 17 00:00:00 2001 From: jorge-oduber <56175237+jorge-oduber@users.noreply.github.com> Date: Mon, 26 Feb 2024 14:25:03 -0600 Subject: [PATCH 13/33] Update content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md Co-authored-by: Victor Morales --- .../docs/tasks/run-application/force-delete-stateful-set-pod.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md b/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md index 51ef9e5272..053bd8ba6c 100644 --- a/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md +++ b/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md @@ -71,7 +71,7 @@ el nodo es eliminado por un administrador. Puedes anular esto forzando la elimin ### Eliminación Forzosa -Las eliminaciones forzosas **no** esperan confirmación del kubelet de que el Pod ha sido terminado. +Las eliminaciones forzosas **no** esperan confirmación de kubelet de que el Pod ha sido terminado. Independientemente de si una eliminación forzosa tiene éxito en matar un Pod, inmediatamente liberará el nombre del apiserver. Esto permitiría que el controlador de StatefulSet cree un Pod de reemplazo con esa misma identidad; esto puede llevar a la duplicación de un Pod que aún está en ejecución, From bf0b7a8242e2e8dbde61ae41e2f4620c4d30589a Mon Sep 17 00:00:00 2001 From: jorge-oduber <56175237+jorge-oduber@users.noreply.github.com> Date: Mon, 26 Feb 2024 14:25:08 -0600 Subject: [PATCH 14/33] Update content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md Co-authored-by: Victor Morales --- .../docs/tasks/run-application/force-delete-stateful-set-pod.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md b/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md index 053bd8ba6c..4d8dbd1783 100644 --- a/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md +++ b/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md @@ -96,7 +96,7 @@ kubectl delete pods --grace-period=0 ``` Si incluso después de estos comandos el pod está atascado en el estado `Unknown`, usa el siguiente comando para -eliminar el pod del clúster: +eliminar el Pod del clúster: ```shell kubectl patch pod -p '{"metadata":{"finalizers":null}}' From 0bb479054fec2d22dd81ec96a703ec3f0548c305 Mon Sep 17 00:00:00 2001 From: jorge-oduber <56175237+jorge-oduber@users.noreply.github.com> Date: Mon, 26 Feb 2024 14:25:19 -0600 Subject: [PATCH 15/33] Update content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md Co-authored-by: Victor Morales --- .../docs/tasks/run-application/force-delete-stateful-set-pod.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md b/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md index 4d8dbd1783..d83aa853ce 100644 --- a/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md +++ b/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md @@ -29,7 +29,7 @@ exista como máximo un Pod con una identidad dada, corriendo en un clúster. Est *como máximo uno* proporcionada por un StatefulSet. La eliminación manual forzada debe realizarse con precaución, ya que tiene el potencial de violar la -semántica de como máximo uno inherente a StatefulSet. Los StatefulSets pueden usarse para ejecutar aplicaciones distribuidas y +semántica de como máximo uno, inherente a StatefulSet. Los StatefulSets pueden usarse para ejecutar aplicaciones distribuidas y agrupadas que necesitan una identidad de red estable y almacenamiento estable. Estas aplicaciones a menudo tienen configuraciones que dependen de un conjunto de un número fijo de miembros con identidades fijas. Tener múltiples miembros con la misma identidad puede ser desastroso From 3eeb60496a864991378b2f316edd64a9c52c24cd Mon Sep 17 00:00:00 2001 From: jorge-oduber <56175237+jorge-oduber@users.noreply.github.com> Date: Mon, 26 Feb 2024 14:25:35 -0600 Subject: [PATCH 16/33] Update content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md Co-authored-by: Victor Morales --- .../docs/tasks/run-application/force-delete-stateful-set-pod.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md b/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md index d83aa853ce..8a3088f7e2 100644 --- a/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md +++ b/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md @@ -45,7 +45,7 @@ kubectl delete pods Para que lo anterior conduzca a una terminación paulatina, el Pod no debe especificar un `pod.Spec.TerminationGracePeriodSeconds` de 0. La práctica de establecer un -`pod.Spec.TerminationGracePeriodSeconds` de 0 segundos es insegura y se desaconseja fuertemente +`pod.Spec.TerminationGracePeriodSeconds` de 0 segundos es insegura y se desaconseja rotundamente para los Pods de StatefulSet. La eliminación paulatina es segura y garantizará que el Pod se apague de [manera paulatina](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination), antes de que el kubelet elimine el nombre del apiserver. From 55afdb55b5e3ba8e6bcb09b38144c2944e590fd3 Mon Sep 17 00:00:00 2001 From: jorge-oduber <56175237+jorge-oduber@users.noreply.github.com> Date: Mon, 26 Feb 2024 14:25:50 -0600 Subject: [PATCH 17/33] Update content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Rodolfo Martínez Vega --- .../docs/tasks/run-application/force-delete-stateful-set-pod.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md b/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md index 8a3088f7e2..52a1f68f48 100644 --- a/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md +++ b/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md @@ -22,7 +22,7 @@ y explica las consideraciones a tener en cuenta al hacerlo. ## Consideraciones de StatefulSet En la operación normal de un StatefulSet, **nunca** hay necesidad de eliminar forzosamente un Pod de StatefulSet. -El [controlador de StatefulSet](/docs/concepts/workloads/controllers/statefulset/) es responsable de +El [controlador de StatefulSet](/es/docs/concepts/workloads/controllers/statefulset/) es responsable de crear, escalar y eliminar miembros del StatefulSet. Intenta asegurar que el número especificado de Pods, desde el ordinal 0 hasta N-1, estén vivos y listos. StatefulSet asegura que, en cualquier momento, exista como máximo un Pod con una identidad dada, corriendo en un clúster. Esto se refiere a la semántica de From bfba8ab89c74076fd89dd5d2c17cdabe32960113 Mon Sep 17 00:00:00 2001 From: jorge-oduber <56175237+jorge-oduber@users.noreply.github.com> Date: Mon, 26 Feb 2024 14:27:20 -0600 Subject: [PATCH 18/33] Update content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md Co-authored-by: Victor Morales --- .../docs/tasks/run-application/force-delete-stateful-set-pod.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md b/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md index 52a1f68f48..6170731725 100644 --- a/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md +++ b/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md @@ -47,7 +47,7 @@ Para que lo anterior conduzca a una terminación paulatina, el Pod no debe espec `pod.Spec.TerminationGracePeriodSeconds` de 0. La práctica de establecer un `pod.Spec.TerminationGracePeriodSeconds` de 0 segundos es insegura y se desaconseja rotundamente para los Pods de StatefulSet. La eliminación paulatina es segura y garantizará que el Pod -se apague de [manera paulatina](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination), antes de que el kubelet elimine el nombre del apiserver. +se apague de [manera paulatina](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination), antes de que kubelet elimine el nombre en el apiserver. Un Pod no se elimina automáticamente cuando un nodo no es accesible. Los Pods que se ejecutan en un Nodo inaccesible entran en el estado 'Terminating' o 'Unknown' después de un From 0535acba45155a547ccf1411a5e6e4b7196db3ee Mon Sep 17 00:00:00 2001 From: jorge-oduber <56175237+jorge-oduber@users.noreply.github.com> Date: Mon, 26 Feb 2024 16:22:44 -0600 Subject: [PATCH 19/33] Update content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Rodolfo Martínez Vega --- .../docs/tasks/run-application/force-delete-stateful-set-pod.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md b/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md index 6170731725..9e39907746 100644 --- a/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md +++ b/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md @@ -56,7 +56,7 @@ Los Pods también pueden entrar en estos estados cuando el usuario intenta la el en un Nodo inaccesible. Las únicas formas en que un Pod en tal estado puede ser eliminado del apiserver son las siguientes: -- El objeto Node es eliminado (ya sea por ti, o por el [Controlador de Nodo](/docs/concepts/architecture/nodes/#node-controller)).). +- El objeto Node es eliminado (ya sea por ti, o por el [Controlador de Nodo](/es/docs/concepts/architecture/nodes/#controlador-de-nodos)).). - El kubelet en el Nodo no responsivo comienza a responder, mata el Pod y elimina la entrada del apiserver. - Eliminación forzada del Pod por el usuario. - From 602441333a36eb97b0b64f0f9b71e927c25607f6 Mon Sep 17 00:00:00 2001 From: jorge-oduber <56175237+jorge-oduber@users.noreply.github.com> Date: Mon, 26 Feb 2024 16:24:04 -0600 Subject: [PATCH 20/33] Update content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md Co-authored-by: Victor Morales --- .../docs/tasks/run-application/force-delete-stateful-set-pod.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md b/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md index 9e39907746..eb5e1d39bf 100644 --- a/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md +++ b/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md @@ -37,7 +37,7 @@ y puede llevar a pérdida de datos (por ejemplo, escenario de cerebro dividido e ## Eliminar Pods -Puedes realizar una eliminación de pod paulatina con el siguiente comando: +Puedes realizar una eliminación de Pod paulatina con el siguiente comando: ```shell kubectl delete pods From 2eb27f916bcd0bdbb37e7236b75715fbd181663a Mon Sep 17 00:00:00 2001 From: jorge-oduber <56175237+jorge-oduber@users.noreply.github.com> Date: Mon, 26 Feb 2024 16:24:13 -0600 Subject: [PATCH 21/33] Update content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md Co-authored-by: Victor Morales --- .../docs/tasks/run-application/force-delete-stateful-set-pod.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md b/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md index eb5e1d39bf..e39e5eb81e 100644 --- a/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md +++ b/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md @@ -53,7 +53,7 @@ Un Pod no se elimina automáticamente cuando un nodo no es accesible. Los Pods que se ejecutan en un Nodo inaccesible entran en el estado 'Terminating' o 'Unknown' después de un [tiempo de espera](/docs/concepts/architecture/nodes/#condition). Los Pods también pueden entrar en estos estados cuando el usuario intenta la eliminación paulatina de un Pod -en un Nodo inaccesible. +en un nodo inaccesible. Las únicas formas en que un Pod en tal estado puede ser eliminado del apiserver son las siguientes: - El objeto Node es eliminado (ya sea por ti, o por el [Controlador de Nodo](/es/docs/concepts/architecture/nodes/#controlador-de-nodos)).). From 6b17fbd92604e8eab759f68e674d30c0e699a34e Mon Sep 17 00:00:00 2001 From: jorge-oduber <56175237+jorge-oduber@users.noreply.github.com> Date: Mon, 26 Feb 2024 16:24:23 -0600 Subject: [PATCH 22/33] Update content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md Co-authored-by: Victor Morales --- .../docs/tasks/run-application/force-delete-stateful-set-pod.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md b/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md index e39e5eb81e..faa1a54b89 100644 --- a/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md +++ b/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md @@ -57,7 +57,7 @@ en un nodo inaccesible. Las únicas formas en que un Pod en tal estado puede ser eliminado del apiserver son las siguientes: - El objeto Node es eliminado (ya sea por ti, o por el [Controlador de Nodo](/es/docs/concepts/architecture/nodes/#controlador-de-nodos)).). -- El kubelet en el Nodo no responsivo comienza a responder, mata el Pod y elimina la entrada del apiserver. +- Kubelet, en el nodo no responsivo, comienza a responder, mata el Pod y elimina la entrada del apiserver. - Eliminación forzada del Pod por el usuario. - La mejor práctica recomendada es usar el primer o segundo enfoque. Si un Nodo está confirmado From 1da0d59d992c146728445326d45cb784bb9149c4 Mon Sep 17 00:00:00 2001 From: jorge-oduber <56175237+jorge-oduber@users.noreply.github.com> Date: Mon, 26 Feb 2024 16:24:31 -0600 Subject: [PATCH 23/33] Update content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md Co-authored-by: Victor Morales --- .../docs/tasks/run-application/force-delete-stateful-set-pod.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md b/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md index faa1a54b89..9fda0b2300 100644 --- a/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md +++ b/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md @@ -62,7 +62,7 @@ Las únicas formas en que un Pod en tal estado puede ser eliminado del apiserver - La mejor práctica recomendada es usar el primer o segundo enfoque. Si un Nodo está confirmado como muerto (por ejemplo, desconectado permanentemente de la red, apagado, etc.), entonces elimina -el objeto Node. Si el Nodo está sufriendo de una partición de red, entonces trata de resolver esto +el objeto Node. Si el nodo es afectado de una partición de red, entonces trata de resolver esto o espera a que se resuelva. Cuando la partición se solucione, kubelet completará la eliminación del Pod y liberará su nombre en el apiserver. From e63722bec0f444bfc26efc5d9af7515f51a802b9 Mon Sep 17 00:00:00 2001 From: jorge-oduber <56175237+jorge-oduber@users.noreply.github.com> Date: Mon, 26 Feb 2024 16:24:41 -0600 Subject: [PATCH 24/33] Update content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md Co-authored-by: Victor Morales --- .../docs/tasks/run-application/force-delete-stateful-set-pod.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md b/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md index 9fda0b2300..9845680811 100644 --- a/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md +++ b/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md @@ -60,7 +60,7 @@ Las únicas formas en que un Pod en tal estado puede ser eliminado del apiserver - Kubelet, en el nodo no responsivo, comienza a responder, mata el Pod y elimina la entrada del apiserver. - Eliminación forzada del Pod por el usuario. - -La mejor práctica recomendada es usar el primer o segundo enfoque. Si un Nodo está confirmado +La mejor práctica recomendada es usar el primer o segundo enfoque. Si un nodo está confirmado como muerto (por ejemplo, desconectado permanentemente de la red, apagado, etc.), entonces elimina el objeto Node. Si el nodo es afectado de una partición de red, entonces trata de resolver esto o espera a que se resuelva. Cuando la partición se solucione, kubelet completará la eliminación From eb75df264767ac4d70feb119e959259f013ddcee Mon Sep 17 00:00:00 2001 From: jorge-oduber <56175237+jorge-oduber@users.noreply.github.com> Date: Mon, 26 Feb 2024 16:47:37 -0600 Subject: [PATCH 25/33] Update force-delete-stateful-set-pod.md --- .../docs/tasks/run-application/force-delete-stateful-set-pod.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md b/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md index 9845680811..2bbcd060f3 100644 --- a/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md +++ b/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md @@ -51,7 +51,7 @@ se apague de [manera paulatina](/docs/concepts/workloads/pods/pod-lifecycle/#pod Un Pod no se elimina automáticamente cuando un nodo no es accesible. Los Pods que se ejecutan en un Nodo inaccesible entran en el estado 'Terminating' o 'Unknown' después de un -[tiempo de espera](/docs/concepts/architecture/nodes/#condition). +[tiempo de espera](es/docs/concepts/architecture/nodes/#Estados). Los Pods también pueden entrar en estos estados cuando el usuario intenta la eliminación paulatina de un Pod en un nodo inaccesible. Las únicas formas en que un Pod en tal estado puede ser eliminado del apiserver son las siguientes: From b2c81c52ede2d20bf6a0a724cc0b84307a18e535 Mon Sep 17 00:00:00 2001 From: Aleksandr Maskalev Date: Tue, 27 Feb 2024 20:48:39 +0600 Subject: [PATCH 26/33] update scale-intro.html (close tag) --- .../ru/docs/tutorials/kubernetes-basics/scale/scale-intro.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ru/docs/tutorials/kubernetes-basics/scale/scale-intro.html b/content/ru/docs/tutorials/kubernetes-basics/scale/scale-intro.html index 4399e729c2..c1c2c2c540 100644 --- a/content/ru/docs/tutorials/kubernetes-basics/scale/scale-intro.html +++ b/content/ru/docs/tutorials/kubernetes-basics/scale/scale-intro.html @@ -41,7 +41,7 @@ description: |-
-

Количество экземпляров можно указать прямо при создании деплоймента, используя параметр --replicas команды kubectl create deployment

+

Количество экземпляров можно указать прямо при создании деплоймента, используя параметр --replicas команды kubectl create deployment

From 69b5bc1914c48404efad071fb0e0d5d6b38c8c59 Mon Sep 17 00:00:00 2001 From: jorge-oduber <56175237+jorge-oduber@users.noreply.github.com> Date: Tue, 27 Feb 2024 11:16:54 -0600 Subject: [PATCH 27/33] Update content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md Co-authored-by: Carol Valencia <8355621+krol3@users.noreply.github.com> --- .../docs/tasks/run-application/force-delete-stateful-set-pod.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md b/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md index 2bbcd060f3..2864766f5c 100644 --- a/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md +++ b/content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md @@ -11,7 +11,7 @@ Esta página muestra cómo eliminar Pods que son parte de un {{< glossary_tooltip text="StatefulSet" term_id="StatefulSet" >}}, y explica las consideraciones a tener en cuenta al hacerlo. -## {{% heading "prerequisitos" %}} +## {{% heading "prerequisites" %}} - Esta es una tarea bastante avanzada y tiene el potencial de violar algunas de las propiedades inherentes de StatefulSet. From 840f8da3f22f9e28d25e6513a76c35881689570f Mon Sep 17 00:00:00 2001 From: windsonsea Date: Wed, 28 Feb 2024 09:50:53 +0800 Subject: [PATCH 28/33] [zh] Sync configure-upgrade-etcd.md --- .../configure-upgrade-etcd.md | 111 +++++++++--------- 1 file changed, 54 insertions(+), 57 deletions(-) diff --git a/content/zh-cn/docs/tasks/administer-cluster/configure-upgrade-etcd.md b/content/zh-cn/docs/tasks/administer-cluster/configure-upgrade-etcd.md index 7f3d68589c..af1f786c84 100644 --- a/content/zh-cn/docs/tasks/administer-cluster/configure-upgrade-etcd.md +++ b/content/zh-cn/docs/tasks/administer-cluster/configure-upgrade-etcd.md @@ -19,17 +19,15 @@ weight: 270 ## {{% heading "prerequisites" %}} -{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} - 你需要有一个 Kubernetes 集群，并且必须配置 kubectl 命令行工具以与你的集群通信。 -建议在至少有两个不充当控制平面的节点上运行此任务。如果你还没有集群， +建议参照本指南在至少有两个不充当控制平面的节点上运行此任务。如果你还没有集群， 你可以使用 [minikube](https://minikube.sigs.k8s.io/docs/tutorials/multi_node/) 创建一个。 @@ -42,7 +40,14 @@ nodes . If you do not already have a cluster, you can create one by using * etcd is a leader-based distributed system. Ensure that the leader periodically send heartbeats on time to all followers to keep the cluster stable. +--> +## 先决条件 {#prerequisites} +* 运行的 etcd 集群个数成员为奇数。 + +* etcd 是一个基于领导者（Leader-Based）的分布式系统。确保主节点定期向所有从节点发送心跳，以保持集群稳定。 + + -## 先决条件 {#prerequisites} - -* 运行的 etcd 集群个数成员为奇数。 - -* etcd 是一个 leader-based 分布式系统。确保主节点定期向所有从节点发送心跳，以保持集群稳定。 - * 确保不发生资源不足。 集群的性能和稳定性对网络和磁盘 I/O 非常敏感。任何资源匮乏都会导致心跳超时， 从而导致集群的不稳定。不稳定的情况表明没有选出任何主节点。 在这种情况下，集群不能对其当前状态进行任何更改，这意味着不能调度新的 Pod。 + * 保持 etcd 集群的稳定对 Kubernetes 集群的稳定性至关重要。 因此，请在专用机器或隔离环境上运行 etcd 集群， 以满足[所需资源需求](https://etcd.io/docs/current/op-guide/hardware/)。 @@ -100,7 +100,7 @@ This section covers starting a single-node and multi-node etcd cluster. -配置安全通信后，限制只有 Kubernetes API 服务器可以访问 etcd 集群。使用 TLS 身份验证来完成此任务。 +配置安全通信后，使用 TLS 身份验证来限制只有 Kubernetes API 服务器可以访问 etcd 集群。 -Kubernetes 目前不支持 etcd 身份验证。 -想要了解更多信息，请参阅相关的问题[支持 etcd v2 的基本认证](https://github.com/kubernetes/kubernetes/issues/23398)。 +Kubernetes 没有为 etcd 提供身份验证的计划。 {{< /note >}} 3. 停止故障节点上的 etcd 服务器。除了 Kubernetes API 服务器之外的其他客户端可能会造成流向 etcd 的流量， 可以停止所有流量以防止写入数据目录。 4. 移除失败的成员： @@ -400,7 +397,7 @@ replace it with `member4=http://10.0.0.4`. ``` 5. 增加新成员： @@ -418,7 +415,7 @@ replace it with `member4=http://10.0.0.4`. ``` 6. 在 IP 为 `10.0.0.4` 的机器上启动新增加的成员： @@ -430,7 +427,7 @@ replace it with `member4=http://10.0.0.4`. ``` ## 备份 etcd 集群 {#backing-up-an-etcd-cluster} -所有 Kubernetes 对象都存储在 etcd 上。 +所有 Kubernetes 对象都存储在 etcd 中。 定期备份 etcd 集群数据对于在灾难场景（例如丢失所有控制平面节点）下恢复 Kubernetes 集群非常重要。 快照文件包含所有 Kubernetes 状态和关键信息。为了保证敏感的 Kubernetes 数据的安全，可以对快照文件进行加密。 @@ -482,22 +479,22 @@ snapshot and volume snapshot. ### 内置快照 {#built-in-snapshot} -etcd 支持内置快照。快照可以从使用 `etcdctl snapshot save` 命令的活动成员中获取， +etcd 支持内置快照。快照可以从使用 `etcdctl snapshot save` 命令的活动成员中创建， 也可以通过从 etcd [数据目录](https://etcd.io/docs/current/op-guide/configuration/#--data-dir) -复制 `member/snap/db` 文件，该 etcd 数据目录目前没有被 etcd 进程使用。获取快照不会影响成员的性能。 +复制 `member/snap/db` 文件，该 etcd 数据目录目前没有被 etcd 进程使用。创建快照不会影响成员的性能。 -下面是一个示例，用于获取 `$ENDPOINT` 所提供的键空间的快照到文件 `snapshot.db`： +下面是一个示例，用于创建 `$ENDPOINT` 所提供的键空间的快照到文件 `snapshot.db`： ```shell ETCDCTL_API=3 etcdctl --endpoints $ENDPOINT snapshot save snapshot.db @@ -527,11 +524,11 @@ ETCDCTL_API=3 etcdctl --write-out=table snapshot status snapshot.db 如果 etcd 运行在支持备份的存储卷（如 Amazon Elastic Block -存储）上，则可以通过获取存储卷的快照来备份 etcd 数据。 +存储）上，则可以通过创建存储卷的快照来备份 etcd 数据。 我们还可以使用 etcdctl 提供的各种选项来制作快照。例如： @@ -548,10 +545,10 @@ ETCDCTL_API=3 etcdctl -h ``` -列出 etcdctl 可用的各种选项。例如，你可以通过指定端点、证书等来制作快照，如下所示： +列出 etcdctl 可用的各种选项。例如，你可以通过指定端点、证书和密钥来制作快照，如下所示： ```shell ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 \ @@ -573,7 +570,7 @@ where `trusted-ca-file`, `cert-file` and `key-file` can be obtained from the des Scaling out etcd clusters increases availability by trading off performance. Scaling does not increase cluster performance nor capability. A general rule is not to scale out or in etcd clusters. Do not configure any auto scaling -groups for etcd clusters. It is highly recommended to always run a static +groups for etcd clusters. It is strongly recommended to always run a static five-member etcd cluster for production Kubernetes clusters at any officially supported scale. --> @@ -599,7 +596,7 @@ for information on how to add members into an existing cluster. etcd 支持从 [major.minor](http://semver.org/) 或其他不同 patch 版本的 etcd 进程中获取的快照进行恢复。 @@ -637,7 +634,7 @@ etcdctl --data-dir snapshot restore snapshot.db ``` 如果 `` 与之前的文件夹相同，请先删除此文件夹并停止 etcd 进程，再恢复集群。 否则，需要在恢复后更改 etcd 配置并重新启动 etcd 进程才能使用新的数据目录。 @@ -650,7 +647,7 @@ For more information and examples on restoring a cluster from a snapshot file, s [etcd 灾难恢复文档](https://etcd.io/docs/current/op-guide/recovery/#restoring-a-cluster)。 碎片整理是一种昂贵的操作，因此应尽可能少地执行此操作。 -另一方面，也有必要确保任何 etcd 成员都不会用尽存储配额。 +另一方面，也有必要确保任何 etcd 成员都不会超过存储配额。 Kubernetes 项目建议在执行碎片整理时， 使用诸如 [etcd-defrag](https://github.com/ahrtr/etcd-defrag) 之类的工具。 {{< /note >}} From 03138d100e9017331878d4445c9e68153d0c9a85 Mon Sep 17 00:00:00 2001 From: windsonsea Date: Tue, 27 Feb 2024 09:36:45 +0800 Subject: [PATCH 29/33] [zh] Sync multiple-zones.md --- .../setup/best-practices/multiple-zones.md | 103 +++++++++--------- 1 file changed, 54 insertions(+), 49 deletions(-) diff --git a/content/zh-cn/docs/setup/best-practices/multiple-zones.md b/content/zh-cn/docs/setup/best-practices/multiple-zones.md index 796a2b0796..9636b38a93 100644 --- a/content/zh-cn/docs/setup/best-practices/multiple-zones.md +++ b/content/zh-cn/docs/setup/best-practices/multiple-zones.md @@ -1,6 +1,6 @@ --- title: 运行于多可用区环境 -weight: 10 +weight: 20 content_type: concept --- @@ -18,7 +18,7 @@ content_type: concept -本页描述如何跨多个区（Zone）中运行集群。 +本页描述如何跨多个区（Zone）运行集群。 @@ -35,11 +35,11 @@ APIs and services. Typical cloud architectures aim to minimize the chance that a failure in one zone also impairs services in another zone. --> -## 背景 +## 背景 {#background} Kubernetes 从设计上允许同一个 Kubernetes 集群跨多个失效区来运行， -通常这些区位于某个称作 _区域（region）_ 逻辑分组中。 -主要的云提供商都将区域定义为一组失效区的集合（也称作 _可用区（Availability Zones）_）， +通常这些区位于某个称作 **区域（Region）** 逻辑分组中。 +主要的云提供商都将区域定义为一组失效区的集合（也称作 **可用区（Availability Zones**））， 能够提供一组一致的功能特性：每个区域内，各个可用区提供相同的 API 和服务。 典型的云体系结构都会尝试降低某个区中的失效影响到其他区中服务的概率。 @@ -66,10 +66,10 @@ If you are running a cloud controller manager then you should also replicate this across all the failure zones you selected. --> 当你部署集群控制面时，应将控制面组件的副本跨多个失效区来部署。 -如果可用性是一个很重要的指标，应该选择至少三个失效区，并将每个 -控制面组件（API 服务器、调度器、etcd、控制器管理器）复制多个副本， -跨至少三个失效区来部署。如果你在运行云控制器管理器，则也应该将 -该组件跨所选的三个失效区来部署。 +如果可用性是一个很重要的指标，应该选择至少三个失效区， +并将每个控制面组件（API 服务器、调度器、etcd、控制器管理器）复制多个副本， +跨至少三个失效区来部署。如果你在运行云控制器管理器， +则也应该将该组件跨所选的三个失效区来部署。 {{< note >}} ## 节点行为 {#node-behavior} -Kubernetes 自动为负载资源（如{{< glossary_tooltip text="Deployment" term_id="deployment" >}} -或 {{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}})） -跨集群中不同节点来部署其 Pods。 +Kubernetes 自动为负载资源（如 {{< glossary_tooltip text="Deployment" term_id="deployment" >}} +或 {{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}}） +跨集群中不同节点来部署其 Pod。 这种分布逻辑有助于降低失效带来的影响。 -节点启动时，每个节点上的 kubelet 会向 Kubernetes API 中代表该 kubelet 的 Node 对象 -添加 {{< glossary_tooltip text="标签" term_id="label" >}}。 +节点启动时，每个节点上的 kubelet 会向 Kubernetes API 中代表该 kubelet 的 Node +对象添加{{< glossary_tooltip text="标签" term_id="label" >}}。 这些标签可能包含[区信息](/zh-cn/docs/reference/labels-annotations-taints/#topologykubernetesiozone)。 如果你的集群跨了多个可用区或者地理区域，你可以使用节点标签，结合 [Pod 拓扑分布约束](/zh-cn/docs/concepts/scheduling-eviction/topology-spread-constraints/) -来控制如何在你的集群中多个失效域之间分布 Pods。这里的失效域可以是 -地理区域、可用区甚至是特定节点。 -这些提示信息使得{{< glossary_tooltip text="调度器" term_id="kube-scheduler" >}} -能够更好地分布 Pods，以实现更好的可用性，降低因为某种失效给整个工作负载 -带来的风险。 +来控制如何在你的集群中多个失效域之间分布 Pod。这里的失效域可以是地理区域、可用区甚至是特定节点。 +这些提示信息使得{{< glossary_tooltip text="调度器" term_id="kube-scheduler" >}}能够更好地调度 +Pod，以实现更好的可用性，降低因为某种失效给整个工作负载带来的风险。 -例如，你可以设置一种约束，确保某个 StatefulSet 中的三个副本都运行在 -不同的可用区中，只要其他条件允许。你可以通过声明的方式来定义这种约束， +例如，你可以设置一种约束，确保某个 StatefulSet 中的 3 个副本都运行在不同的可用区中， +只要其他条件允许。你可以通过声明的方式来定义这种约束， 而不需要显式指定每个工作负载使用哪些可用区。 -### 跨多个区分布节点 {#distributing-nodes-across-zones} +### 跨多个区分布节点 {#distributing-nodes-across-zones} -Kubernetes 的核心逻辑并不会帮你创建节点，你需要自行完成此操作，或者使用 -类似 [Cluster API](https://cluster-api.sigs.k8s.io/) 这类工具来替你管理节点。 +Kubernetes 的核心逻辑并不会帮你创建节点，你需要自行完成此操作，或者使用类似 +[Cluster API](https://cluster-api.sigs.k8s.io/) 这类工具来替你管理节点。 -使用类似 Cluster API 这类工具，你可以跨多个失效域来定义一组用做你的集群 -工作节点的机器，以及当整个区的服务出现中断时如何自动治愈集群的策略。 +使用类似 Cluster API 这类工具，你可以跨多个失效域来定义一组用做你的集群工作节点的机器， +以及当整个区的服务出现中断时如何自动治愈集群的策略。 -## 为 Pods 手动指定区 +## 为 Pod 手动指定区 {#manual-zone-assignment-for-pods} -你可以应用[节点选择算符约束](/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector) -到你所创建的 Pods 上，或者为 Deployment、StatefulSet 或 Job 这类工作负载资源 -中的 Pod 模板设置此类约束。 +你可以应用[节点选择算符约束](/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector)到你所创建的 +Pod 上，或者为 Deployment、StatefulSet 或 Job 这类工作负载资源中的 Pod 模板设置此类约束。 -## 跨区的存储访问 +## 跨区的存储访问 {#storage-access-for-zones} -当创建持久卷时，Kubernetes 会自动向那些链接到特定区的 PersistentVolume 添加区标签。。 +当创建持久卷时，Kubernetes 会自动向那些链接到特定区的 PersistentVolume 添加区标签。 {{< glossary_tooltip text="调度器" term_id="kube-scheduler" >}}通过其 -`NoVolumeZoneConflict` 断言确保申领给定 PersistentVolume 的 Pods 只会 -被调度到该卷所在的可用区。 +`NoVolumeZoneConflict` 断言确保申领给定 PersistentVolume 的 Pod +只会被调度到该卷所在的可用区。 + + +请注意，添加区标签的方法可能取决于你的云提供商和存储制备器。 +请参阅具体的环境文档，确保配置正确。 请注意，添加区标签的方法可能会根据你所使用的云提供商和存储制备器而有所不同。 为确保配置正确，请始终参阅你的环境的特定文档。 @@ -212,10 +217,11 @@ storage in that class may use. To learn about configuring a StorageClass that is aware of failure domains or zones, see [Allowed topologies](/docs/concepts/storage/storage-classes/#allowed-topologies). --> -你可以为 PersistentVolumeClaim 指定{{< glossary_tooltip text="StorageClass" term_id="storage-class" >}} +你可以为 PersistentVolumeClaim 指定 +{{< glossary_tooltip text="StorageClass" term_id="storage-class" >}} 以设置该类中的存储可以使用的失效域（区）。 -要了解如何配置能够感知失效域或区的 StorageClass，请参阅 -[可用的拓扑逻辑](/zh-cn/docs/concepts/storage/storage-classes/#allowed-topologies)。 +要了解如何配置能够感知失效域或区的 StorageClass， +请参阅[可用的拓扑逻辑](/zh-cn/docs/concepts/storage/storage-classes/#allowed-topologies)。 -## 网络 {#networking} +## 网络 {#networking} Kubernetes 自身不提供与可用区相关的联网配置。 你可以使用[网络插件](/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) 来配置集群的联网，该网络解决方案可能拥有一些与可用区相关的元素。 -例如，如果你的云提供商支持 `type=LoadBalancer` 的 Service，则负载均衡器 -可能仅会将请求流量发送到运行在负责处理给定连接的负载均衡器组件所在的区。 +例如，如果你的云提供商支持 `type=LoadBalancer` 的 Service， +则负载均衡器可能仅会将请求流量发送到运行在负责处理给定连接的负载均衡器组件所在的区。 请查阅云提供商的文档了解详细信息。 -对于自定义的或本地集群部署，也可以考虑这些因素 -{{< glossary_tooltip text="Service" term_id="service" >}} +对于自定义的或本地集群部署，也可以考虑这些因素。 +{{< glossary_tooltip text="Service" term_id="service" >}} 和 {{< glossary_tooltip text="Ingress" term_id="ingress" >}} 的行为， 包括处理不同失效区的方法，在很大程度上取决于你的集群是如何搭建的。 @@ -266,11 +272,11 @@ something to consider. --> ## 失效恢复 {#fault-recovery} -在搭建集群时，你可能需要考虑当某区域中的所有失效区都同时掉线时，是否以及如何 -恢复服务。例如，你是否要求在某个区中至少有一个节点能够运行 Pod？ +在搭建集群时，你可能需要考虑当某区域中的所有失效区都同时掉线时，是否以及如何恢复服务。 +例如，你是否要求在某个区中至少有一个节点能够运行 Pod？ 请确保任何对集群很关键的修复工作都不要指望集群中至少有一个健康节点。 例如：当所有节点都不健康时，你可能需要运行某个修复性的 Job， -该 Job 要设置特定的{{< glossary_tooltip text="容忍度" term_id="toleration" >}} +该 Job 要设置特定的{{< glossary_tooltip text="容忍度" term_id="toleration" >}}， 以便修复操作能够至少将一个节点恢复为可用状态。 Kubernetes 对这类问题没有现成的解决方案；不过这也是要考虑的因素之一。 @@ -281,6 +287,5 @@ Kubernetes 对这类问题没有现成的解决方案；不过这也是要考虑 To learn how the scheduler places Pods in a cluster, honoring the configured constraints, visit [Scheduling and Eviction](/docs/concepts/scheduling-eviction/). --> -要了解调度器如何在集群中放置 Pods 并遵从所配置的约束，可参阅 -[调度与驱逐](/zh-cn/docs/concepts/scheduling-eviction/)。 - +要了解调度器如何在集群中放置 Pod 并遵从所配置的约束， +可参阅[调度与驱逐](/zh-cn/docs/concepts/scheduling-eviction/)。 From 4764c8706be47c1e5b429496121a11c54e52b042 Mon Sep 17 00:00:00 2001 From: Andrii Holovin Date: Wed, 28 Feb 2024 11:18:06 +0200 Subject: [PATCH 30/33] Update thirdparty-content.html --- layouts/shortcodes/thirdparty-content.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/layouts/shortcodes/thirdparty-content.html b/layouts/shortcodes/thirdparty-content.html index a252e93c3d..09b45e72d8 100644 --- a/layouts/shortcodes/thirdparty-content.html +++ b/layouts/shortcodes/thirdparty-content.html @@ -2,7 +2,7 @@ {{- $vendor_message := .Get "vendor" | default "false" -}}