1. Une modification manuelle est effacéeLe paramètre
selfHeal est actif sur ArgoCD. Toute modification manuelle via kubectl edit ou kubectl set image est écrasée à la prochaine réconciliation. Passez toujours par Git pour faire évoluer une application.2. Renommer une Application recrée toutes les ressourcesLe renommage d’une Application ArgoCD recrée l’ensemble des ressources, y compris le Service Kubernetes. Le nom DNS interne change alors, et les appels service-à-service écrits en dur cessent de fonctionner. Consultez la page /deploiement/renommage pour les précautions à prendre.
3. Migrer de rollout vers rollout-v2 renomme aussi toutLe changement de chart
rollout vers rollout-v2 entraîne le renommage de l’ensemble des ressources. Planifiez cette migration hors des heures de pointe.4. valueFiles est relatif au dossier du chartLes chemins indiqués dans
valueFiles sont résolus par rapport au dossier du chart, d’où les chemins en ../../. Consultez la page /deploiement/anatomie-application pour le détail du fonctionnement.5. Annotations nginx.ingress.kubernetes.io/ sans effet*L’ingress controller de la plateforme est Traefik, pas NGINX. Les annotations
nginx.ingress.kubernetes.io/* sont donc sans effet. Consultez la page /deploiement/annotations-sans-effet pour les alternatives.6. service.additionalPorts ouvre le port du conteneur, pas celui du ServiceLe gabarit de chart expose uniquement le port
http. Un second port déclaré via service.additionalPorts est ouvert sur le conteneur, mais reste inatteignable par le Service Kubernetes.7. resources vide par défautPar défaut, les demandes et limites de ressources ne sont pas définies. Les pods sont alors en QoS
BestEffort, ce qui les rend plus vulnérables à l’éviction en cas de pression sur le nœud.8. Sondes désactivées par défautLes sondes de liveness et readiness ne sont pas activées par défaut dans les charts. Vous devez les activer explicitement dans le fichier de valeurs de votre application.
9. Dry-run ArgoCD désactivéL’annotation
SkipDryRunOnMissingResource=true est présente sur toutes les ressources. Le dry-run d’ArgoCD est donc contourné, et les erreurs de schéma ne sont pas détectées avant l’application. C’est pourquoi le contrôle local avec helm template est indispensable.10. Le dépôt ne dit pas quelle image tourneLe dépôt GitOps ne reflète pas nécessairement l’image réellement déployée. Consultez la page /deploiement/image-updater pour comprendre le mécanisme de mise à jour des images.
11. databases/, secrets/, traefik.yaml non synchronisésLes dossiers
databases/, secrets/ et le fichier traefik.yaml ne sont pas gérés par ArgoCD. Les modifier dans le dépôt ne déclenche aucun déploiement automatique.12. Dossier vald/ vise un autre clusterLe dossier
vald/ du dépôt cible un autre cluster. Ne le confondez pas avec la configuration de production.13. Charts init, test-init, apps : copies historiquesLes charts
init, test-init et apps sont des copies historiques du chart antid. Ne les ciblez pas pour créer une nouvelle application : utilisez antid-v2 ou rollout-v2.14. Nœud big-one-9d0479e4 évité par la configurationLe nœud
big-one-9d0479e4 est exclu du placement des pods par la configuration d’affinity. Un pod restant en état Pending avec une règle d’affinity non satisfaite peut venir de là. Consultez la page /infrastructure/placement-pods pour le détail.15. Manifeste de base sans metadata.namespace atterrit dans defaultUn manifeste Kubernetes qui ne précise pas
metadata.namespace est déployé dans le namespace default. Vérifiez toujours la présence de ce champ, ou passez par les templates de chart qui le positionnent automatiquement.16. La rotation des accès AWS applicatifs ne couvre pas la sauvegarde logique PostgresLe postgres-operator (Zalando) utilise sa propre credential AWS, portée par le Secret
logical-backup-s3-credentials (namespace default), pour envoyer les sauvegardes logiques vers S3. Elle est indépendante de la credential AWS utilisée par les applications dans leur bloc env. Rotater l’une ne rotate pas l’autre : une rotation « AWS » côté applicatif laisse les sauvegardes Postgres tourner avec l’ancienne clé jusqu’à sa désactivation côté AWS, ce qui fait échouer silencieusement le CronJob logical-backup-*. Consultez /infrastructure/sauvegardes pour le mécanisme complet.17. Deux secrets Cloudflare distincts par cluster, un seul est branché sur les certificatsLe
ClusterIssuer letsencrypt-cloudflare (résolution DNS-01) consomme le secret cloudflare-api-token du namespace cert-manager. Un autre secret peut coexister dans le namespace external-dns, résidu d’un external-dns désactivé sur certains clusters (voir /infrastructure/environnements) — rien ne garantit qu’il contienne le même jeton. Vérifiez toujours lequel des deux vous manipulez avant une rotation ou la création manuelle d’un enregistrement DNS.18. Les secrets d’image (ghcr-secret, argo-pull) sont dupliqués par namespaceCe ne sont pas des secrets référencés depuis un objet central : chaque namespace porte sa propre copie, soit plusieurs centaines d’objets à eux deux rien que sur le cluster de production. Rotater le token GHCR suppose de repasser namespace par namespace ; un oubli se traduit par des
ImagePullBackOff qui n’apparaissent pas tous au même moment, ce qui peut faire croire le problème résolu alors que des namespaces restent non traités.