Introducción
En Kubernetes para principiantes, utilizaste kubectl get, describe y las etiquetas para comprobar si una aplicación funcionaba correctamente. Los clústeres reales contienen muchos objetos, por lo que la siguiente habilidad consiste en formular preguntas más concretas y extraer únicamente la información que necesitas.
En este laboratorio, implementarás una pequeña carga de trabajo de una tienda y la inspeccionarás desde varios ángulos: namespace, etiquetas, campos estructurados, propiedad del controlador y eventos. Al final, tendrás un comando compacto que relaciona un Deployment con los Pods que administra.
No necesitas memorizar todos los formatos de salida. En su lugar, practica cómo convertir una pregunta en una consulta precisa: «¿Qué objetos existen?», «¿Qué Pods coinciden con este Service?», «¿Quién es el propietario de este Pod?» o «¿Qué ha ocurrido recientemente?». Cada paso añade una herramienta al flujo de inspección.
Crear un espacio de trabajo delimitado
En este paso, crearás un namespace e implementarás en él los recursos preparados. Un namespace limita el alcance de las consultas posteriores y evita confundir objetos con nombres similares.
Accede al espacio de trabajo del laboratorio y, antes de modificar el estado del clúster, inspecciona el contexto actual. cd cambia el directorio de trabajo del shell, por lo que los nombres de archivo relativos posteriores, como storefront.yaml, harán referencia al espacio de trabajo preparado.
cd /home/labex/project/resource-inspection
kubectl config current-context
La salida debe ser labex-v135. Crea el namespace y aplica el manifiesto preparado con varios documentos:
kubectl create namespace practice-observe
kubectl apply -f storefront.yaml
kubectl rollout status deployment/storefront -n practice-observe --timeout=60s
Las últimas líneas deberían tener este aspecto. Mientras se inician los dos Pods, pueden aparecer mensajes intermedios del despliegue:
namespace/practice-observe created
deployment.apps/storefront created
service/storefront created
deployment "storefront" successfully rolled out
-n practice-observe limita el comando a ese namespace. El comando de despliegue espera hasta que las dos réplicas del Deployment estén disponibles, en lugar de depender de una espera arbitraria.
Utilizarás -n practice-observe repetidamente. De lo contrario, los comandos de Kubernetes usan el namespace configurado en el contexto actual —normalmente default— y un objeto correcto podría parecer «inexistente» simplemente porque consultaste el ámbito equivocado.
Descubrir recursos y su ámbito
En este paso, utilizarás el descubrimiento de la API antes de consultar objetos. kubectl api-resources muestra los nombres de los recursos que entiende el servidor de API actual, junto con sus nombres abreviados e indica si cada recurso pertenece a un namespace. La tubería hacia head limita el listado inicial a sus diez primeras líneas para evitar saturar el terminal.
kubectl api-resources | head
kubectl api-resources --namespaced=true | grep -E 'pods|deployments|services'
La tubería pasa la lista de recursos a grep. -E habilita la alternancia mediante |, de modo que un solo comando puede buscar varios nombres de recursos. Observa que Pods, Deployments y Services pertenecen a namespaces.
Enumera los objetos de la aplicación usando sus nombres completos y repite después la consulta con nombres abreviados habituales:
kubectl get pods,deployments,services -n practice-observe
kubectl get po,deploy,svc -n practice-observe
Ambos comandos consultan los mismos recursos de la API. Los nombres abreviados ahorran escritura, pero los nombres completos son más claros en scripts y documentación.
Deberías ver un Deployment, dos Pods generados y un Service. La lista de recursos separada por comas solo es una comodidad para la consulta; estos objetos siguen teniendo funciones y esquemas de API distintos.
Los prefijos de tipo facilitan la interpretación de la salida combinada. Los sufijos generados, las direcciones y las antigüedades variarán:
NAME READY STATUS RESTARTS AGE
pod/storefront-... 1/1 Running 0 ...
pod/storefront-... 1/1 Running 0 ...
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/storefront 2/2 2 2 ...
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/storefront ClusterIP ... <none> 80/TCP ...
Filtrar con etiquetas y selectores
En este paso, utilizarás las etiquetas como metadatos consultables. --show-labels muestra todas las etiquetas, mientras que -l selecciona únicamente los objetos cuyas etiquetas coinciden con una expresión.
kubectl get pods -n practice-observe --show-labels
kubectl get pods -n practice-observe -l app=storefront
kubectl get pods -n practice-observe -l 'app=storefront,tier=web'
Una coma entre los requisitos del selector representa una conjunción lógica (AND). Por tanto, la última consulta devuelve los Pods que contienen ambas etiquetas.
Compara el selector del Service con las etiquetas de los Pods seleccionados:
kubectl get service storefront -n practice-observe -o jsonpath='Service selector: {.spec.selector.app}{"\n"}'
kubectl get pods -n practice-observe -l app=storefront -o custom-columns='NAME:.metadata.name,TIER:.metadata.labels.tier,IP:.status.podIP,READY:.status.containerStatuses[0].ready'
kubectl get endpointslices -n practice-observe -l kubernetes.io/service-name=storefront
JSONPath extrae un campo del Service. -o custom-columns genera una tabla compacta a partir de varios campos de los Pods. Este método es más fiable que buscar visualmente en un documento YAML extenso.
El último comando solicita los EndpointSlices cuya etiqueta gestionada automáticamente, kubernetes.io/service-name, pertenece a storefront. Un EndpointSlice registra los extremos de red seleccionados para un Service. Una columna ENDPOINTS no vacía demuestra que las etiquetas coincidentes han producido backends accesibles por red.
El selector del Service debería mostrar storefront, y ambas filas de la tabla de Pods deberían incluir tier=web. La etiqueta app coincidente es el vínculo: un Service descubre Pods mediante etiquetas, no mediante la relación de propiedad del Deployment.
Service selector: storefront
NAME TIER IP READY
storefront-... web 10.244... true
storefront-... web 10.244... true
NAME ADDRESSTYPE PORTS ENDPOINTS AGE
storefront-... IPv4 80 10.244...,10.244... ...
Seguir la propiedad de los controladores
En este paso, seguirás la relación de propiedad de Kubernetes desde el Deployment hasta su ReplicaSet y sus Pods. Los controladores adjuntan ownerReferences para que Kubernetes sepa qué objeto de nivel superior administra cada objeto dependiente.
kubectl get replicasets -n practice-observe -l app=storefront
kubectl get replicasets -n practice-observe -l app=storefront -o custom-columns='REPLICASET:.metadata.name,OWNER_KIND:.metadata.ownerReferences[0].kind,OWNER_NAME:.metadata.ownerReferences[0].name'
kubectl get pods -n practice-observe -l app=storefront -o custom-columns='POD:.metadata.name,OWNER_KIND:.metadata.ownerReferences[0].kind,OWNER_NAME:.metadata.ownerReferences[0].name'
El propietario del ReplicaSet debería ser el Deployment storefront. El propietario de cada Pod es el ReplicaSet generado, no el Deployment directamente:
Deployment/storefront -> ReplicaSet/storefront-... -> Pod/storefront-...
Utiliza kubectl describe cuando necesites esta relación junto con las condiciones y los eventos recientes:
kubectl describe deployment storefront -n practice-observe
No leas describe de principio a fin cada vez. Para esta pregunta, concéntrate en Selector, los recuentos de réplicas, las condiciones y los eventos. El mejor comando de inspección es el que responde a la pregunta actual con el menor ruido posible.
Leer los eventos como una línea temporal
En este paso, inspeccionarás los eventos como evidencias ordenadas cronológicamente. Los eventos describen acciones relacionadas con la programación, las imágenes, los contenedores y los controladores, pero son diagnósticos temporales, no registros de auditoría permanentes.
kubectl get events -n practice-observe --sort-by=.metadata.creationTimestamp
--sort-by ordena los objetos utilizando una ruta de campo. Limita primero la línea temporal al Deployment y después a uno de los Pods seleccionados:
kubectl events -n practice-observe --for deployment/storefront
POD_NAME=$(kubectl get pods -n practice-observe -l app=storefront -o jsonpath='{.items[0].metadata.name}')
echo "$POD_NAME"
kubectl events -n practice-observe --for "pod/${POD_NAME}"
$(...) es una sustitución de comandos: el shell ejecuta el comando interno y almacena su salida en POD_NAME. Ahora dispones de un proceso de inspección repetible: delimitar el namespace, seleccionar mediante etiquetas, extraer campos, seguir las relaciones de propiedad y terminar con la línea temporal de eventos relevante.
Los nombres de los Pods generados por los controladores cambian cuando se reemplazan, por lo que es más seguro seleccionar el nombre actual mediante una etiqueta que copiar un valor antiguo. Este patrón volverá a aparecer en los laboratorios de resolución de problemas.
El ciclo de vida correcto observado normalmente incluye Scheduled, Pulled, Created y Started. Un clúster local recién iniciado también puede conservar una advertencia anterior, como FailedCreatePodSandBox, mientras Calico termina de estar listo. No concluyas que la aplicación sigue fallando basándote únicamente en una advertencia antigua: compara su marca temporal con los eventos normales posteriores y confirma el estado actual de READY del Pod. Las marcas temporales y los nombres generados de los Pods se omiten intencionadamente porque cambian en cada ejecución.
Resumen
Inspeccionaste una aplicación de Kubernetes sin revisar objetos no relacionados. Combinaste namespaces, etiquetas, JSONPath, columnas personalizadas, referencias de propiedad y eventos para pasar de un inventario general a evidencias operativas precisas. En el siguiente laboratorio aplicarás este flujo de inspección a Pods y contenedores que presentan errores.
