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
@@ -4,7 +4,7 @@ reviewers:
 title: ¿Qué es Kubernetes?
 content_template: templates/concept
 weight: 10
-card: 
+card:
  name: concepts
  weight: 10
 ---
@@ -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.
@@ -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
@@ -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).
@@ -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