Add content/es/docs/content/overview/working-with-objects (#14026)

* Spanish Translation

* Spanish Translation

* Add referenced glossary terms

* Add referenced glossary terms

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

@@ -0,0 +1,77 @@
+---
+title: Anotaciones
+content_template: templates/concept
+weight: 50
+---
+
+{{% capture overview %}}
+Puedes usar las anotaciones de Kubernetes para adjuntar metadatos arbitrarios a los objetos, de tal forma que clientes como herramientas y librerías puedan obtener fácilmente dichos metadatos.
+{{% /capture %}}
+
+{{% capture body %}}
+## Adjuntar metadatos a los objetos
+
+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,
+y pueden incluir caracteres no permitidos en las etiquetas.
+
+Las anotaciones, al igual que las etiquetas, son mapas de clave/valor:
+
+```json
+"metadata": {
+  "annotations": {
+    "key1" : "value1",
+    "key2" : "value2"
+  }
+}
+```
+
+Aquí se presentan algunos ejemplos de información que podría ser indicada como anotaciones:
+
+* 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 
+  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,
+  número de PR, funciones hash de imágenes, y direcciones de registro.
+
+* Referencias a los repositorios de trazas, monitorización, analíticas, o auditoría.
+
+* Información de librería de cliente o herramienta que puede usarse con fines de depuración de código:
+  por ejemplo, nombre, versión, e información de construcción.
+
+* Información de usuario o procedencia de herramienta/sistema, como las URLs de los
+  objetos provenientes de otros componentes del ecosistema.
+
+* Metadatos para una herramienta ligera de lanzamiento de aplicaciones: por ejemplo, configuración o puntos de control.
+
+* Número de teléfono o contacto de las personas a cargo, o entradas de directorio que
+  especifican dónde puede encontrarse dicha información, como la página web de un equipo de trabajo.
+
+* Directivas del usuario final a las implementaciones para modificar el comportamiento
+  o solicitar funcionalidades no estándar.
+
+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 
+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, 
+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.
+
+Los prefijos `kubernetes.io/` y `k8s.io/` se reservan para el uso exclusivo de los componentes principales de Kubernetes.
+
+{{% /capture %}}
+
+{{% capture whatsnext %}}
+Aprende más acerca de las [Etiquetas y Selectores](/docs/concepts/overview/working-with-objects/labels/).
+{{% /capture %}}
+
+

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

@@ -0,0 +1,174 @@
+---
+title: Etiquetas recomendadas
+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 
+trabajar de forma interoperable, describiendo los objetos de una forma común que todas las
+herramientas puedan entender.
+
+Además del soporte a herramientas, las etiquetas recomendadas describen las aplicaciones
+de forma que puedan ser consultadas.
+{{% /capture %}}
+
+{{% capture body %}}
+Los metadatos se organizan en torno al concepto de una _aplicación_. Kubernetes no es
+una plataforma como servicio (PaaS) y ni tiene o restringe la definición formal de una aplicación.
+Al contrario, las aplicaciones son informales y se describen mediante el uso de los metadatos.
+La definición de lo que contiene una aplicación es imprecisa.
+
+{{< note >}}
+Estas son las etiquetas recomendadas. Estas facilitan la gestión de aplicaciones,
+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 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.
+
+## Etiquetas
+
+Para beneficiarse al máximo del uso de estas etiquetas, estas deberían aplicarse a cada objeto de recurso.
+
+| Clave                               | Descripción           | Ejemplo  | Tipo |
+| ----------------------------------- | --------------------- | -------- | ---- |
+| `app.kubernetes.io/name`            | El nombre de la aplicación | `mysql` | string |
+| `app.kubernetes.io/instance`        | Un nombre único que identifique la instancia de la aplicación | `wordpress-abcxzy` | string |
+| `app.kubernetes.io/version`         | La versión actual de la aplicación (ej., la versión semántica, cadena hash de revisión, etc.) | `5.7.21` | string |
+| `app.kubernetes.io/component`       | El componente dentro de la arquitectura | `database` | string |
+| `app.kubernetes.io/part-of`         | El nombre de una aplicación de nivel superior de la cual es parte esta aplicación | `wordpress` | string |
+| `app.kubernetes.io/managed-by`  | La herramienta usada para gestionar la operativa de una aplicación | `helm` | string |
+
+Para ilustrar estas etiquetas en acción, consideremos el siguiente objeto StatefulSet:
+
+```yaml
+apiVersion: apps/v1
+kind: StatefulSet
+metadata:
+  labels:
+    app.kubernetes.io/name: mysql
+    app.kubernetes.io/instance: wordpress-abcxzy
+    app.kubernetes.io/version: "5.7.21"
+    app.kubernetes.io/component: database
+    app.kubernetes.io/part-of: wordpress
+    app.kubernetes.io/managed-by: helm
+```
+
+## Aplicaciones e Instancias de Aplicaciones
+
+Una misma aplicación puede desplegarse una o más veces en un clúster de Kubernetes e,
+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. 
+Cada instancia de una aplicación tiene su propio nombre único.
+
+## Ejemplos
+
+Para ilustrar las diferentes formas en que se puede utilizar las etiquetas, los siguientes ejemplos presentan distintas complejidades.
+
+### Un Servicio Simple sin Estado
+
+Considera el caso de un servicio simple sin estado desplegado mediante el uso de un objeto `Deployment` y `Service`. Los dos siguientes extractos de código representan cómo usar las etiquetas de la forma más sencilla.
+
+El objeto `Deployment` se utiliza para supervisar los pods que ejecutan la propia aplicación.
+```yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  labels:
+    app.kubernetes.io/name: myservice
+    app.kubernetes.io/instance: myservice-abcxzy
+...
+```
+
+El objeto `Service` se utiliza para exponer la aplicación.
+```yaml
+apiVersion: v1
+kind: Service
+metadata:
+  labels:
+    app.kubernetes.io/name: myservice
+    app.kubernetes.io/instance: myservice-abcxzy
+...
+```
+
+### Aplicación Web con una Base de Datos
+
+Considera una aplicación un poco más complicada: una aplicación web (WordPress)
+que utiliza una base de datos (MySQL), instalada utilizando Helm. Los siguientes extractos
+de código ilustran la parte inicial de los objetos utilizados para desplegar esta aplicación.
+
+El comienzo del objeto `Deployment` siguiente se utiliza para WordPress:
+
+```yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  labels:
+    app.kubernetes.io/name: wordpress
+    app.kubernetes.io/instance: wordpress-abcxzy
+    app.kubernetes.io/version: "4.9.4"
+    app.kubernetes.io/managed-by: helm
+    app.kubernetes.io/component: server
+    app.kubernetes.io/part-of: wordpress
+...
+```
+
+El objeto `Service` se emplea para exponer WordPress:
+
+```yaml
+apiVersion: v1
+kind: Service
+metadata:
+  labels:
+    app.kubernetes.io/name: wordpress
+    app.kubernetes.io/instance: wordpress-abcxzy
+    app.kubernetes.io/version: "4.9.4"
+    app.kubernetes.io/managed-by: helm
+    app.kubernetes.io/component: server
+    app.kubernetes.io/part-of: wordpress
+...
+```
+
+MySQL se expone como un objeto `StatefulSet` con metadatos tanto para sí mismo como para la aplicación global que lo contiene:
+
+```yaml
+apiVersion: apps/v1
+kind: StatefulSet
+metadata:
+  labels:
+    app.kubernetes.io/name: mysql
+    app.kubernetes.io/instance: wordpress-abcxzy
+    app.kubernetes.io/managed-by: helm
+    app.kubernetes.io/component: database
+    app.kubernetes.io/part-of: wordpress
+    app.kubernetes.io/version: "5.7.21"
+...
+```
+
+El objeto `Service` se usa para exponer MySQL como parte de WordPress:
+
+```yaml
+apiVersion: v1
+kind: Service
+metadata:
+  labels:
+    app.kubernetes.io/name: mysql
+    app.kubernetes.io/instance: wordpress-abcxzy
+    app.kubernetes.io/managed-by: helm
+    app.kubernetes.io/component: database
+    app.kubernetes.io/part-of: wordpress
+    app.kubernetes.io/version: "5.7.21"
+...
+```
+
+Con los objetos `StatefulSet` y `Service` de MySQL te darás cuenta que se incluye la información acerca de MySQL y Wordpress, la aplicación global.
+
+{{% /capture %}}

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

@@ -0,0 +1,60 @@
+---
+title: Selectores de Campo
+weight: 60
+---
+
+Los _selectores de campo_ te permiten [seleccionar recursos de Kubernetes](/docs/concepts/overview/working-with-objects/kubernetes-objects) basados en el valor de uno o más campos del recurso. Aquí se presentan varios ejemplos de consultas de selectores de campo:
+
+* `metadata.name=my-service`
+* `metadata.namespace!=default`
+* `status.phase=Pending`
+
+Este comando `kubectl` selecciona todos los Pods para los cuales el valor del campo [`status.phase`](/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase) es igual a `Running`:
+
+```shell
+kubectl get pods --field-selector status.phase=Running
+```
+
+{{< note >}}
+Los selectores de campo son esencialmente *filtros* de recursos. Por defecto, no se aplica ningún selector/filtro, lo que significa que todos los tipos de recursos son seleccionados. Esto hace que las siguientes consultas con `kubectl` sean equivalentes:
+
+```shell
+kubectl get pods
+kubectl get pods --field-selector ""
+```
+{{< /note >}}
+
+## Campos soportados
+
+Los selectores de campos soportados varían según el tipo de recursos de Kubernetes. Todos los tipos de recursos permiten los campos `metadata.name` y `metadata.namespace`. El uso de un selector de campo no soportado provoca un error. Por ejemplo:
+
+```shell
+kubectl get ingress --field-selector foo.bar=baz
+```
+```
+Error from server (BadRequest): Unable to find "ingresses" that match label selector "", field selector "foo.bar=baz": "foo.bar" is not a known field selector: only "metadata.name", "metadata.namespace"
+```
+
+## Operadores soportados
+
+Puedes usar los operadores `=`, `==`, y `!=` en los selectores de campo (`=` y `==` significan lo mismo). Este comando de `kubectl`, por ejemplo, selecciona todos los servicios de Kubernetes que no están en el espacio de nombres `default`:
+
+```shell
+kubectl get services --field-selector metadata.namespace!=default
+```
+
+## Selectores anidados
+
+De la misma manera que con una [etiqueta](/docs/concepts/overview/working-with-objects/labels) y otros selectores, los selectores de campo pueden anidarse como una lista de elementos separados por coma. Este comando de `kubectl` selecciona todos los Pods para los que el campo `status.phase` no es igual a `Running` y el campo `spec.restartPolicy` es igual a `Always`:
+
+```shell
+kubectl get pods --field-selector=status.phase!=Running,spec.restartPolicy=Always
+```
+
+## Múltiples tipos de recursos
+
+Puedes usar los selectores de campo entre múltiples tipos de recursos. Este comando de `kubectl` selecciona todos los Statefulsets y Services que no están en el espacio de nombres `default`:
+
+```shell
+kubectl get statefulsets,services --field-selector metadata.namespace!=default
+```

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

@@ -0,0 +1,78 @@
+---
+title: Entender los Objetos de Kubernetes
+content_template: templates/concept
+weight: 10
+card: 
+  name: concepts
+  weight: 40
+---
+
+{{% capture overview %}}
+Esta página explica cómo se representan los objetos de Kubernetes en la API de Kubernetes, y cómo puedes definirlos en formato `.yaml`.
+{{% /capture %}}
+
+{{% capture body %}}
+## Entender los Objetos de Kubernetes
+
+Los *Objetos de Kubernetes* son entidades persistentes dentro del sistema de Kubernetes. Kubernetes utiliza estas entidades para representar el estado de tu clúster. Específicamente, pueden describir:
+
+* Qué aplicaciones corren en contenedores (y en qué nodos)
+* Los recursos disponibles para dichas aplicaciones
+* Las políticas acerca de cómo dichas aplicaciones se comportan, como las políticas de reinicio, actualización, y tolerancia a fallos
+
+Un objeto de Kubernetes es un "registro de intención" -- una vez que has creado el objeto, el sistema de Kubernetes se pondrá en marcha para asegurar que el objeto existe. Al crear un objeto, en realidad le estás diciendo al sistema de Kubernetes cómo quieres que sea la carga de trabajo de tu clúster; esto es, el **estado deseado** de tu clúster.
+
+Para trabajar con los objetos de Kubernetes -- sea para crearlos, modificarlos, o borrarlos -- necesitarás usar la [API de Kubernetes](/docs/concepts/overview/kubernetes-api/). Cuando utilizas el interfaz de línea de comandos `kubectl`, por ejemplo, este realiza las llamadas necesarias a la API de Kubernetes en tu lugar. También puedes usar la API de Kubernetes directamente desde tus programas utilizando alguna de las [Librerías de Cliente](/docs/reference/using-api/client-libraries/).
+
+### Alcance y Estado de un Objeto
+
+Cada objeto de Kubernetes incluye dos campos como objetos anidados que determinan la configuración del objeto: el campo de objeto *spec* y el campo de objeto *status*. El campo *spec*, que es obligatorio, describe el *estado deseado* del objeto -- las características que quieres que tenga el objeto. El campo *status* describe el *estado actual* del objeto, y se suministra y actualiza directamente por el sistema de Kubernetes. En cualquier momento, el Plano de Control de Kubernetes gestiona de forma activa el estado actual del objeto para que coincida con el estado deseado requerido.
+
+
+Por ejemplo, un Deployment de Kubernetes es un objeto que puede representar una aplicación de tu clúster. Cuando creas el Deployment, puedes especificar en el spec del Deployment que quieres correr tres réplicas de la aplicación. El sistema de Kubernetes lee el spec del Deployment y comienza a instanciar réplicas de tu aplicación -- actualizando el estado para conciliarlo con tu spec. Si cualquiera de las instancias falla (un cambio de estado), el sistema de Kubernetes soluciona la diferencia entre la spec y el estado llevando a cabo una correción -- en este caso, iniciando otra instancia de reemplazo.
+
+Para obtener más información acerca de la spec, el status, y los metadatos de los objetos, echa un vistazo a las [Normas de la API de Kubernetes](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md).
+
+### Describir un Objeto de Kubernetes
+
+Cuando creas un objeto en Kubernetes, debes especificar la spec del objeto que describe su estado deseado, así como información básica del mismo (como el nombre). Cuando usas la API de Kubernetes para crear el objeto (bien de forma directa o usando `kubectl`), dicha petición a la API debe incluir toda la información en formato JSON en el cuerpo de la petición. **A menudo, le proporcionas la información a `kubectl` como un archivo .yaml.** `kubectl` convierte esa información a JSON cuando realiza la llamada a la API.
+
+Aquí hay un ejemplo de un archivo `.yaml` que muestra los campos requeridos y la spec del objeto Deployment de Kubernetes:
+
+{{< 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) 
+en el interfaz de línea de comandos, pasándole el archivo `.yaml` como argumento. Aquí tienes un ejemplo de cómo hacerlo:
+
+```shell
+kubectl apply -f https://k8s.io/examples/application/deployment.yaml --record
+```
+
+La salida del comando sería algo parecido a esto:
+
+```shell
+deployment.apps/nginx-deployment created
+```
+
+### Campos requeridos
+
+En el archivo `.yaml` del objeto de Kubernetes que quieras crear, obligatoriamente tendrás que indicar los valores de los siguientes campos (como mínimo):
+
+* `apiVersion` - Qué versión de la API de Kubernetes estás usando para crear este objeto
+* `kind` - Qué clase de objeto quieres crear
+* `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 
+[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).
+
+{{% /capture %}}
+
+{{% capture whatsnext %}}
+* Aprender más acerca de los objetos básicos más importantes de Kubernetes, como el [Pod](/docs/concepts/workloads/pods/pod-overview/).
+{{% /capture %}}
+
+