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]>
Alloy plutôt que Promtail, que l'amont a marqué déprécié. Rétention 30 jours,
calée sur 305 Mio/jour mesurés — et la mesure a révélé pire que ce que l'issue
supposait : traefik ne gardait que 10 minutes d'histoire, clickhouse 2.
La propriété tient, éprouvée : jeton écrit, pod supprimé, `kubectl logs` ne
répond plus, Loki rend encore les lignes.
Ferme #38.
Co-Authored-By: Claude Opus 5 <[email protected]>
Co-authored-by: Gabriel Radureau <[email protected]>
Le fondateur : « on déploie MinIO dans le repo tools du homelab non ? » — oui,
c'est bien le pattern : le dossier tools/ porte les briques PARTAGÉES
(pgbouncer, clickhouse, grafana…) et le namespace tools les fait tourner ; les
charts applicatifs vivent dans le repo de leur app.
Décidé de longue date côté produit, jamais déployé : ADR-012 « MinIO local
d'abord » (bascule R2 à 100+ utilisateurs / 10 To par mois), ADR-013 (le gratuit
reste local-first, MinIO sert les paliers payants). Vérifié avant d'écrire :
aucun pod ni service MinIO dans le cluster.
Le chart suit la recette du repo (dépendance à la library "tool" + chart amont
en SubChart, deux gardes dans templates/) :
- mode STANDALONE, 1 réplique : ce qui transite est DÉRIVÉ (le master d'une
vidéo reste sur l'appareil de son propriétaire, ADR-018) et Longhorn réplique
déjà le volume — l'erasure coding distribué coûterait de la RAM que des Pi 5
n'ont pas à dépenser pour ça ;
- 50 Gi sur longhorn ≈ 250 h de cours au palier « travail » (360p, 3,4 Mo/min) ;
⚠ Longhorn réplique : compter ×3 sur la capacité avant d'augmenter ;
- ressources bornées (512 Mi / 2 Gi) : la limite protège les voisins de tools ;
- API s3.arcodange.lab + console minio.arcodange.lab (Traefik) ;
- bucket kadans-videos PRIVÉ — l'accès passera par des URL signées (ADR-0002) ;
- identifiants JAMAIS au dépôt : iac/ les génère dans Vault (kvv2/minio/config),
le Vault Secrets Operator les matérialise, le chart les lit via existingSecret.
Le SA du pod est nommé "minio" (pas le "minio-sa" amont) car le module
app_roles borne l'authentification au SA portant le nom de l'app.
⚠ Le workflow minio.yaml écrit ses triggers EN TOUTES LETTRES : une ancre YAML
dans un trigger Gitea Actions fait taire push ET pull_request en silence (vécu
sur arcodange/kadans, issues 113→117). Les workflows plausible/crowdsec/vault de
ce repo en utilisent encore — à vérifier séparément, c'est probablement
pourquoi ils ne partent qu'à la main.
Vérifié : helm dependency update + helm template (11 ressources rendues, SA et
VaultAuth cohérents) + helm lint ✓.
Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01CoafGWmRVESaWX819USUUA
arcodangeandClaude Opus 5