Objetos de Kubernetes

• 1: Entender los Objetos de Kubernetes
• 2: Nombres
• 3: Espacios de nombres
• 4: Etiquetas y Selectores
• 5: Anotaciones
• 6: Selectores de Campo
• 7: Etiquetas recomendadas

1 - Entender los Objetos de Kubernetes

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.

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. 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.

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.

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:

application/deployment.yaml

apiVersion: apps/v1 # Usa apps/v1beta2 para versiones anteriores a 1.9.0
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 2 # indica al controlador que ejecute 2 pods
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80

Una forma de crear un Deployment utilizando un archivo .yaml como el indicado arriba sería ejecutar el comando kubectl apply en el interfaz de línea de comandos, pasándole el archivo .yaml como argumento. Aquí tienes un ejemplo de cómo hacerlo:

kubectl apply -f https://k8s.io/examples/application/deployment.yaml --record

La salida del comando sería algo parecido a esto:

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 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í, y el formato de la spec para un objeto de tipo Deployment lo puedes encontrar aquí.

Siguientes pasos

• Aprender más acerca de los objetos básicos más importantes de Kubernetes, como el Pod.

2 - Nombres

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 y anotaciones.

Echa un vistazo al documento de diseño de identificadores para información precisa acerca de las reglas sintácticas de los Nombres y UIDs.

Nombres

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.

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

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.

3 - Espacios de nombres

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).

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).

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 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.

Ver espacios de nombre

Puedes listar los espacios de nombres actuales dentro de un clúster mediante:

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:

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.

kubectl config set-context --current --namespace=<insert-namespace-name-here>
# Validate it
kubectl config view | grep namespace:

Espacios de nombres y DNS

Cuando creas un Servicio, se crea una entrada DNS 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 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:

# In a namespace
kubectl api-resources --namespaced=true

# Not in a namespace
kubectl api-resources --namespaced=false

4 - Etiquetas y Selectores

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.

"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.

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, 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.

Nota: 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.

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".

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 clavetier. 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:

kubectl get pods -l environment=production,tier=frontend

o usando requisitos basados en conjunto:

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:

kubectl get pods -l 'environment in (production, qa)'

o restringir la coincidencia negativa mediante el operador exists:

kubectl get pods -l 'environment,environment notin (frontend)'

Establecer referencias en los objetos de la API

Algunos objetos de Kubernetes, como los services y los replicationcontrollers, también hacen uso de los selectores de etiqueta para referirse a otros conjuntos de objetos, como los 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:

"selector": {
    "component" : "redis",
}

ó

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, el Deployment, el Replica Set, y el Daemon Set, sí permiten requisitos basados en conjunto.

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 para más información.

5 - Anotaciones

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.

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:

"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.

Siguientes pasos

Aprende más acerca de las Etiquetas y Selectores.

6 - Selectores de Campo

Los selectores de campo te permiten seleccionar recursos de Kubernetes 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 es igual a Running:

kubectl get pods --field-selector status.phase=Running

Nota:

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:

kubectl get pods
kubectl get pods --field-selector ""

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:

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:

kubectl get services --field-selector metadata.namespace!=default

Selectores anidados

De la misma manera que con una etiqueta 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:

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:

kubectl get statefulsets,services --all-namespaces --field-selector metadata.namespace!=default

7 - Etiquetas recomendadas

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.

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.

Nota: Estas son las etiquetas recomendadas. Estas facilitan la gestión de aplicaciones, pero no son obligatorias para las herramientas en general.

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.

Para ilustrar estas etiquetas en acción, consideremos el siguiente objeto StatefulSet:

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.

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.

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:

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:

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:

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:

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.