La PriorityClass de Vault était refusée par l'AppProject, et toute l'app restait OutOfSync
Helm Charts / Detect changed charts (pull_request) Successful in 22s
Helm Charts / Library charts tool (pull_request) Skipped
Helm Charts / Application charts alloy (pull_request) Skipped
Helm Charts / Application charts crowdsec (pull_request) Skipped
Helm Charts / Application charts grafana (pull_request) Skipped
Helm Charts / Application charts hashicorp-vault (pull_request) Skipped
Helm Charts / Application charts loki (pull_request) Skipped
Helm Charts / Application charts minio (pull_request) Skipped
Helm Charts / Application charts pgbouncer (pull_request) Skipped
Helm Charts / Application charts pgcat (pull_request) Skipped
Helm Charts / Application charts prometheus (pull_request) Skipped
Helm Charts / Application charts redis (pull_request) Skipped
Helm Charts / Application charts chart (pull_request) Successful in 34s

Suite de #46. La PriorityClass `vault-critical` y était correcte, mais elle n'a
jamais atteint le cluster :

  SyncFailed | PriorityClass/vault-critical
  resource scheduling.k8s.io:PriorityClass is not permitted in project tools

Une PriorityClass est cluster-scoped, et le `clusterResourceWhitelist` de
l'AppProject `tools` ne l'autorisait pas. Conséquence non évidente : ArgoCD ne
refuse pas seulement cette ressource, il fait échouer la SYNCHRONISATION ENTIÈRE
de l'application. `hashicorp-vault` est donc resté OutOfSync après cinq
tentatives, et les `requests` mémoire de #46 n'ont pas atterri non plus.

À côté, `prometheus` a synchronisé sans problème : l'alerte VaultIndisponible de
#46 est bien en place dans la ConfigMap. C'est ce qui rendait le symptôme
trompeur — la moitié du travail était visible.

CE QUE CE CHANGEMENT FAIT, ET CE QU'IL NE FAIT PAS

Une ligne, un kind. Cette liste est un garde-fou volontaire : elle borne ce qu'une
application de `tools` peut créer hors de son namespace. On l'élargit donc d'un
kind à la fois, avec sa raison écrite à côté.

Une PriorityClass ne porte ni droit ni donnée. Elle ne fait qu'ordonner
l'éviction et la préemption — c'est le seul pouvoir qu'on accorde ici.

Vérifié : `helm lint` passe, `helm template` rend bien l'entrée, et la liste
compte désormais cinq kinds au lieu de quatre.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
This commit is contained in:
2026-09-11 15:25:00 +02:00
co-authored by Claude Opus 5
parent e32faa3c77
commit 3cfa83b2d6
+16 -1
View File
@@ -24,4 +24,19 @@ spec:
- group: '*' - group: '*'
kind: MutatingWebhookConfiguration kind: MutatingWebhookConfiguration
- group: 'apiextensions.k8s.io' - group: 'apiextensions.k8s.io'
kind: CustomResourceDefinition kind: CustomResourceDefinition
# PriorityClass — ajoutée le 2026-09-11, et une seule raison la justifie.
# `hashicorp-vault/templates/priorityclass.yaml` déclare `vault-critical`, qui sort
# Vault de la classe `BestEffort` où il était le premier pod évincé du cluster (il y
# est resté SCELLÉ onze jours après l'éviction du 30/08). Une PriorityClass est
# cluster-scoped : sans cette ligne ArgoCD refuse la synchronisation ENTIÈRE de
# l'application — constaté, `hashicorp-vault` est resté OutOfSync sur
# « resource scheduling.k8s.io:PriorityClass is not permitted in project tools »,
# après 5 tentatives.
#
# Cette liste est un GARDE-FOU, pas une formalité : elle borne ce qu'une application
# de `tools` peut créer hors de son namespace. On y ajoute donc un kind à la fois,
# avec sa raison. Une PriorityClass ne porte ni droit ni donnée : elle ne fait
# qu'ordonner l'éviction et la préemption.
- group: 'scheduling.k8s.io'
kind: PriorityClass