diff --git a/content/es/docs/concepts/overview/working-with-objects/annotations.md b/content/es/docs/concepts/overview/working-with-objects/annotations.md new file mode 100644 index 0000000000000..7b9b6885eac74 --- /dev/null +++ b/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 %}} + + diff --git a/content/es/docs/concepts/overview/working-with-objects/common-labels.md b/content/es/docs/concepts/overview/working-with-objects/common-labels.md new file mode 100644 index 0000000000000..d18427d5ce947 --- /dev/null +++ b/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 %}} \ No newline at end of file diff --git a/content/es/docs/concepts/overview/working-with-objects/field-selectors.md b/content/es/docs/concepts/overview/working-with-objects/field-selectors.md new file mode 100644 index 0000000000000..830467d7b9b36 --- /dev/null +++ b/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 +``` diff --git a/content/es/docs/concepts/overview/working-with-objects/kubernetes-objects.md b/content/es/docs/concepts/overview/working-with-objects/kubernetes-objects.md new file mode 100644 index 0000000000000..7ffb93c771364 --- /dev/null +++ b/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 %}} + + diff --git a/content/es/docs/concepts/overview/working-with-objects/labels.md b/content/es/docs/concepts/overview/working-with-objects/labels.md new file mode 100644 index 0000000000000..ae42584883364 --- /dev/null +++ b/content/es/docs/concepts/overview/working-with-objects/labels.md @@ -0,0 +1,204 @@ +--- +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 %}} diff --git a/content/es/docs/concepts/overview/working-with-objects/names.md b/content/es/docs/concepts/overview/working-with-objects/names.md new file mode 100644 index 0000000000000..75e64b963efde --- /dev/null +++ b/content/es/docs/concepts/overview/working-with-objects/names.md @@ -0,0 +1,30 @@ +--- +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 %}} diff --git a/content/es/docs/concepts/overview/working-with-objects/namespaces.md b/content/es/docs/concepts/overview/working-with-objects/namespaces.md new file mode 100644 index 0000000000000..e4ad987e0fad7 --- /dev/null +++ b/content/es/docs/concepts/overview/working-with-objects/namespaces.md @@ -0,0 +1,115 @@ +--- +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= run nginx --image=nginx +kubectl --namespace= 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= +# 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 `..svc.cluster.local`, que significa +que si un contenedor simplemente usa ``, 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 %}} diff --git a/content/es/docs/reference/glossary/name.md b/content/es/docs/reference/glossary/name.md new file mode 100644 index 0000000000000..d9c81d446d352 --- /dev/null +++ b/content/es/docs/reference/glossary/name.md @@ -0,0 +1,17 @@ +--- +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`. + + + +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 diff --git a/content/es/docs/reference/glossary/uid.md b/content/es/docs/reference/glossary/uid.md new file mode 100644 index 0000000000000..5e5a3a924aca9 --- /dev/null +++ b/content/es/docs/reference/glossary/uid.md @@ -0,0 +1,17 @@ +--- +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. + + + +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