Introducción
Un clúster de Kubernetes se parece a un edificio de apartamentos grande.
Si todos vivieran en el vestíbulo, habría un caos. No sabría de quién son los muebles y un vecino ruidoso podría molestar a todo el mundo.
Los Namespaces dividen lógicamente un clúster para que distintos equipos, entornos o aplicaciones puedan organizar sus recursos por separado.
Las ResourceQuotas restringen la cantidad de determinados recursos que puede consumir un namespace. Esto ayuda a evitar que un equipo o una carga de trabajo agote la capacidad compartida del clúster.
En este laboratorio, usted hará lo siguiente:
- Construirá un nuevo «apartamento» (Namespace) llamado
dev. - Establecerá un «límite de electricidad» estricto (ResourceQuota) para ese apartamento.
- Intentará introducir muebles (Pods) en el apartamento y comprobará si caben.
Crear un Namespace
En este paso, creará un nuevo namespace para aislar los recursos de un equipo de desarrollo.
Un namespace es un límite lógico dentro de un mismo clúster, no un clúster independiente. Los equipos siguen compartiendo el mismo plano de control y los nodos subyacentes, pero los nombres, las políticas y muchas vistas de recursos pueden separarse para mantener el trabajo organizado.
De forma predeterminada, todo se coloca en el namespace default (el vestíbulo). Consulte qué namespaces existen actualmente:
kubectl get namespaces
Debería ver default, kube-system (donde trabajan los administradores del edificio) y algunos más.
Ahora, cree el apartamento dev:
kubectl create namespace dev
Compruebe que existe:
kubectl get namespaces
Verá dev en la lista. Actualmente es un apartamento vacío, sin paredes ni límites; puede colocar cualquier cosa dentro.
Aplicar límites de recursos
Ahora debemos establecer las reglas. No queremos que el equipo dev consuma toda la CPU y la memoria del clúster.
Crearemos un objeto ResourceQuota. Esto permite indicar: «En el namespace dev, puede utilizar como máximo 2 CPU y 2Gi de memoria».
Las cuotas son especialmente importantes en los clústeres compartidos porque la CPU y la memoria son recursos finitos. Sin cuotas, una carga de trabajo descontrolada podría consumir más de su parte justa y hacer que el clúster dejara de ser fiable para los demás. Por eso, las cuotas no solo sirven para contabilizar recursos; también son una herramienta de estabilidad.
Cree un archivo llamado quota.yaml:
nano quota.yaml
Pegue la siguiente configuración:
apiVersion: v1
kind: ResourceQuota
metadata:
name: dev-quota
namespace: dev
spec:
hard:
requests.cpu: "1"
requests.memory: 1Gi
limits.cpu: "2"
limits.memory: 2Gi
Guarde el archivo y salga (Ctrl+X, Y, Enter).
Aplique esta regla al clúster:
kubectl apply -f quota.yaml
Puede consultar los detalles de la regla. Verá el límite «Hard» (el que estableció) y la cantidad «Used» (actualmente 0).
kubectl describe resourcequota dev-quota --namespace=dev
Implementar un Pod
Ahora que las reglas están configuradas, intentemos introducirnos.
Regla fundamental: cuando un apartamento tiene un límite, cada mueble que introduzca debe tener declarado su tamaño. En términos de Kubernetes: si un Namespace tiene una Quota, cada Pod debe especificar explícitamente sus resources (requests y limits). Si no lo hace, el administrador del edificio (Kubernetes) le bloqueará la entrada.
Aquí se relacionan dos conceptos. Un request indica al planificador qué cantidad de recursos debe garantizarse al colocar el Pod. Un limit es la cantidad máxima que el contenedor puede utilizar. Las cuotas suman esos requests y limits en todo el namespace para mantener el total dentro de la política.
Cree un archivo llamado pod.yaml:
nano pod.yaml
Pegue lo siguiente. Observe que declaramos explícitamente el tamaño de este pod:
apiVersion: v1
kind: Pod
metadata:
name: dev-pod
namespace: dev ## <-- Putting it in the 'dev' apartment
spec:
containers:
- name: nginx
image: nginx
resources:
requests:
memory: "128Mi"
cpu: "250m"
limits:
memory: "256Mi"
cpu: "500m"
Guarde el archivo y salga (Ctrl+X, Y, Enter).
Implemente el Pod:
kubectl apply -f pod.yaml
Compruebe si se está ejecutando dentro del namespace dev:
kubectl get pods --namespace=dev
Espere hasta que vea Running.
Ahora, vuelva a comprobar el uso de la Quota. Verá que la columna «Used» ha aumentado:
kubectl describe resourcequota dev-quota --namespace=dev
Ha conseguido controlar el uso de recursos con respecto a su presupuesto.
Verificar el aislamiento
Por último, compruebe que las paredes de nuestro «apartamento» son reales.
El aislamiento de los namespaces se basa principalmente en los nombres, las políticas y el ámbito de las operaciones. De forma predeterminada, no significa que las cargas de trabajo se ejecuten en hardware físicamente separado. Esta distinción será importante más adelante, cuando aprenda sobre la selección de nodos y los mecanismos de aislamiento más sólidos.
Colocamos dev-pod dentro de dev. No debería estar visible desde el vestíbulo (default).
Enumere los Pods del namespace predeterminado:
kubectl get pods
Debería ver «No resources found in default namespace» o, al menos, no debería aparecer dev-pod.
Ahora, compruebe si hay una Quota en el namespace predeterminado:
kubectl get resourcequota
No debería aparecer nada. El límite de electricidad que establecimos se aplica solo al apartamento dev, no a todo el edificio.
Esto confirma que los Namespaces proporcionan un aislamiento real para sus equipos.
Resumen
En este laboratorio, se convirtió en el administrador del edificio de su clúster de Kubernetes.
Ha conseguido:
- Construir un Namespace privado (
dev) para un equipo. - Establecer una ResourceQuota estricta (límite de electricidad) para evitar el consumo excesivo.
- Implementar una aplicación que respetara estos límites.
- Verificar que las paredes entre los namespaces mantenían los recursos aislados.
Así es como las grandes organizaciones comparten un único clúster de Kubernetes entre cientos de equipos sin que interfieran entre sí.
