Remove trailing spaces from ES documents(kubernetes#16742)

Author: Yushiro FURUKAWA

content/es/docs/concepts/architecture/cloud-controller.md

@@ -62,15 +62,15 @@ El CCM hereda sus funciones de componentes que son dependientes de un proveedor
 
 ### 1. Kubernetes Controller Manager
 
-La mayoría de las funciones del CCM derivan del KCM. Como se ha mencionado en la sección anterior, el CCM es responsable de los siguientes circuitos de control: 
+La mayoría de las funciones del CCM derivan del KCM. Como se ha mencionado en la sección anterior, el CCM es responsable de los siguientes circuitos de control:
 
  * Controlador de Nodos
  * Controlador de Rutas
  * Controlador de Servicios
 
 #### Controlador de Nodos
 
-El controlador de nodos es responsable de inicializar un nodo obteniendo información del proveedor de servicios sobre los nodos ejecutándose en el clúster. El controlador de nodos lleva a cabo las siguientes funciones: 
+El controlador de nodos es responsable de inicializar un nodo obteniendo información del proveedor de servicios sobre los nodos ejecutándose en el clúster. El controlador de nodos lleva a cabo las siguientes funciones:
 
 1. Inicializa un nodo con etiquetas de región y zona específicas del proveedor.
 2. Inicializa un nodo con detalles de la instancia específicos del proveedor, como por ejemplo, el tipo o el tamaño.
@@ -95,7 +95,7 @@ En este nuevo modelo, el kubelet inicializa un nodo sin información especifica
 
 El Cloud Controller Manager utiliza interfaces Go(lang), lo que permite que implementaciones de cualquier proveedor de servicios sean conectadas. Específicamente, utiliza el CloudProvider Interface definido [aquí](https://github.com/kubernetes/cloud-provider/blob/9b77dc1c384685cb732b3025ed5689dd597a5971/cloud.go#L42-L62).
 
-La implementación de los cuatro controladores referenciados en este documento, algunas estructuras de inicialización junto con el interface CloudProvider, permanecerán como parte del núcleo de Kubernetes. 
+La implementación de los cuatro controladores referenciados en este documento, algunas estructuras de inicialización junto con el interface CloudProvider, permanecerán como parte del núcleo de Kubernetes.
 
 Para más información sobre el desarrollo de extensiones/plugins, consultar [Desarrollo del CCM](https://kubernetes.io/docs/tasks/administer-cluster/developing-cloud-controller-manager/).
 
@@ -119,7 +119,7 @@ v1/Node:
 
 ### Controlador de Rutas
 
-El controlador de rutas permanece a la escucha de eventos de creación de nodos y configura sus rutas. Necesita acceso a los objetos Nodo. 
+El controlador de rutas permanece a la escucha de eventos de creación de nodos y configura sus rutas. Necesita acceso a los objetos Nodo.
 
 v1/Node:
 

content/es/docs/concepts/architecture/master-node-communication.md

@@ -1,5 +1,5 @@
 ---
-reviewers: 
+reviewers:
 - glo-pena
 title: Comunicación Nodo-Maestro
 content_template: templates/concept
@@ -15,7 +15,7 @@ Este documento cataloga las diferentes vías de comunicación entre el nodo más
 {{% capture body %}}
 
 ### Clúster a Máster
- 
+
 Todos los canales de comunicación desde el clúster hacia el máster terminan en el apiserver (ningún otro componente del máster está diseñado para exponer servicios remotos). En un despliegue típico, el apiserver está configurado para escuchar conexiones remotas en un canal seguro cómo HTTPS en el puerto (443) con una o más formas de [autenticación de clientes](/docs/reference/access-authn-authz/authentication/) habilitada. Una o más formas de [autorización](/docs/reference/access-authn-authz/authorization/) deberían ser habilitadas, especialmente si se permiten [peticiones anónimas](/docs/reference/access-authn-authz/authentication/#anonymous-requests)
 o [tokens de cuenta de servicio](/docs/reference/access-authn-authz/authentication/#service-account-tokens).
 
@@ -48,7 +48,7 @@ Finalmente, [autenticación y/o autorización al kubelet](/docs/admin/kubelet-au
 
 ### apiserver a nodos, pods y servicios
 
-Las conexiones desde el apiserver a un nodo, pod o servicio se realizan por defecto con HTTP y, por consiguiente, no son autentificadas o encriptadas. Pueden ser ejecutadas en una conexión HTTPS segura añadiendo el prefijo `https:` al nodo, pod o nombre de servicio en la API URL, pero los receptores no validan el certificado provisto por el endpoint HTTPS ni facilitan credenciales de cliente asi que, aunque la conexión esté encriptada, esta no ofrece garantía de integridad. Estas conexiones **no son seguras** para conectar a través de redes públicas o inseguras.  
+Las conexiones desde el apiserver a un nodo, pod o servicio se realizan por defecto con HTTP y, por consiguiente, no son autentificadas o encriptadas. Pueden ser ejecutadas en una conexión HTTPS segura añadiendo el prefijo `https:` al nodo, pod o nombre de servicio en la API URL, pero los receptores no validan el certificado provisto por el endpoint HTTPS ni facilitan credenciales de cliente asi que, aunque la conexión esté encriptada, esta no ofrece garantía de integridad. Estas conexiones **no son seguras** para conectar a través de redes públicas o inseguras.
 
 ### Túneles SSH
 

content/es/docs/concepts/architecture/nodes.md

@@ -60,7 +60,7 @@ Si el `status` de la condición `Ready` se mantiene como `Unknown` o `False` por
 
 En versiones de Kubernetes anteriores a 1.5, el controlador de nodos [forzaba el borrado](/docs/concepts/workloads/pods/pod/#force-deletion-of-pods) de dichos pods inaccesibles desde el API Server. Sin embargo, desde la versión 1.5, el nodo controlador no fuerza el borrado de pods hasta que se confirma que dichos pods han dejado de ejecutarse en el clúster. Pods que podrían estar ejecutándose en un nodo inalcanzable se muestran como `Terminating` o `Unknown`. En aquellos casos en los que Kubernetes no puede deducir si un nodo ha abandonado el clúster de forma permanente, puede que sea el administrador el que tenga que borrar el nodo de forma manual. Borrar un objeto `Node` en un clúster de Kubernetes provoca que los objetos Pod que se ejecutaban en el nodo sean eliminados en el API Server y libera sus nombres.
 
-En la versión 1.12, la funcionalidad `TaintNodesByCondition` se eleva a beta, de forma que el controlador del ciclo de vida de nodos crea [taints](/docs/concepts/configuration/taint-and-toleration/) de forma automática, que representan estados de nodos. 
+En la versión 1.12, la funcionalidad `TaintNodesByCondition` se eleva a beta, de forma que el controlador del ciclo de vida de nodos crea [taints](/docs/concepts/configuration/taint-and-toleration/) de forma automática, que representan estados de nodos.
 De forma similar, el planificador de tareas ignora estados cuando evalúa un nodo; en su lugar mira los taints del nodo y las tolerancias de los pods.
 
 En la actualidad, los usuarios pueden elegir entre la versión de planificación antigua y el nuevo, más flexible, modelo de planificación.
@@ -123,7 +123,7 @@ En la mayoría de los casos, el controlador de nodos limita el ritmo de desalojo
 El comportamiento de desalojo de nodos cambia cuando un nodo en una zona de disponibilidad tiene problemas. El controlador de nodos comprobará qué porcentaje de nodos en la zona no se encuentran en buen estado (es decir, que su condición `NodeReady` tiene un valor `ConditionUnknown` o `ConditionFalse`) al mismo tiempo. Si la fracción de nodos con problemas es de al menos `--unhealthy-zone-threshold` (0.55 por defecto) entonces se reduce el ratio de desalojos: si el clúster es pequeño (por ejemplo, tiene menos o los mismos nodos que `--large-cluster-size-threshold` - 50 por defecto) entonces los desalojos se paran. Sino, el ratio se reduce a `--secondary-node-eviction-rate` (0.01 por defecto) por segundo. La razón por la que estas políticas se implementan por zonas de disponibilidad es debido a que una zona puede quedarse aislada del nodo máster mientras que las demás continúan conectadas. Si un clúster no comprende más de una zona, todo el clúster se considera una única zona.
 
 La razón principal por la que se distribuyen nodos entre varias zonas de disponibilidad es para que el volumen de trabajo se transfiera a aquellas zonas que se encuentren en buen estado cuando una de las zonas se caiga.
-Por consiguiente, si todos los nodos de una zona se encuentran en mal estado, el nodo controlador desaloja al ritmo normal `--node-eviction-rate`. En el caso extremo de que todas las zonas se encuentran en mal estado (es decir, no responda ningún nodo del clúster), el controlador de nodos asume que hay algún tipo de problema con la conectividad del nodo máster y paraliza todos los desalojos hasta que se re-establece la conectividad. 
+Por consiguiente, si todos los nodos de una zona se encuentran en mal estado, el nodo controlador desaloja al ritmo normal `--node-eviction-rate`. En el caso extremo de que todas las zonas se encuentran en mal estado (es decir, no responda ningún nodo del clúster), el controlador de nodos asume que hay algún tipo de problema con la conectividad del nodo máster y paraliza todos los desalojos hasta que se re-establece la conectividad.
 
 Desde la versión 1.6 de Kubernetes el controlador de nodos también es el responsable de desalojar pods que están ejecutándose en nodos con `NoExecute` taints, cuando los pods no permiten dichos taints. De forma adicional, como una funcionalidad alfa que permanece deshabilitada por defecto, el `NodeController` es responsable de añadir taints que se corresponden con problemas en los nodos del tipo nodo inalcanzable o nodo no preparado. En [esta sección de la documentación](/docs/concepts/configuration/taint-and-toleration/) hay más detalles acerca de los taints `NoExecute` y de la funcionalidad alfa.
 
@@ -161,7 +161,7 @@ Marcar un nodo como no-planificable impide que nuevos pods sean planificados en
 kubectl cordon $NODENAME
 ```
 
-{{< note >}} 
+{{< note >}}
 Los pods creados por un controlador DaemonSet ignoran el planificador de Kubernetes y no respetan el atributo no-planificable de un nodo. Se asume que los daemons pertenecen a la máquina huésped y que se ejecutan incluso cuando esta está siendo drenada de aplicaciones en preparación de un reinicio.
 {{< /note >}}
 

content/es/docs/concepts/containers/container-lifecycle-hooks.md

@@ -114,7 +114,7 @@ Events:
 {{% capture whatsnext %}}
 
 * Aprende más sobre [variables de entorno de contenedores](/docs/concepts/containers/container-environment-variables/).
-* Practica 
+* Practica
   [adjuntando controladores a los eventos de lifecycle de los contenedores](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/).
 
 {{% /capture %}}

content/es/docs/concepts/overview/what-is-kubernetes.md

@@ -4,7 +4,7 @@ reviewers:
 title: ¿Qué es Kubernetes?
 content_template: templates/concept
 weight: 10
-card: 
+card:
   name: concepts
   weight: 10
 ---

content/es/docs/concepts/overview/working-with-objects/annotations.md

@@ -11,7 +11,7 @@ Puedes usar las anotaciones de Kubernetes para adjuntar metadatos arbitrarios a
 {{% capture body %}}
 ## Adjuntar metadatos a los objetos
 
-Puedes usar las etiquetas o anotaciones para adjuntar metadatos a los objetos de Kubernetes. 
+Puedes usar las etiquetas o anotaciones para adjuntar metadatos a los objetos de Kubernetes.
 Las etiquetas pueden utilizarse para seleccionar objetos y para encontrar colecciones de objetos que satisfacen ciertas condiciones.
 Por el contrario, las anotaciones no se utilizan para identificar y seleccionar objetos.
 Los metadatos de una anotación pueden ser pequeños o grandes, estructurados o no estructurados,
@@ -32,7 +32,7 @@ Aquí se presentan algunos ejemplos de información que podría ser indicada com
 
 * Campos gestionados por una capa de configuración declarativa.
   Adjuntando dichos campos como anotaciones permitiría diferenciarlos de los
-  valores por defecto establecidos por clientes o servidores, además de los 
+  valores por defecto establecidos por clientes o servidores, además de los
   campos auto-generados y los campos modificados por sistemas de auto-escalado.
 
 * Información acerca de la construcción, entrega, o imagen como marcas de fecha, IDs de entrega, rama de Git,
@@ -56,12 +56,12 @@ Aquí se presentan algunos ejemplos de información que podría ser indicada com
 
 En vez de usar anotaciones, podrías almacenar este tipo de información en una
 base de datos externa o un directorio, pero eso complicaría enormemente la posibilidad
-de crear librerías compartidas de cliente, así como herramientas para el 
+de crear librerías compartidas de cliente, así como herramientas para el
 despliegue, gestión, introspección, y similares.
 
 ## Sintaxis y conjunto de caracteres
 
-Las _Anotaciones_ son entradas clave/valor. Una clave válida para una anotación tiene dos partes: un prefijo opcional y un nombre, separados por una barra (`/`). La parte del nombre es obligatoria y debe tener 63 caracteres o menos, empezando y terminando con un carácter alfanumérico (`[a-z0-9A-Z]`) con guiones (`-`), guiones bajos (`_`), puntos (`.`) en medio. El prefijo es opcional. Si se indica, 
+Las _Anotaciones_ son entradas clave/valor. Una clave válida para una anotación tiene dos partes: un prefijo opcional y un nombre, separados por una barra (`/`). La parte del nombre es obligatoria y debe tener 63 caracteres o menos, empezando y terminando con un carácter alfanumérico (`[a-z0-9A-Z]`) con guiones (`-`), guiones bajos (`_`), puntos (`.`) en medio. El prefijo es opcional. Si se indica,
 el prefijo debe ser un subdominio DNS: una serie de etiquetas DNS separadas por puntos (`.`), no superior a 253 caracteres en total, seguida de una barra (`/`).
 
 Si se omite el prefijo, la clave de la anotación se entiende que es privada para el usuario. Los componentes automatizados del sistema (e.g. `kube-scheduler`, `kube-controller-manager`, `kube-apiserver`, `kubectl`, u otros de terceros) que añaden anotaciones a los objetos de usuario deben, pues, especificar un prefijo.

content/es/docs/concepts/overview/working-with-objects/common-labels.md

@@ -5,7 +5,7 @@ content_template: templates/concept
 
 {{% capture overview %}}
 Puedes visualizar y gestionar los objetos de Kubernetes con herramientas adicionales a kubectl
-y el propio tablero de control. Un conjunto común de etiquetas permite a dichas herramientas 
+y el propio tablero de control. Un conjunto común de etiquetas permite a dichas herramientas
 trabajar de forma interoperable, describiendo los objetos de una forma común que todas las
 herramientas puedan entender.
 
@@ -24,7 +24,7 @@ Estas son las etiquetas recomendadas. Estas facilitan la gestión de aplicacione
 pero no son obligatorias para las herramientas en general.
 {{< /note >}}
 
-Las etiquetas compartidas y las anotaciones comparten un prefijo común: `app.kubernetes.io`. 
+Las etiquetas compartidas y las anotaciones comparten un prefijo común: `app.kubernetes.io`.
 Las etiquetas sin un prefijo son privadas para los usuarios. El prefijo compartido
 garantiza que las etiquetas compartidas no entran en conflicto con las etiquetas
 personalizadas de usuario.
@@ -63,10 +63,10 @@ Una misma aplicación puede desplegarse una o más veces en un clúster de Kuber
 incluso, el mismo espacio de nombres. Por ejemplo, wordpress puede instalarse más de una
 vez de forma que sitios web diferentes sean instalaciones diferentes de wordpress.
 
-El nombre de una aplicación y el nombre de la instancia se almacenan de forma separada. 
-Por ejemplo, WordPress tiene un `app.kubernetes.io/name` igual a `wordpress` mientras que 
-tiene un nombre de instancia, representado como `app.kubernetes.io/instance` con un valor de 
-`wordpress-abcxzy`. Esto permite identificar tanto a la aplicación como a sus instancias. 
+El nombre de una aplicación y el nombre de la instancia se almacenan de forma separada.
+Por ejemplo, WordPress tiene un `app.kubernetes.io/name` igual a `wordpress` mientras que
+tiene un nombre de instancia, representado como `app.kubernetes.io/instance` con un valor de
+`wordpress-abcxzy`. Esto permite identificar tanto a la aplicación como a sus instancias.
 Cada instancia de una aplicación tiene su propio nombre único.
 
 ## Ejemplos

content/es/docs/concepts/overview/working-with-objects/kubernetes-objects.md

@@ -2,7 +2,7 @@
 title: Entender los Objetos de Kubernetes
 content_template: templates/concept
 weight: 10
-card: 
+card:
   name: concepts
   weight: 40
 ---
@@ -42,7 +42,7 @@ Aquí hay un ejemplo de un archivo `.yaml` que muestra los campos requeridos y l
 {{< codenew file="application/deployment.yaml" >}}
 
 Una forma de crear un Deployment utilizando un archivo `.yaml` como el indicado arriba sería ejecutar el comando
-[`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands#apply) 
+[`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands#apply)
 en el interfaz de línea de comandos, pasándole el archivo `.yaml` como argumento. Aquí tienes un ejemplo de cómo hacerlo:
 
 ```shell
@@ -64,7 +64,7 @@ En el archivo `.yaml` del objeto de Kubernetes que quieras crear, obligatoriamen
 * `metadata` - Datos que permiten identificar unívocamente al objeto, incluyendo una cadena de texto para el `name`, UID, y opcionalmente el `namespace`
 
 También deberás indicar el campo `spec` del objeto. El formato del campo `spec` es diferente según el tipo de objeto de Kubernetes, y contiene campos anidados específicos de cada objeto. La [Referencia de la API de Kubernetes](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) puede servirte de ayuda para encontrar el formato de la spec para cada uno de los objetos que puedes crear usando Kubernetes.
-Por ejemplo, el formato de la `spec` para un objeto de tipo `Pod` lo puedes encontrar 
+Por ejemplo, el formato de la `spec` para un objeto de tipo `Pod` lo puedes encontrar
 [aquí](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core),
 y el formato de la `spec` para un objeto de tipo `Deployment` lo puedes encontrar
 [aquí](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#deploymentspec-v1-apps).

content/es/docs/concepts/overview/working-with-objects/namespaces.md

@@ -17,8 +17,8 @@ Estos clústeres virtuales se denominan espacios de nombres (namespaces).
 ## Cuándo Usar Múltiple Espacios de Nombre
 
 Los espacios de nombres están pensados para utilizarse en entornos con muchos usuarios
-distribuidos entre múltiples equipos, o proyectos. Para aquellos clústeres con 
-unas pocas decenas de usuarios, no deberías necesitar crear o pensar en espacios de 
+distribuidos entre múltiples equipos, o proyectos. Para aquellos clústeres con
+unas pocas decenas de usuarios, no deberías necesitar crear o pensar en espacios de
 nombres en absoluto. Empieza a usarlos solamente si necesitas las características
 que proporcionan.
 
@@ -31,7 +31,7 @@ entre múltiples usuarios (via [cuotas de recursos](/docs/concepts/policy/resour
 En futuras versiones de Kubernetes, los objetos de un mismo espacio de nombres
 tendrán las mismas políticas de control de acceso por defecto.
 
-No es necesario usar múltiples espacios de nombres sólo para separar recursos 
+No es necesario usar múltiples espacios de nombres sólo para separar recursos
 ligeramente diferentes, como versiones diferentes de la misma aplicación: para ello
 utiliza [etiquetas](/docs/user-guide/labels) para distinguir tus recursos dentro
 del mismo espacio de nombres.
@@ -58,8 +58,8 @@ Kubernetes arranca con tres espacios de nombres inicialmente:
 
    * `default` El espacio de nombres por defecto para aquellos objetos que no especifican ningún espacio de nombres
    * `kube-system` El espacio de nombres para aquellos objetos creados por el sistema de Kubernetes
-   * `kube-public` Este espacio de nombres se crea de forma automática y es legible por todos los usuarios (incluyendo aquellos no autenticados). 
-   Este espacio de nombres se reserva principalmente para uso interno del clúster, en caso de que algunos recursos necesiten ser visibles y legibles de forma pública para todo el clúster. 
+   * `kube-public` Este espacio de nombres se crea de forma automática y es legible por todos los usuarios (incluyendo aquellos no autenticados).
+   Este espacio de nombres se reserva principalmente para uso interno del clúster, en caso de que algunos recursos necesiten ser visibles y legibles de forma pública para todo el clúster.
    La naturaleza pública de este espacio de nombres es simplemente por convención, no es un requisito.
 
 ### Establecer el espacio de nombres para una petición