Commit bd333c5b authored by Enrique Medina Montenegro's avatar Enrique Medina Montenegro Committed by Kubernetes Prow Robot

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

* Spanish Translation

* Spanish Translation

* Add referenced glossary terms

* Add referenced glossary terms
parent 54814e6e
---
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 %}}
---
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 %}}
\ No newline at end of file
---
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
```
---
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 %}}
---
title: Etiquetas y Selectores
content_template: templates/concept
weight: 40
---
{{% capture overview %}}
Las _etiquetas_ son pares de clave/valor que se asocian a los objetos, como los pods.
El propósito de las etiquetas es permitir identificar atributos de los objetos que son relevantes y significativos para los usuarios, pero que no tienen significado para el sistema principal.
Se puede usar las etiquetas para organizar y seleccionar subconjuntos de objetos. Las etiquetas se pueden asociar a los objetos a la hora de crearlos y posteriormente modificarlas o añadir nuevas.
Cada objeto puede tener un conjunto de etiquetas clave/valor definidas, donde cada clave debe ser única para un mismo objeto.
```json
"metadata": {
"labels": {
"key1" : "value1",
"key2" : "value2"
}
}
```
Las etiquetas permiten consultar y monitorizar los objetos de forma más eficiente y son ideales para su uso en UIs y CLIs. El resto de información no identificada debe ser registrada usando [anotaciones](/docs/concepts/overview/working-with-objects/annotations/).
{{% /capture %}}
{{% capture body %}}
## Motivación
Las etiquetas permiten que los usuarios mapeen sus estructuras organizacionales en los propios objetos sin acoplamiento, sin forzar a los clientes a almacenar estos mapeos.
Los despliegues de servicios y los procesos en lotes suelen requerir a menudo la gestión de entidades multi-dimensionales (ej., múltiples particiones o despliegues, múltiples entregas, múltiples capas, múltiples microservicios por capa). Tal gestión a menudo requiere de operaciones horizontales que rompen la encapsulación de representaciones estrictamente jerárquicas, especialmente jerarquías rígidas determinadas por la infraestructura en vez de por los usuarios.
Ejemplos de etiquetas:
* `"release" : "stable"`, `"release" : "canary"`
* `"environment" : "dev"`, `"environment" : "qa"`, `"environment" : "production"`
* `"tier" : "frontend"`, `"tier" : "backend"`, `"tier" : "cache"`
* `"partition" : "customerA"`, `"partition" : "customerB"`
* `"track" : "daily"`, `"track" : "weekly"`
Estos son sólo algunos ejemplos de etiquetas de uso común; eres libre de establecer tus propias normas. Ten en cuenta que la clave de cada etiqueta debe ser única dentro de cada objeto.
## Sintaxis y conjunto de caracteres
Las _etiquetas_ son pares de clave/valor. Las claves válidas de etiqueta tienen dos partes: un prefijo opcional y un nombre, separados por una barra (`/`). La parte del nombre es obligatoria y debe ser menor o igual a 63 caracteres, empezando y terminando con un carácter alfanumérico (`[a-z0-9A-Z]`), con guiones (`-`), guiones bajos (`_`), puntos (`.`), y cualquier carácter alfanumérico en medio. El prefijo es opcional. Si se indica, este debe ser un subdominio DNS: una serie de etiquetas DNS separadas por puntos (`.`), no mayores de 253 caracteres en total, seguidas de una barra (`/`).
Si se omite el prefijo, la clave de la etiqueta se entiende que es privada para el usuario. Los componentes automatizados del sistema (ej. `kube-scheduler`, `kube-controller-manager`, `kube-apiserver`, `kubectl`, u otros de terceras partes) que añaden etiquetas a los objetos de usuario deben especificar obligatoriamente un prefijo.
Los prefijos `kubernetes.io/` y `k8s.io/` están reservados para el sistema de Kubernetes.
Los valores de etiqueta válidos deben tener como máximo 63 caracteres y empezar y terminar con un carácter alfanumérico (`[a-z0-9A-Z]`), con guiones (`-`), guiones bajos (`_`), puntos (`.`), y cualquier carácter alfanumérico en medio.
## Selectores de etiquetas
Al contrario que los [nombres y UIDs](/docs/user-guide/identifiers), las etiquetas no garantizan la unicidad. En general, se espera que muchos objetos compartan la(s) misma(s) etiqueta(s).
A través del _selector de etiqueta_, el cliente/usuario puede identificar un conjunto de objetos. El selector de etiqueta es la primitiva principal de agrupación en Kubernetes.
La API actualmente soporta dos tipos de selectores: _basados en igualdad_ y _basados en conjunto_.
Un selector de etiqueta puede componerse de múltiples _requisitos_ separados por coma. En el caso de múltiples requisitos, todos ellos deben ser satisfechos de forma que las comas actúan como operadores _AND_ (`&&`) lógicos.
La semántica de selectores vacíos o no espefificados es dependiente del contexto,
y los tipos de la API que utilizan los selectores deberían documentar su propia validación y significado.
{{< note >}}
Para algunos tipos de la API, como los ReplicaSets, los selectores de etiqueta de dos instancias no deben superponerse dentro del mismo espacio de nombres, ya que el controlador puede interpretarlos como un conflicto y no ser capaz de determinar cuántas réplicas debería haber finalmente.
{{< /note >}}
### Requisito _basado en Igualdad_
Los requisitos basados en _Igualdad_ o _Desigualdad_ permiten filtrar por claves y valores de etiqueta. Los objetos coincidentes deben satisfacer todas y cada una de las etiquetas indicadas, aunque puedan tener otras etiquetas adicionalmente.
Se permiten tres clases de operadores `=`,`==`,`!=`. Los dos primeros representan la _igualdad_ (y son simplemente sinónimos), mientras que el último representa la _desigualdad_. Por ejemplo:
```
environment = production
tier != frontend
```
El primero selecciona todos los recursos cuya clave es igual a `environment` y su valor es igual a `production`.
El último selecciona todos los recursos cuya clave es igual a `tier` y su valor distinto de `frontend`, y todos los recursos que no tengan etiquetas con la clave `tier`.
Se podría filtrar los recursos de `production` que excluyan `frontend` usando comas: `environment=production,tier!=frontend`
Un escenario de uso de requisitos basados en igualdad es aquel donde los Pods pueden especificar
los criterios de selección de nodo. Por ejemplo, el Pod de abajo selecciona aquellos nodos con
la etiqueta "`accelerator=nvidia-tesla-p100`".
```yaml
apiVersion: v1
kind: Pod
metadata:
name: cuda-test
spec:
containers:
- name: cuda-test
image: "k8s.gcr.io/cuda-vector-add:v0.1"
resources:
limits:
nvidia.com/gpu: 1
nodeSelector:
accelerator: nvidia-tesla-p100
```
### Requisito _basado en Conjunto_
Los requisitos de etiqueta basados en _Conjuntos_ permiten el filtro de claves en base a un conjunto de valores. Se puede utilizar tres tipos de operadores: `in`,`notin` y `exists` (sólo el identificador clave). Por ejemplo:
```
environment in (production, qa)
tier notin (frontend, backend)
partition
!partition
```
El primer ejemplo selecciona todos los recursos cuya clave es igual a `environment` y su valor es igual a `production` o `qa`.
El segundo ejemplo selecciona todos los recursos cuya clave es igual a `tier` y sus valores son distintos de `frontend` y `backend`, y todos los recursos que no tengan etiquetas con la clave`tier`.
El tercer ejemplo selecciona todos los recursos que incluyan una etiqueta con la clave `partition`; sin comprobar los valores.
El cuarto ejemplo selecciona todos los recursos que no incluyan una etiqueta con la clave `partition`; sin comprobar los valores.
De forma similar, el separador de coma actúa como un operador _AND_ . Así, el filtro de recursos con una clave igual a `partition` (sin importar el valor) y con un `environment` distinto de `qa` puede expresarse como `partition,environment notin (qa)`.
El selector _basado en conjunto_ es una forma genérica de igualdad puesto que `environment=production` es equivalente a `environment in (production)`; y lo mismo aplica para `!=` y `notin`.
Los requisitos _basados en conjunto_ pueden alternarse con aquellos _basados en igualdad_. Por ejemplo: `partition in (customerA, customerB),environment!=qa`.
## API
### Filtro con LIST y WATCH
Las operaciones LIST y WATCH pueden especificar selectores de etiqueta para filtrar el conjunto de objetos devueltos usando un parámetro de consulta. Ambos requisitos están permitidos (se presentan aquí como aparecerían en la cadena URL de consulta):
* requisitios _basados en igualdad_: `?labelSelector=environment%3Dproduction,tier%3Dfrontend`
* requisitios _basados en conjunto_: `?labelSelector=environment+in+%28production%2Cqa%29%2Ctier+in+%28frontend%29`
Es posible utilizar ambos estilos de selección de etiquetas para mostrar u observar recursos con un cliente REST. Por ejemplo, para enfocarse en `apiserver` con `kubectl` usando el estilo _basado en igualdad_ se puede ejecutar:
```shell
kubectl get pods -l environment=production,tier=frontend
```
o usando requisitos _basados en conjunto_:
```shell
kubectl get pods -l 'environment in (production),tier in (frontend)'
```
Como ya se ha comentado, los requisitos _basados en conjunto_ son más expresivos.  Por ejemplo, se puede implementar el operador _OR_ sobre valores:
```shell
kubectl get pods -l 'environment in (production, qa)'
```
o restringir la coincidencia negativa mediante el operador _exists_:
```shell
kubectl get pods -l 'environment,environment notin (frontend)'
```
### Establecer referencias en los objetos de la API
Algunos objetos de Kubernetes, como los [`services`](/docs/user-guide/services) y los [`replicationcontrollers`](/docs/user-guide/replication-controller), también hacen uso de los selectores de etiqueta para referirse a otros conjuntos de objetos, como los [pods](/docs/user-guide/pods).
#### Service y ReplicationController
El conjunto de pods que un `service` expone se define con un selector de etiqueta. De forma similar, el conjunto de pods que un `replicationcontroller` debería gestionar se define con un selector de etiqueta.
Los selectores de etiqueta para ambos objetos se definen en los archivos `json` o `yaml` usando mapas, y únicamente se permite los selectores _basados en igualad_:
```json
"selector": {
"component" : "redis",
}
```
ó
```yaml
selector:
component: redis
```
este selector (respectivamente en formato `json` o `yaml`) es equivalente a `component=redis` o `component in (redis)`.
#### Recursos que soportan requisitos basados en conjunto
Algunos recursos más recientes, como el [`Job`](/docs/concepts/jobs/run-to-completion-finite-workloads/), el [`Deployment`](/docs/concepts/workloads/controllers/deployment/), el [`Replica Set`](/docs/concepts/workloads/controllers/replicaset/), y el [`Daemon Set`](/docs/concepts/workloads/controllers/daemonset/), sí permiten requisitos _basados en conjunto_.
```yaml
selector:
matchLabels:
component: redis
matchExpressions:
- {key: tier, operator: In, values: [cache]}
- {key: environment, operator: NotIn, values: [dev]}
```
`matchLabels` es un mapa de pares `{key,value}`. Una única combinación de `{key,value}` en el mapa `matchLabels` es equivalente a un elemento en `matchExpressions` donde el campo `key` es "key", el `operator` es "In", y la matriz `values` contiene únicamente "value". `matchExpressions` es una lista de requisitos de selección de pod. Los operadores permitidos son In, NotIn, Exists, y DoesNotExist. El conjunto de valores no puede ser vacío en el caso particular de In y NotIn. Todos los requisitos, tanto de `matchLabels` como de `matchExpressions` se combinan entre sí con el operador AND -- todos ellos deben ser satisfechos.
#### Seleccionar conjuntos de objetos
Un caso de uso de selección basada en etiquetas es la posibilidad de limitar los nodos en los que un pod puede desplegarse.
Ver la documentación sobre [selección de nodo](/docs/concepts/configuration/assign-pod-node/) para más información.
{{% /capture %}}
---
title: Nombres
content_template: templates/concept
weight: 20
---
{{% capture overview %}}
Todos los objetos de la API REST de Kubernetes se identifica de forma inequívoca mediante un Nombre y un UID.
Para aquellos atributos provistos por el usuario que no son únicos, Kubernetes provee de [etiquetas](/docs/user-guide/labels) y [anotaciones](/docs/concepts/overview/working-with-objects/annotations/).
Echa un vistazo al [documento de diseño de identificadores](https://git.k8s.io/community/contributors/design-proposals/architecture/identifiers.md) para información precisa acerca de las reglas sintácticas de los Nombres y UIDs.
{{% /capture %}}
{{% capture body %}}
## Nombres
{{< glossary_definition term_id="name" length="all" >}}
Por regla general, los nombres de los recursos de Kubernetes no deben exceder la longitud máxima de 253 caracteres y deben incluir caracteres alfanuméricos en minúscula, `-`, y `.`; aunque algunos recursos tienen restricciones más específicas.
## UIDs
{{< glossary_definition term_id="uid" length="all" >}}
{{% /capture %}}
---
title: Espacios de nombres
content_template: templates/concept
weight: 30
---
{{% capture overview %}}
Kubernetes soporta múltiples clústeres virtuales respaldados por el mismo clúster físico.
Estos clústeres virtuales se denominan espacios de nombres (namespaces).
{{% /capture %}}
{{% capture body %}}
## 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
nombres en absoluto. Empieza a usarlos solamente si necesitas las características
que proporcionan.
Los espacios de nombres proporcionan un campo de acción para los nombres. Los nombres de los recursos
tienen que ser únicos dentro de cada espacio de nombres, pero no entre dichos espacios de nombres.
Los espacios de nombres son una forma de dividir los recursos del clúster
entre múltiples usuarios (via [cuotas de recursos](/docs/concepts/policy/resource-quotas/)).
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
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.
## Trabajar con Espacios de Nombres
La creación y borrado de espacios de nombres se describe en la [documentación de la Guía de Administración para espacios de nombres](/docs/admin/namespaces).
### Ver espacios de nombre
Puedes listar los espacios de nombres actuales dentro de un clúster mediante:
```shell
kubectl get namespaces
```
```
NAME STATUS AGE
default Active 1d
kube-system Active 1d
kube-public Active 1d
```
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.
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
Para indicar de forma temporal el espacio de nombres para una petición, usa la opción `--namespace`.
Por ejemplo:
```shell
kubectl --namespace=<insert-namespace-name-here> run nginx --image=nginx
kubectl --namespace=<insert-namespace-name-here> get pods
```
### Establecer la preferencia de espacio de nombres