Introducción
Las aplicaciones modernas suelen distribuirse en contenedores. Un contenedor agrupa una aplicación con las bibliotecas y configuraciones que necesita, lo que facilita ejecutarla de forma uniforme. Ejecutar un solo contenedor es sencillo. Ejecutar muchos contenedores de manera fiable es más difícil: un operador debe decidir dónde se ejecutan, reiniciar los contenedores que fallen, conectar las aplicaciones entre sí y aplicar cambios de forma segura.
Kubernetes es un sistema de orquestación de contenedores que se encarga de estas responsabilidades a nivel de clúster. Tú describes el estado que deseas —por ejemplo, «ejecutar tres copias de esta aplicación web»— y Kubernetes trabaja continuamente para que el estado real coincida con ese estado deseado.
Un clúster de Kubernetes está compuesto por una o más máquinas llamadas nodos. El plano de control administra el clúster, mientras que los nodos proporcionan la CPU, la memoria, la red y el entorno de ejecución de contenedores que utilizan las aplicaciones. Las aplicaciones se ejecutan mediante objetos de Kubernetes como Pods, Deployments y Services.
En este primer laboratorio todavía no desplegarás ninguna aplicación. Primero aprenderás a orientarte dentro de un clúster real:
- Identificar las herramientas, el clúster activo, la versión de Kubernetes y el estado de los nodos.
- Encontrar los componentes del plano de control y de los nodos que hacen funcionar Kubernetes.
- Inspeccionar los endpoints del clúster y la información detallada de los nodos.
- Explorar Pods, Deployments y Services en distintos namespaces.
El entorno ya está preparado para que puedas centrarte en los conceptos de Kubernetes en lugar de en la instalación. Utiliza Minikube v1.38.1 con un perfil llamado labex-v135, que ejecuta Kubernetes v1.35.5. Minikube ejecuta un clúster completo de Kubernetes dentro de un contenedor Docker en la máquina virtual de LabEx. Es un entorno de aprendizaje de un solo nodo, pero los comandos y conceptos de Kubernetes que practicarás también se aplican a clústeres más grandes.
Trabajarás íntegramente en la terminal. Lee las explicaciones antes de ejecutar cada comando y compara la salida real con las evidencias descritas. Las edades exactas, los recuentos de reinicios y los nombres generados pueden variar; es normal en un sistema activo.
Verifica el clúster preconfigurado
Inicio del entorno: Este laboratorio inicia un clúster de Kubernetes completo. La configuración del plano de control, el nodo y los componentes de red suele tardar 2–3 minutos. Espera pacientemente a que el entorno termine de cargarse antes de comenzar.
En este paso aprenderás cómo se conectan las herramientas de la terminal con Kubernetes, identificarás las versiones del software proporcionado y confirmarás que el clúster está listo. Antes de modificar un clúster, un administrador debe saber siempre qué clúster está activo y si funciona correctamente.
Comprende las herramientas
Utilizarás dos herramientas de línea de comandos relacionadas:
minikubecrea y administra clústeres locales de Kubernetes. Un entorno de Minikube con nombre se denomina perfil. Este laboratorio utiliza el perfillabex-v135.kubectles el cliente estándar de línea de comandos de Kubernetes. Envía solicitudes al servidor de la API de Kubernetes para listar, crear, actualizar y eliminar objetos.
El clúster ya está en ejecución. No ejecutes minikube start: no es necesario y podría hacerte esperar mientras Minikube vuelve a comprobar el entorno existente.
Entra en el directorio de trabajo
Desplázate al directorio del proyecto, donde los laboratorios posteriores almacenarán manifiestos y otros archivos creados por los alumnos:
cd /home/labex/project
El comando cd cambia el directorio actual del shell. Normalmente no muestra ninguna salida cuando se ejecuta correctamente.
Comprueba la versión de Minikube
Muestra la versión instalada de Minikube. Una opción que comienza por -- modifica el comportamiento del comando. En este caso, --short solicita únicamente el número de versión.
minikube version --short
v1.38.1
Esta es la versión de la herramienta de administración del clúster, no la versión de Kubernetes. Minikube y Kubernetes son proyectos independientes y tienen números de versión distintos.
Comprueba las versiones del cliente y del servidor
Solicita a kubectl la información de versión. Esta operación contacta con el clúster, por lo que comprueba el cliente local y el servidor de API remoto:
kubectl version
Client Version: v1.35.5
Kustomize Version: ...
Server Version: v1.35.5
Client Version corresponde al kubectl instalado; Server Version es la versión informada por el servidor de la API de Kubernetes. Ver la línea del servidor demuestra que kubectl ha llegado correctamente a un clúster. Kustomize es una función integrada para personalizar manifiestos que no se necesita en este laboratorio.
Confirma el contexto activo
Un equipo puede almacenar los datos de acceso de varios clústeres en un archivo kubeconfig. Un contexto de kubeconfig selecciona un clúster, las credenciales de un usuario y el namespace predeterminado. Comprobarlo evita trabajar accidentalmente en el clúster equivocado.
kubectl config current-context
labex-v135
Esto coincide con el perfil preparado de Kubernetes v1.35.
Lista y selecciona contextos
Los archivos kubeconfig reales suelen contener más de un contexto. Enuméralos antes de cambiar para no tener que adivinar ningún nombre:
kubectl config get-contexts
La columna NAME contiene los nombres de los contextos y la columna CURRENT marca el activo con *. El clúster, la información de autenticación y el namespace predeterminado asociados a cada contexto aparecen en las demás columnas.
Utiliza use-context cuando necesites seleccionar uno de esos nombres. Volver a seleccionar labex-v135 es seguro aunque ya sea el contexto actual, y te permite practicar el flujo exacto para cambiar de contexto:
kubectl config use-context labex-v135
Switched to context "labex-v135".
current-context responde «¿cuál está seleccionado?», get-contexts responde «¿qué opciones existen?» y use-context NAME cambia la selección. Estos comandos solo modifican la elección del cliente local; no inician, detienen ni modifican ningún clúster.
Comprueba el perfil de Minikube
Solicita a Minikube el estado de este perfil. La opción corta -p significa profile y va seguida de su nombre.
minikube status -p labex-v135
labex-v135
type: Control Plane
host: Running
kubelet: Running
apiserver: Running
kubeconfig: Configured
host indica que el contenedor del nodo de Minikube está en ejecución. kubelet es el agente del nodo. apiserver es el endpoint de la API de Kubernetes. kubeconfig: Configured significa que la configuración del cliente local apunta a este clúster. Todos deberían estar en buen estado.
Lista los nodos
La mayoría de los comandos de kubectl siguen el formato kubectl <verb> <resource>. Aquí, get lee objetos y nodes es el tipo de recurso:
kubectl get nodes
NAME STATUS ROLES AGE VERSION
labex-v135 Ready control-plane ... v1.35.5
NAME identifica el nodo. STATUS=Ready significa que puede ejecutar cargas de trabajo. ROLES muestra que aloja el plano de control. AGE puede ser mayor que la duración de esta sesión porque la imagen restaura una instantánea preparada. VERSION es la versión de kubelet.
Este laboratorio tiene un único nodo que desempeña funciones del plano de control y de ejecución de cargas de trabajo. En los clústeres de producción, estas funciones suelen distribuirse entre varias máquinas.
Punto de control del paso
Has comprobado que kubectl llega al clúster previsto labex-v135 y que su nodo está en estado Ready con Kubernetes v1.35.5. Esta es una rutina de orientación útil cada vez que accedes a un clúster desconocido.
Identifica los componentes de la arquitectura de Kubernetes
En este paso relacionarás el modelo de arquitectura de Kubernetes con sus componentes reales. Nombres como servidor de API, planificador y kubelet son más fáciles de recordar cuando ves sus Pods en ejecución.
Sigue una solicitud a través de Kubernetes
Imagina que pides a Kubernetes que ejecute una aplicación web. Primero, kubectl envía la solicitud a kube-apiserver, que la valida y almacena el estado deseado en etcd.
A continuación, kube-scheduler elige un nodo para cada Pod nuevo. kube-controller-manager observa el clúster y trabaja para que el estado real coincida con el estado deseado.
Por último, el kubelet del nodo seleccionado pide al entorno de ejecución de contenedores que inicie los contenedores del Pod. Los componentes de red permiten que los Pods y Services se comuniquen.
Esta comparación continua entre el estado deseado y el real se denomina reconciliación. Si un Deployment solicita tres Pods, pero solo existen dos, un controlador crea el Pod que falta.
Comprende los Pods y los namespaces del sistema
Un Pod es la unidad desplegable más pequeña de Kubernetes. Agrupa uno o más contenedores estrechamente relacionados y les proporciona un contexto compartido de red y almacenamiento.
Un namespace proporciona un ámbito lógico para los objetos que admiten namespaces. kube-system contiene la infraestructura del clúster. La opción -n kube-system indica a kubectl que busque allí en lugar de hacerlo en el namespace predeterminado. Su equivalente largo es --namespace=kube-system; ambas formas seleccionan el mismo ámbito.
Minikube ejecuta los componentes del plano de control como Pods estáticos. El kubelet los crea directamente a partir de archivos del nodo, lo que permite que el plano de control se inicie antes de que el proceso normal de planificación esté disponible.
Lista el plano de control
Los objetos pueden tener labels, metadatos en forma de pares clave-valor que se utilizan para agrupar y seleccionar objetos. Usa -l tier=control-plane para seleccionar los Pods que tienen esa etiqueta:
kubectl get pods -n kube-system -l tier=control-plane
NAME READY STATUS RESTARTS AGE
etcd-labex-v135 1/1 Running ... ...
kube-apiserver-labex-v135 1/1 Running ... ...
kube-controller-manager-labex-v135 1/1 Running ... ...
kube-scheduler-labex-v135 1/1 Running ... ...
El servidor de API es la puerta de entrada a Kubernetes. etcd almacena el estado del clúster. El planificador decide dónde colocar los Pods. El administrador de controladores ejecuta los controladores de reconciliación.
READY=1/1 significa que el contenedor único del Pod está listo. Los componentes de larga duración deberían estar en estado Running. RESTARTS puede ser distinto de cero después de reanudar el clúster guardado. AGE indica la antigüedad del objeto, no el tiempo transcurrido en este laboratorio.
Inspecciona las etiquetas
Muestra las etiquetas en una columna final:
kubectl get pods -n kube-system -l tier=control-plane --show-labels
Busca component=kube-apiserver y tier=control-plane. La primera distingue un componente; la segunda agrupa todos los Pods del plano de control. Las etiquetas identifican objetos y los selectores encuentran los objetos coincidentes.
Inspecciona los componentes de red de los nodos
Utiliza un selector basado en conjuntos que indique que k8s-app puede ser kube-proxy o calico-node. Las comillas impiden que el shell interprete los paréntesis.
kubectl get pods -n kube-system -l 'k8s-app in (kube-proxy,calico-node)'
NAME READY STATUS RESTARTS AGE
calico-node-... 1/1 Running ... ...
kube-proxy-... 1/1 Running ... ...
Calico configura la red de los Pods. kube-proxy mantiene las reglas del nodo que ayudan a los Services a dirigir el tráfico hacia los Pods. El kubelet no aparece en esta lista porque es el agente del host responsable de operar los Pods; por eso se ejecuta como un servicio del host y no como un Pod ordinario gestionado por sí mismo.
Punto de control del paso
El servidor de API acepta solicitudes, etcd almacena el estado, el planificador elige dónde colocar los Pods, los controladores reconcilian el estado, el kubelet opera el nodo y Calico junto con kube-proxy proporcionan soporte de red.
Inspecciona los detalles del clúster y de los nodos
En este paso pasarás de una comprobación básica del estado a una inspección detallada. Kubernetes ofrece vistas resumidas en forma de listas y descripciones detalladas; aprender cuándo utilizar cada una es un hábito esencial para solucionar problemas.
Localiza los endpoints del clúster
kubectl cluster-info es un comando diseñado específicamente para orientarse. A diferencia de kubectl get, no enumera un tipo concreto de recurso; solicita al clúster activo las direcciones de servicios importantes como el servidor de API y CoreDNS.
kubectl cluster-info
Kubernetes control plane is running at https://...
CoreDNS is running at https://...
La URL del plano de control es el endpoint del servidor de API. CoreDNS proporciona descubrimiento de servicios mediante DNS, lo que permite que las cargas de trabajo encuentren Services por nombre en lugar de depender de IP que pueden cambiar. Las direcciones varían, así que céntrate en is running, que indica que el servidor de API devolvió información. Esto no demuestra que todas las cargas de trabajo estén sanas.
Amplía la lista de nodos
Añade -o wide para solicitar más columnas:
kubectl get nodes -o wide
NAME STATUS ROLES AGE VERSION INTERNAL-IP ... OS-IMAGE
labex-v135 Ready control-plane ... v1.35.5 192.168.49.2 ... Debian GNU/Linux 12 (bookworm)
INTERNAL-IP es la dirección del nodo en la red del clúster. EXTERNAL-IP=<none> significa que no tiene una dirección pública gestionada por Kubernetes. OS-IMAGE, KERNEL-VERSION y CONTAINER-RUNTIME describen el software del nodo.
La infraestructura de LabEx utiliza Ubuntu 22.04, mientras que Minikube representa el nodo de Kubernetes mediante un contenedor Docker basado en Debian. Por tanto, ver Debian aquí es lo esperado.
Describe el nodo
Utiliza describe cuando una fila de la lista no contenga suficiente información. Su formato es kubectl describe <resource-type> <name>; aquí, el tipo de recurso es node y el nombre del objeto es labex-v135:
kubectl describe node labex-v135
Cerca de la parte superior, inspecciona la identidad y la planificación:
Name: labex-v135
Roles: control-plane
Taints: <none>
Unschedulable: false
Los Taints pueden impedir que se asignen Pods que no los toleren. <none> significa que este nodo de aprendizaje no tiene ninguno. Unschedulable: false significa que Kubernetes puede colocar cargas de trabajo en él.
Busca la tabla Conditions:
Type Status ... Reason
NetworkUnavailable False ... CalicoIsUp
MemoryPressure False ... KubeletHasSufficientMemory
DiskPressure False ... KubeletHasNoDiskPressure
PIDPressure False ... KubeletHasSufficientPID
Ready True ... KubeletReady
Para las condiciones de presión y de indisponibilidad, False es un estado saludable porque el problema está ausente. Para Ready, True es saludable. Lee siempre el nombre de la condición junto con su valor.
Capacity representa los recursos totales que informa el nodo. Allocatable indica los recursos que Kubernetes puede ofrecer a los Pods después de aplicar las reservas del sistema. System Info muestra información del entorno de ejecución y del kubelet. Las secciones posteriores enumeran los Pods, las solicitudes y límites asignados, y los eventos. Los valores exactos y las marcas de tiempo pueden variar.
Punto de control del paso
Utiliza get para obtener una tabla rápida, get -o wide para consultar columnas adicionales y describe para revisar las condiciones, la capacidad, los detalles del entorno de ejecución y los eventos de un objeto concreto.
Inspecciona recursos en distintos namespaces
En este paso crearás un mapa inicial de los objetos más habituales: los Namespaces organizan los recursos, los Pods ejecutan contenedores, los Deployments administran Pods y los Services proporcionan acceso de red estable.
Comprende las relaciones entre objetos
- Un Pod es la unidad desplegable más pequeña y contiene uno o más contenedores.
- Un Deployment declara cuántas copias de una aplicación sin estado deben ejecutarse y administra los Pods mediante un ReplicaSet.
- Un Service proporciona a los Pods seleccionados una IP virtual y un nombre DNS estables, ya que las IP de los Pods reemplazables pueden cambiar.
- Un Namespace agrupa objetos que admiten namespaces y permite utilizar el mismo nombre en distintos ámbitos.
Una relación simplificada es la siguiente: un Deployment administra Pods, mientras que un Service selecciona esos Pods y ofrece a los clientes un endpoint estable. No todos los objetos pertenecen a un namespace; los Nodes forman parte del clúster completo.
Lista los Pods de todos los namespaces
Sin una opción de namespace, kubectl get pods busca únicamente en el namespace actual. -A significa --all-namespaces:
kubectl get pods -A
NAMESPACE es el ámbito lógico. NAME identifica el Pod dentro de ese ámbito. READY muestra los contenedores listos divididos entre el número total de contenedores. STATUS indica la fase del ciclo de vida. RESTARTS cuenta los reinicios y AGE indica la antigüedad del objeto.
La infraestructura de larga duración debería estar en estado Running. Algunos Pods de admisión de Ingress aparecen como Completed con una disponibilidad 0/1 porque ejecutaron Jobs puntuales y finalizaron correctamente. El estado de salud debe interpretarse según el propósito de cada carga de trabajo.
Lista los Deployments
El nombre de recurso en plural deployments solicita los objetos Deployment. Mantén -A porque los Deployments del sistema se encuentran fuera del namespace actual default:
kubectl get deployments -A
NAMESPACE NAME READY UP-TO-DATE AVAILABLE AGE
ingress-nginx ingress-nginx-controller 1/1 1 1 ...
kube-system calico-kube-controllers 1/1 1 1 ...
kube-system coredns 1/1 1 1 ...
kube-system metrics-server 1/1 1 1 ...
READY muestra las réplicas listas divididas entre las réplicas deseadas. UP-TO-DATE cuenta las réplicas que utilizan la plantilla actual del Pod. AVAILABLE cuenta las réplicas disponibles para su propósito. El Pod coredns-... visto anteriormente es administrado por el Deployment coredns.
Lista los Services
Los Pods pueden reemplazarse, por lo que los clientes no deberían depender de la IP de un Pod. Enumera los endpoints estables de los Services:
kubectl get services -A
NAMESPACE NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
default kubernetes ClusterIP 10.96.0.1 <none> 443/TCP ...
kube-system kube-dns ClusterIP 10.96.0.10 <none> ... ...
ingress-nginx ingress-nginx-controller NodePort ... <none> ... ...
TYPE describe cómo se expone el Service. ClusterIP permite acceder a él desde dentro del clúster; NodePort también abre un puerto en el nodo. CLUSTER-IP es la dirección virtual estable. EXTERNAL-IP=<none> significa que no se ha asignado ninguna dirección externa. PORT(S) enumera los protocolos y puertos expuestos.
El Service kubernetes expone la API dentro del clúster. kube-dns proporciona acceso estable a CoreDNS. Los Services de Ingress permiten gestionar el tráfico HTTP y HTTPS entrante.
Crea una vista combinada
Cuando todavía no sabes qué tipos de cargas de trabajo comunes existen, kubectl get all proporciona una vista general combinada. Añadir -A mantiene el ámbito de todos los namespaces utilizado anteriormente:
kubectl get all -A
Este comando agrupa recursos habituales como Pods, Services, DaemonSets, Deployments, ReplicaSets y Jobs. Es posible que veas un mismo componente en varios niveles: Deployment, ReplicaSet y Pod.
A pesar de su nombre, get all no devuelve todos los recursos. ConfigMaps, Secrets, NetworkPolicies y muchos otros quedan excluidos. Utilízalo para orientarte y después solicita el tipo de recurso exacto.
Punto de control del paso
Los Namespaces proporcionan un ámbito, los Pods ejecutan contenedores, los Deployments mantienen el número deseado de réplicas de Pods y los Services ofrecen acceso de red estable a Pods cuyos cambios son esperables.
Resumen
Has completado tu primera exploración guiada de un clúster de Kubernetes. Has aprendido que Kubernetes administra el estado deseado entre los nodos y que kubectl se comunica con el servidor de API mediante el contexto activo de kubeconfig.
Has practicado cómo distinguir las versiones de Minikube, Kubernetes y kubectl; confirmar el contexto y la disponibilidad del nodo; identificar los componentes del plano de control, de los nodos y de la red; utilizar etiquetas y selectores; elegir entre get, get -o wide y describe; interpretar las condiciones y la capacidad de los nodos; y relacionar Namespaces, Pods, Deployments y Services.
El hábito fundamental para principiantes es inspeccionar antes de cambiar cualquier cosa: confirma el contexto, comprueba el estado de los nodos, identifica el namespace y el tipo de recurso relevantes, y lee atentamente el estado informado. Los laboratorios posteriores se basan en este modelo para que puedas crear tus propias cargas de trabajo.
