Utiliser la planification de capacité - Container Compute Service

Container Compute Service (ACS) prend en charge le mécanisme ResourceQuota de Kubernetes open source. Un ResourceQuota impose des limites strictes sur le volume total de ressources qu'un namespace peut consommer : CPU, mémoire, ressources étendues, etc. Lorsqu'un namespace dispose d'un ResourceQuota, Kubernetes suit l'utilisation et rejette toute requête entraînant un dépassement de cette limite.

Fonctionnement

Les ResourceQuotas fonctionnent selon les principes suivants :

Chaque équipe ou application s'exécute dans un namespace distinct.
Un administrateur de cluster crée un ou plusieurs ResourceQuotas pour chaque namespace.
Lors de la création de ressources (pods, Services, etc.), le système de quotas suit leur utilisation et garantit le respect des limites strictes définies par le ResourceQuota.
Si la création ou la mise à jour d'une ressource dépasse un quota, Kubernetes rejette la requête avec le code d'état HTTP 403 Forbidden. Le message d'erreur indique le nom du quota, la quantité demandée, l'utilisation actuelle et la limite stricte.

Prérequis

Si un ResourceQuota définit des limites de CPU ou de mémoire pour un namespace, chaque pod créé dans ce namespace doit spécifier des requêtes et des limites de ressources. Les pods ne disposant pas de ces paramètres sont rejetés. Pour éviter cela, utilisez un contrôleur d'admission LimitRanger afin de définir automatiquement des limites de ressources par défaut.
La modification d'un ResourceQuota s'applique uniquement aux nouvelles demandes de création de ressources. Les ressources existantes ne sont pas affectées.
Le nom d'un ResourceQuota doit être un sous-domaine DNS valide.

Activer la fonctionnalité ResourceQuota

Par défaut, la fonctionnalité ResourceQuota est activée pour les clusters Container Service for Kubernetes (ACK) créés dans la console ACS. Créez simplement un ResourceQuota dans le namespace pour activer cette fonctionnalité.

Types de ressources pris en charge

ACS est entièrement compatible avec le mécanisme ResourceQuota de Kubernetes. Les ressources standard et étendues sont toutes deux prises en charge.

Ressources standard

Ressource	Contrainte
`limits.cpu`	Pour l'ensemble des pods non terminés, la somme des limites de CPU ne peut pas dépasser cette valeur.
`limits.memory`	Pour l'ensemble des pods non terminés, la somme des limites de mémoire ne peut pas dépasser cette valeur.
`requests.cpu`	Pour l'ensemble des pods non terminés, la somme des requêtes de CPU ne peut pas dépasser cette valeur.
`requests.memory`	Pour l'ensemble des pods non terminés, la somme des requêtes de mémoire ne peut pas dépasser cette valeur.
`hugepages-<size>`	Pour l'ensemble des pods non terminés, la somme des requêtes HugePage de la taille spécifiée ne peut pas dépasser cette valeur.
`cpu`	Équivalent à `requests.cpu`.
`memory`	Équivalent à `requests.memory`.

Ressources étendues

Kubernetes ne prend pas en charge le surengagement des ressources étendues (limite > requête). Pour ces ressources, configurez uniquement des quotas commençant par requests.. Pour plus de détails, consultez la rubrique Resource quotas.

Conditions préalables

Avant de commencer, assurez-vous de disposer des éléments suivants :

Un cluster ACS
kubectl configuré pour se connecter à votre cluster
Des permissions d'administrateur de cluster pour créer des ResourceQuotas

Créer et vérifier un ResourceQuota

Cet exemple détaille la création d'un ResourceQuota plafonnant l'utilisation du CPU dans un namespace, puis illustre le comportement lorsque les pods atteignent cette limite.

Étape 1 : Créer un namespace

kubectl create namespace test

Étape 2 : Créer un ResourceQuota

Créez un ResourceQuota nommé test-quota dans le namespace test avec une limite stricte de CPU de 4000 millicœurs (4 cœurs) pour les requêtes et les limites :

cat << EOF | kubectl apply -f -
apiVersion: v1
kind: ResourceQuota
metadata:
  name: test-quota
  namespace: test
spec:
  hard:
    requests.cpu: "4000m"
    limits.cpu: "4000m"
EOF

Ce quota applique les contraintes suivantes au namespace test :

La somme des requêtes de CPU pour tous les pods ne doit pas dépasser 4000m.
La somme des limites de CPU pour tous les pods ne doit pas dépasser 4000m.

Étape 3 : Vérifier le ResourceQuota

kubectl -n test describe resourcequota test-quota

Sortie attendue :

Namespace:    test
Resource      Used  Hard
--------      ----  ----
limits.cpu    0     4
requests.cpu  0     4

La colonne Used affiche 0, ce qui confirme qu'aucun pod n'a encore consommé de quota.

Étape 4 : Déployer des pods consommant le quota

Créez un Deployment avec 5 réplicas, chacun demandant 1 cœur CPU (1000m). Comme le quota est de 4000m, seuls 4 pods peuvent être planifiés :

cat << EOF | kubectl apply -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: test-app
  name: test-app
  namespace: test
spec:
  replicas: 5
  selector:
    matchLabels:
      app: test-app
  template:
    metadata:
      labels:
        app: test-app
    spec:
      containers:
      - image: registry.cn-hangzhou.aliyuncs.com/acs/busybox:v1.29.2
        imagePullPolicy: IfNotPresent
        name: test
        command:
        - sleep
        - "360000000"
        resources:
          limits:
            cpu: "1"
EOF

Étape 5 : Vérifier l'état des pods

kubectl -n test get pod

Sortie attendue :

NAME                        READY   STATUS    RESTARTS   AGE
test-app-5ddxxxxx94-jdv4m   1/1     Running   0          35s
test-app-5ddxxxxx94-jhmtb   1/1     Running   0          35s
test-app-5ddxxxxx94-mr8vq   1/1     Running   0          35s
test-app-5ddxxxxx94-pjdfn   1/1     Running   0          35s

Quatre pods sont en cours d'exécution. Le cinquième pod ne peut pas démarrer car le namespace n'a plus de quota CPU disponible.

Étape 6 : Vérifier l'utilisation du quota

kubectl -n test describe resourcequota

Sortie attendue :

Name:         test-quota
Namespace:    test
Resource      Used  Hard
--------      ----  ----
limits.cpu    4     4
requests.cpu  4     4

Les colonnes Used et Hard correspondent : le quota est entièrement consommé.

Étape 7 : Confirmer que le quota bloque les nouveaux pods

Passez le Deployment à 5 réplicas et observez l'application du quota :

Mettez le Deployment à l'échelle :

kubectl -n test scale deploy test-app --replicas 5

Vérifiez le ReplicaSet. La colonne DESIRED affiche 5 mais CURRENT affiche 4, ce qui signifie qu'un pod n'a pas pu être créé :
```
kubectl -n test get rs
```
Sortie attendue :
```
NAME                  DESIRED   CURRENT   READY   AGE
test-app-5ddxxxxx94   5         4         4       3m10s
```
Examinez les événements du ReplicaSet pour voir l'erreur de quota :
```
kubectl -n test describe rs test-app-5ddxxxxx94
```
La section Events affiche un avertissement FailedCreate similaire à :
```
Warning  FailedCreate  replicaset-controller  Error creating: pods "test-app-5ddc68c994-5s4ph" is forbidden: exceeded quota: test-quota, requested: limits.cpu=1,requests.cpu=1, used: limits.cpu=4,requests.cpu=4, limited: limits.cpu=4,requests.cpu=4
```
L'erreur identifie le nom du quota (test-quota), la quantité demandée, l'utilisation actuelle et la limite stricte, ce qui facilite le diagnostic et la résolution.

Étapes suivantes

Resource quotas — Référence officielle Kubernetes
LimitRange — Définir automatiquement des requêtes et limites de ressources par défaut pour les pods