Introduction
Un cluster Kubernetes ressemble à un grand immeuble.
Si tout le monde vivait dans le hall, ce serait le chaos. Vous ne sauriez pas à qui appartiennent les meubles, et un voisin bruyant pourrait déranger tout le monde.
Les Namespaces partitionnent logiquement un cluster afin que différentes équipes, différents environnements ou différentes applications puissent organiser leurs ressources séparément.
Les ResourceQuotas limitent la quantité de certaines ressources qu’un espace de noms peut consommer. Cela évite qu’une équipe ou qu’une charge de travail épuise la capacité partagée du cluster.
Dans ce laboratoire, vous allez :
- Construire un nouvel « appartement » (Namespace) appelé
dev. - Définir une « limite d’électricité » stricte (ResourceQuota) pour cet appartement.
- Essayer d’y déplacer des meubles (Pods) et vérifier s’ils peuvent y entrer.
Créer un Namespace
Dans cette étape, vous allez créer un nouvel espace de noms afin d’isoler les ressources d’une équipe de développement.
Un espace de noms est une limite logique à l’intérieur d’un même cluster, et non un cluster séparé. Les équipes partagent toujours le même control plane et les mêmes nœuds sous-jacents, mais les noms, les règles et de nombreuses vues des ressources peuvent être séparés pour garder le travail organisé.
Par défaut, tout est placé dans l’espace de noms default (le hall). Voyons quels espaces de noms existent actuellement :
kubectl get namespaces
Vous devriez voir default, kube-system (là où résident les responsables de l’immeuble) et quelques autres espaces de noms.
Construisons maintenant l’appartement dev :
kubectl create namespace dev
Vérifiez qu’il existe :
kubectl get namespaces
Vous verrez dev dans la liste. Pour le moment, c’est un appartement vide, sans murs ni limites : vous pouvez y placer n’importe quoi.
Appliquer des limites de ressources
Nous devons maintenant définir les règles. Nous ne voulons pas que l’équipe dev utilise tout le processeur et toute la mémoire du cluster.
Nous allons créer un objet ResourceQuota. Il permet de définir la règle suivante : « Dans l’espace de noms dev, vous pouvez utiliser au maximum 2 processeurs et 2Gi de mémoire. »
Les quotas sont particulièrement importants dans les clusters partagés, car le processeur et la mémoire sont des ressources limitées. Sans quotas, une charge de travail trop gourmande peut consommer plus que sa part équitable et rendre le cluster peu fiable pour les autres utilisateurs. Les quotas ne servent donc pas uniquement à comptabiliser l’utilisation : ils contribuent aussi à la stabilité du cluster.
Créez un fichier nommé quota.yaml :
nano quota.yaml
Collez la configuration suivante :
apiVersion: v1
kind: ResourceQuota
metadata:
name: dev-quota
namespace: dev
spec:
hard:
requests.cpu: "1"
requests.memory: 1Gi
limits.cpu: "2"
limits.memory: 2Gi
Enregistrez le fichier et quittez (Ctrl+X, Y, Enter).
Appliquez cette règle au cluster :
kubectl apply -f quota.yaml
Vous pouvez afficher les détails de la règle. Ils indiquent la limite « Hard » (la valeur que vous avez définie) ainsi que la quantité « Used » (actuellement égale à 0).
kubectl describe resourcequota dev-quota --namespace=dev
Déployer un Pod
Maintenant que les règles sont définies, essayons d’emménager.
Règle essentielle : lorsqu’un appartement a une limite, chaque meuble que vous y apportez doit avoir sa taille déclarée. Dans Kubernetes, cela signifie que si un Namespace possède un quota, chaque Pod doit définir explicitement des resources (requests et limits). Sinon, le responsable de l’immeuble (Kubernetes) vous bloquera à l’entrée.
C’est ici que deux notions liées se rencontrent. Un request indique au scheduler la quantité de ressources que le Pod doit obtenir lorsqu’il est placé. Une limit représente la quantité maximale que le conteneur est autorisé à utiliser. Les quotas additionnent ces requests et ces limits dans un espace de noms afin de maintenir le total dans les limites de la règle.
Créez un fichier nommé pod.yaml :
nano pod.yaml
Collez le contenu suivant. Remarquez que la taille de ce Pod est déclarée explicitement :
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"
Enregistrez le fichier et quittez (Ctrl+X, Y, Enter).
Déployez le Pod :
kubectl apply -f pod.yaml
Vérifiez qu’il s’exécute dans l’espace de noms dev :
kubectl get pods --namespace=dev
Attendez que son état soit Running.
Vérifiez maintenant à nouveau l’utilisation du quota. Vous constaterez que la colonne « Used » a augmenté !
kubectl describe resourcequota dev-quota --namespace=dev
Vous suivez maintenant correctement l’utilisation de vos ressources par rapport au budget défini.
Vérifier l’isolation
Pour finir, vérifions que les murs de notre « appartement » sont bien réels.
L’isolation entre espaces de noms concerne principalement les noms, les règles et la portée des opérations. Elle ne signifie pas que les charges de travail s’exécutent par défaut sur du matériel physiquement séparé. Cette distinction sera importante lorsque vous apprendrez la sélection des nœuds et les mécanismes d’isolation renforcée.
Nous avons placé dev-pod dans dev. Il ne doit pas être visible depuis le hall (default).
Listez les Pods de l’espace de noms par défaut :
kubectl get pods
Vous devriez voir « No resources found in default namespace » ou, au minimum, ne pas voir dev-pod.
Vérifiez maintenant la présence d’un quota dans l’espace de noms par défaut :
kubectl get resourcequota
Vous ne devriez rien voir. La limite d’électricité que nous avons définie s’applique uniquement à l’appartement dev, et non à tout l’immeuble.
Cela confirme que les Namespaces fournissent une véritable isolation pour vos équipes.
Résumé
Dans ce laboratoire, vous êtes devenu responsable de l’immeuble de votre cluster Kubernetes.
Vous avez réussi à :
- Construire un Namespace privé (
dev) pour une équipe. - Définir une ResourceQuota stricte (limite d’électricité) afin d’éviter une consommation excessive.
- Déployer une application qui respecte ces limites.
- Vérifier que les murs entre les espaces de noms maintiennent leur isolation.
C’est ainsi que les grandes organisations partagent un seul cluster Kubernetes entre des centaines d’équipes sans qu’elles se gênent mutuellement.
