Remove trailing spaces from ES documents(#16742) (#16785)

2019-10-10 15:52:52 +09:00
parent 520caa1264
commit af66c0a274
40 changed files with 167 additions and 167 deletions
@@ -62,7 +62,7 @@ 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
@@ -70,7 +70,7 @@ La mayoría de las funciones del CCM derivan del KCM. Como se ha mencionado en l

 #### 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:

@@ -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

@@ -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 >}}