Introducción
kubectl es la herramienta de línea de comandos que utilizarás durante todo tu trabajo con Kubernetes al estilo CKAD. Antes de crear Pods, Deployments, Services u objetos de configuración, necesitas saber a qué clúster se está conectando kubectl y qué espacio de nombres (namespace) utilizan tus comandos de forma predeterminada.
En este laboratorio, inspeccionarás el contexto activo de Kubernetes, listarás los espacios de nombres, establecerás un espacio de nombres de práctica como el actual y crearás un pequeño ConfigMap para observar cómo se aíslan los objetos dentro de los espacios de nombres. Las comprobaciones se centran en el estado clave de Kubernetes que creas, no en el formato exacto de la salida de los comandos.
Confirmar el acceso a kubectl
En este paso, confirmarás que kubectl puede comunicarse con el clúster de Kubernetes preparado e identificarás el contexto que están utilizando tus comandos.
Comienza en /home/labex/project. El comando mkdir -p crea el directorio si no existe y no realiza ninguna acción si ya está presente. Este curso mantiene el trabajo del estudiante en ese directorio para que los laboratorios posteriores puedan crear manifiestos y archivos auxiliares en una ubicación predecible.
mkdir -p /home/labex/project
cd /home/labex/project
Un contexto de Kubernetes es una configuración de conexión guardada en tu archivo kubeconfig. Le indica a kubectl qué clúster, credenciales de usuario y espacio de nombres predeterminado debe utilizar. Verifica el contexto activo antes de ejecutar cualquier comando que modifique objetos.
kubectl config current-context
Deberías ver el nombre del perfil de Kubernetes de LabEx preparado:
labex-v135
Para tener un punto de partida predecible, establece el espacio de nombres del contexto actual en default. Aquí no estás creando ningún objeto; solo le estás indicando a kubectl qué espacio de nombres usar cuando un comando posterior omita el parámetro --namespace.
kubectl config set-context --current --namespace=default
La salida debería confirmar que el contexto actual se ha actualizado:
Context "labex-v135" modified.
Es posible que el perfil de Kubernetes necesite un breve momento para terminar de iniciarse después de que aparezca la máquina virtual. Primero, lista los nodos del clúster. Si este comando informa que el servidor de API aún no está listo, espera unos segundos y vuelve a ejecutar el mismo comando hasta que veas un nodo en estado Ready.
kubectl get nodes --request-timeout=5s
La salida esperada incluirá un nodo listo y la versión de Kubernetes:
NAME STATUS ROLES AGE VERSION
labex-v135 Ready control-plane ... v1.35...
Ahora solicita al servidor de API información básica sobre el clúster. Esto demuestra que tu terminal no solo está encontrando el binario de kubectl, sino que realmente está autenticado en un clúster en ejecución.
kubectl cluster-info
La salida debería mencionar el endpoint del plano de control de Kubernetes:
Kubernetes control plane is running at ...
...
Leer espacios de nombres
En este paso, inspeccionarás los espacios de nombres de Kubernetes y verificarás qué espacio de nombres utiliza tu contexto actual de forma predeterminada.
Los espacios de nombres son una forma de dividir los objetos de Kubernetes en ámbitos separados dentro del mismo clúster. Muchos recursos de aplicaciones, como Pods, Deployments, Services, Secrets y ConfigMaps, residen exactamente en un solo espacio de nombres.
Lista los espacios de nombres que ya existen en el clúster:
kubectl get namespaces
Deberías ver espacios de nombres del sistema como kube-system y el espacio de nombres de aplicación estándar default:
NAME STATUS AGE
default Active ...
kube-system Active ...
...
Tu contexto también puede almacenar un espacio de nombres predeterminado. Cuando ejecutas un comando que requiere espacio de nombres sin especificar --namespace, kubectl utiliza ese valor predeterminado. La opción --minify muestra solo el contexto activo, y la expresión jsonpath imprime únicamente el campo del espacio de nombres.
kubectl config view --minify --output 'jsonpath={..namespace}'; echo
Debido a que estableciste el espacio de nombres del contexto en el paso anterior, esto imprimirá default:
default
Siempre puedes anular el espacio de nombres actual para un solo comando usando --namespace. Por ejemplo, inspecciona los Pods en el espacio de nombres del sistema de Kubernetes sin cambiar tu contexto:
kubectl get pods --namespace kube-system
Los nombres exactos de los Pods pueden variar, pero el comando debería devolver los Pods del sistema como CoreDNS, componentes de red o de almacenamiento:
NAME READY STATUS RESTARTS AGE
... ... ... ... ...
Seleccionar un espacio de nombres de práctica
En este paso, crearás un espacio de nombres para este laboratorio y lo convertirás en el espacio de nombres predeterminado para los comandos posteriores.
Crea un espacio de nombres llamado ckad-prep-contexts. Los nombres de los espacios de nombres son parte de la identidad del objeto: un ConfigMap llamado app-settings en un espacio de nombres es diferente de un ConfigMap con el mismo nombre en otro espacio de nombres.
kubectl create namespace ckad-prep-contexts
El comando de creación debería confirmar el nuevo espacio de nombres:
namespace/ckad-prep-contexts created
Ahora actualiza solo el contexto actual para que los comandos sin --namespace apunten a ckad-prep-contexts. La opción --current significa "modificar el contexto que estoy usando ahora" en lugar de tener que nombrar un contexto manualmente.
kubectl config set-context --current --namespace=ckad-prep-contexts
La salida confirma que el contexto fue modificado:
Context "labex-v135" modified.
Verifica nuevamente el espacio de nombres almacenado en el contexto activo:
kubectl config view --minify --output 'jsonpath={..namespace}'; echo
Ahora debería imprimir:
ckad-prep-contexts
Ejecuta una lista simple de Pods sin --namespace. Debido a que el espacio de nombres actual es ahora ckad-prep-contexts, este comando busca dentro de tu espacio de nombres de práctica. Es normal que el espacio de nombres esté vacío.
kubectl get pods
Salida esperada:
No resources found in ckad-prep-contexts namespace.
Observar el alcance de los espacios de nombres
En este paso, crearás un pequeño ConfigMap y lo usarás para observar cómo el espacio de nombres actual afecta la búsqueda de objetos.
Un ConfigMap almacena datos de configuración no confidenciales para aplicaciones. Es ligero, rápido de crear y tiene espacio de nombres, lo que lo hace útil para practicar el comportamiento de los espacios de nombres antes de comenzar a desplegar aplicaciones reales.
Crea un ConfigMap llamado app-settings sin pasar --namespace. Debido a que seleccionaste ckad-prep-contexts en el paso anterior, Kubernetes lo crea en ese espacio de nombres.
kubectl create configmap app-settings --from-literal=mode=prep
El comando debería informar:
configmap/app-settings created
Lista el ConfigMap sin una bandera de espacio de nombres. Esto utiliza el espacio de nombres del contexto actual.
kubectl get configmap app-settings
Salida esperada:
NAME DATA AGE
app-settings 1 ...
Ahora solicita el mismo objeto con un espacio de nombres explícito. Esto debería devolver el mismo ConfigMap porque ckad-prep-contexts es donde lo creaste.
kubectl get configmap app-settings --namespace ckad-prep-contexts
Finalmente, verifica el espacio de nombres default. La opción --ignore-not-found hace que kubectl finalice con éxito y no imprima nada cuando el objeto no existe, lo cual es útil para un laboratorio guiado, ya que la ausencia es el resultado esperado aquí.
kubectl get configmap app-settings --namespace default --ignore-not-found
La ausencia de salida significa que el ConfigMap no se creó en default. Ahora has visto el efecto práctico de establecer el espacio de nombres en tu contexto actual.
Resumen
Confirmaste que kubectl puede comunicarse con el clúster de Kubernetes preparado, identificaste el contexto activo, inspeccionaste los espacios de nombres existentes, cambiaste el espacio de nombres del contexto actual y creaste un ConfigMap para observar el alcance de los espacios de nombres. Estos conceptos básicos son la base para los laboratorios de preparación de CKAD posteriores, donde crearás objetos de aplicación y necesitarás saber exactamente dónde se está creando e inspeccionando cada objeto.
