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: 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
Puedes indicar de forma permanente el espacio de nombres para todas las llamadas futuras a comandos kubectl
en dicho contexto.
```shell
kubectl config set-context $(kubectl config current-context) --namespace=<insert-namespace-name-here>
# Validate it
kubectl config view | grep namespace:
```
## Espacios de nombres y DNS
Cuando creas un [Servicio](/docs/user-guide/services), se crea una [entrada DNS](/docs/concepts/services-networking/dns-pod-service/) correspondiente.
Esta entrada tiene la forma `<service-name>.<namespace-name>.svc.cluster.local`, que significa
que si un contenedor simplemente usa `<service-name>`, se resolverá al servicio
que sea local al espacio de nombres. Esto es de utilidad para poder emplear la misma
configuración entre múltiples espacios de nombres como Development, Staging y Production.
Si quieres referenciar recursos entre distintos espacios de nombres, entonces
debes utilizar el nombre cualificado completo de dominio (FQDN).
## No Todos los Objetos están en un Espacio de nombres
La mayoría de los recursos de Kubernetes (ej. pods, services, replication controllers, y otros) están
en algunos espacios de nombres. Sin embargo, los recursos que representan a los propios
espacios de nombres no están a su vez en espacios de nombres.
De forma similar, los recursos de bajo nivel, como los nodos [nodos](/docs/admin/node) y
los volúmenes persistentes, no están en ningún espacio de nombres.
Para comprobar qué recursos de Kubernetes están y no están en un espacio de nombres:
```shell
# In a namespace
kubectl api-resources --namespaced=true
# Not in a namespace
kubectl api-resources --namespaced=false
```
{{% /capture %}}
---
title: Nombre
id: name
date: 2018-04-12
full_link: /docs/concepts/overview/working-with-objects/names
short_description: >
Una cadena de caracteres proporcionada por el cliente que identifica un objeto en la URL de un recurso, como por ejemplo, `/api/v1/pods/nombre-del-objeto`.
aka:
tags:
- fundamental
---
Una cadena de caracteres proporcionada por el cliente que identifica un objeto en la URL de un recurso, como por ejemplo, `/api/v1/pods/nombre-del-objeto`.
<!--more-->
Los nombres de los objetos son únicos para cada tipo de objeto. Sin embargo, si se elimina el objeto, se puede crear un nuevo objeto con el mismo nombre.
\ No newline at end of file
---
title: UID
id: uid
date: 2018-04-12
full_link: /docs/concepts/overview/working-with-objects/names
short_description: >
Una cadena de caracteres generada por Kubernetes para identificar objetos de forma única.
aka:
tags:
- fundamental
---
Una cadena de caracteres generada por Kubernetes para identificar objetos de forma única.
<!--more-->
Cada objeto creado a lo largo de toda la vida de un clúster Kubernetes tiene un UID distinto. Está pensado para distinguir entre ocurrencias históricas de entidades similares.
\ No newline at end of file
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment