For AI agents: the complete documentation index is available at https://docs.ovhcloud.com/fr/llms.txt, the full documentation bundle is available at https://docs.ovhcloud.com/fr/llms-full.txt, and this page is available as Markdown at https://docs.ovhcloud.com/fr/guides/public-cloud/containers-orchestration/managed-kubernetes/etcd-quota-error.md.

Quotas ETCD, utilisation, dépannage et erreurs

Voir en Markdown

Découvrez comment consulter les quotas et l'utilisation ETCD, et corriger les erreurs

Objectif

ETCD est l'un des composants majeurs d'un cluster Kubernetes. C'est une base de données clé-valeur distribuée qui permet de stocker et de répliquer l'état du cluster.

Composants Kubernetes

À un moment donné de la vie de votre cluster Managed Kubernetes, vous pouvez rencontrer l'une des erreurs suivantes, qui vous empêchent de modifier des ressources :

rpc error: code = Unknown desc = ETCD storage quota exceeded
rpc error: code = Unknown desc = quota computation: etcdserver: not capable
rpc error: code = Unknown desc = The OVHcloud storage quota has been reached

Ce guide vous montre comment consulter votre utilisation et votre quota, diagnostiquer et résoudre cette situation.

Prérequis

  • Un cluster OVHcloud Managed Kubernetes
  • L'outil en ligne de commande kubectl installé

En pratique

Contexte

Chaque cluster Kubernetes dispose d'un quota dédié sur l'utilisation du stockage ETCD, calculé selon la formule suivante :

Quota = 10MB + (25MB per node)* (capped to 400MB)

Par exemple, un cluster comportant 3 serveurs b2-7 dispose d'un quota de 85 Mo.

Afin de vérifier votre quota et votre utilisation ETCD actuels, vous pouvez interroger l'API OVHcloud.

GET/cloud/project/{serviceName}/kube/{kubeId}/metrics/etcdUsage

Résultat :

{
  "quota": 89128960,
  "usage": 2604349
}
Info

Le résultat du quota et de l'utilisation ETCD est exprimé en octets.

Grâce à cet endpoint d'API, vous pouvez consulter l'utilisation et le quota ETCD, et anticiper un éventuel problème.

Le quota peut ainsi être augmenté en ajoutant des nœuds, mais ne sera jamais diminué (même si tous les nœuds sont supprimés), afin d'éviter toute perte de données. L'erreur mentionnée ci-dessus indique que l'utilisation du stockage ETCD du cluster a dépassé le quota.

Pour résoudre cette situation, vous devez supprimer les ressources créées en excès.

Cas le plus fréquent : mauvaise configuration de cert-manager

La plupart des utilisateurs installent cert-manager via Helm, puis passent à autre chose un peu trop rapidement.

Les cas les plus fréquents de problèmes de quota ETCD proviennent d'une mauvaise configuration de cert-manager, qui l'amène à créer en continu des ressources certificaterequest.

Ce comportement va remplir l'ETCD de ressources jusqu'à ce que le quota soit atteint.

Pour vérifier si vous êtes dans cette situation, vous pouvez obtenir le nombre de ressources certificaterequest et order.acme :

kubectl get certificaterequest.cert-manager.io -A | wc -l
kubectl get order.acme.cert-manager.io -A | wc -l

Si vous obtenez un nombre très élevé (des centaines ou plus) de ces demandes de ressources, vous avez trouvé la cause racine.

Pour résoudre la situation, nous proposons la méthode suivante :

  • Arrêter cert-manager
kubectl -n <your_cert_manager_namespace> scale deployment --replicas 0 cert-manager
  • Vider toutes les ressources certificaterequest et order.acme
kubectl delete certificaterequest.cert-manager.io -A --all
kubectl delete order.acme.cert-manager.io -A --all
  • Mettre à jour cert-manager

Il n'existe pas de méthode générique pour cela, mais si vous utilisez Helm, nous vous recommandons de l'utiliser pour la mise à jour : documentation officielle de Cert Manager

  • Corriger le problème

Nous vous recommandons de suivre les étapes suivantes pour diagnostiquer votre cert-manager et vous assurer que tout est correctement configuré : dépannage Acme

  • Redémarrer cert-manager

Autres cas

Si cert-manager n'est pas la cause racine, vous devriez vous intéresser aux autres opérateurs en cours d'exécution qui créent des ressources Kubernetes. Nous avons constaté que les ressources suivantes peuvent parfois être générées en continu par des opérateurs existants :

  • backups.velero.io
kubectl get backups.velero.io -A | wc -l
  • podvolumebackups.velero.io
kubectl get podvolumebackups.velero.io -A | wc -l
  • ingress.networking.k8s.io
kubectl get ingress.networking.k8s.io -A | wc -l
  • ingress.extensions
kubectl get ingress.extensions -A | wc -l
  • authrequests.dex.coreos.com
kubectl get authrequests.dex.coreos.com -A | wc -l
  • reportchangerequest.kyverno.io
kubectl get reportchangerequest.kyverno.io -A | wc -l
  • vulnerabilityreports.aquasecurity.github.io
kubectl get vulnerabilityreports.aquasecurity.github.io -A | wc -l
  • configauditreport.aquasecurity.github.io
kubectl get configauditreport.aquasecurity.github.io -A | wc -l
  • clusterrbacassessmentreport.aquasecurity.github.io
kubectl get clusterrbacassessmentreport.aquasecurity.github.io -A | wc -l

Si cela ne couvre toujours pas votre cas, vous pouvez utiliser un outil comme ketall pour lister et compter facilement les ressources de votre cluster. Vous devrez alors supprimer les ressources en excès et corriger le processus responsable de leur création.

Compter toutes les ressources

Si vous avez encore besoin de vérifier toutes les ressources parce que vous ne savez pas ce qui consomme les quotas etcd, vous pouvez exécuter cet extrait. Vous aurez besoin du plugin count pour kubectl. Consultez les instructions d'installation.

kubectl count -A $(kubectl api-resources --verbs=list -o name | tr '\n' ',')
+-----------+---------------------------------------+--------------------------------+-------+
| Namespace |             GroupVersion              |              Kind              | Count |
+-----------+---------------------------------------+--------------------------------+-------+
|           | v1                                    | ComponentStatus                |     3 |
+-----------+                                       +--------------------------------+-------+
|           |                                       | ConfigMap                      |    78 |
+-----------+                                       +--------------------------------+-------+
|           |                                       | Endpoints                      |    44 |
+-----------+                                       +                                +       +
|           |                                       |                                |       |
+-----------+                                       +--------------------------------+-------+
|           |                                       | Event                          |    40 |
+-----------+---------------------------------------+                                +       +
|           | events.k8s.io/v1                      |                                |       |
+-----------+---------------------------------------+--------------------------------+-------+
...

L'exécution de la commande peut prendre plusieurs secondes, selon l'utilisation de votre cluster Kubernetes.

Aller plus loin

Pour en savoir plus sur l'utilisation pratique de votre cluster Kubernetes, nous vous invitons à consulter notre site de documentation OVHcloud Managed Kubernetes.

  • Pour une formation ou une assistance technique sur la mise en œuvre de nos solutions, contactez votre commercial ou consultez la page Professional Services pour obtenir un devis et faire analyser votre projet par nos experts.

  • Échangez avec notre communauté d'utilisateurs.

Cette page vous a-t-elle aidé ?