> ## Documentation Index
> Fetch the complete documentation index at: https://infra-docs.kaeyros.org/llms.txt
> Use this file to discover all available pages before exploring further.

# Le socle Kubernetes partagé par toutes les applications

> Découvrez les composants installés une fois sur le cluster et utilisés par toutes les applications : déploiement continu, réseau, stockage, secrets et supervision.

Le socle partagé rassemble les outils installés une fois sur le cluster Kubernetes RKE2 de Kaeyros Analytics. Vous n'aurez normalement pas à les manipuler directement, mais leurs noms apparaissent dans les logs, les manifestes et les interfaces de supervision. Cette page vous aide à comprendre le rôle de chaque composant et son impact sur vos applications.

## Déploiement continu

> **ArgoCD**
>
> Namespace : `argocd`
>
> Lit le dépôt `argo-production` et applique automatiquement le contenu au cluster. C'est le cerveau du déploiement continu : chaque Application ArgoCD relie un chart Helm, un fichier de valeurs et un namespace. Il suit le motif `app-of-apps` : une Application racine `production` crée toutes les autres depuis le dossier `apps/`.

> **argocd-image-updater**
>
> Namespace : `argocd`
>
> Surveille les images publiées sur `ghcr.io` et met à jour le tag d'image dans les Applications ArgoCD concernées. Il fait le lien entre la chaîne de build (GitHub Actions) et le déploiement effectif sur le cluster.

> **argocd-notifications**
>
> Namespace : `argocd`
>
> Envoie un courriel à `devops@kaeyros-analytics.com` à chaque synchronisation d'une Application ArgoCD. Vous recevez ainsi une notification en cas de succès comme d'échec de déploiement.

> **Argo Rollouts**
>
> Namespace : `argo-rollouts`
>
> Gère les déploiements progressifs (canary). Il bascule le trafic par paliers vers la nouvelle version des pods, ce qui limite l'impact d'une régression. Les charts `rollout` et `rollout-v2` en dépendent.

## Administration

> **Rancher**
>
> Namespace : `cattle-system`
>
> Interface d'administration graphique du cluster. Rancher offre une alternative visuelle à `kubectl` pour consulter les ressources, les logs et les événements. Il est utile pour le diagnostic rapide ou pour les équipes moins familières avec la ligne de commande.

> **Fleet**
>
> Namespace : `cattle-fleet-system`
>
> Moteur GitOps intégré à Rancher. Chez Kaeyros Analytics, le déploiement continu passe principalement par ArgoCD : Fleet est installé mais peu utilisé en pratique.

## Réseau et TLS

> **cert-manager**
>
> Namespace : `cert-manager`
>
> Obtient et renouvelle automatiquement les certificats TLS auprès de Let's Encrypt. Deux `ClusterIssuer` sont configurés :
>
> * `letsencrypt-dns` (en réalité HTTP-01 via ingress Traefik) : cas courant
> * `letsencrypt-cloudflare` (DNS-01 via jeton Cloudflare) : wildcards et domaines proxifiés
>
> Lorsqu'un certificat est en attente de validation, des pods `cm-acme-http-solver-*` apparaissent temporairement dans le namespace cible.

> **Traefik**
>
> Namespace : `traefik`
>
> Reçoit le trafic HTTP entrant sur le port `websecure` (HTTPS, HTTP/3 activé) et l'aiguille vers le bon Service grâce aux règles d'Ingress. Traefik redirige aussi automatiquement le port 80 vers 443. Tous les Ingress du cluster utilisent `ingressClassName: traefik`.
>
> > [!NOTE]
> >
> > Beaucoup de fichiers de valeurs contiennent des annotations `nginx.ingress.kubernetes.io/*`. Elles sont sans effet car l'ingress controller est Traefik, pas Nginx. Pour un comportement équivalent, créez un Middleware Traefik et référencez-le depuis l'Ingress.

## Stockage

> **postgres-operator (Zalando)**
>
> Namespace : `default`
>
> Crée et gère les clusters PostgreSQL depuis un manifeste Kubernetes. Il orchestre environ 95 bases sur la plateforme. Chaque cluster est matérialisé par un pod nommé `<nom>-0`.

> **Longhorn**
>
> Namespace : `longhorn-system`
>
> Fournit des volumes persistants répliqués entre les nœuds du cluster. Il assure la résilience des données en cas de perte d'un nœud. Longhorn est le stockage par défaut pour les applications qui ont besoin de haute disponibilité.

> **local-path-provisioner**
>
> Namespace : `local-path-storage`
>
> Fournit des volumes locaux à un seul nœud, sans réplication. Utile pour les besoins légers ou temporaires où la redondance n'est pas nécessaire. Moins coûteux en ressources que Longhorn.

## Secrets et configuration

> **sealed-secrets**
>
> Namespace : `kube-system`
>
> Permet de commettre des secrets chiffrés dans Git sans risque de fuite. Le contrôleur les déchiffre automatiquement en Secrets Kubernetes classiques au moment du déploiement.

> **external-secrets**
>
> Namespace : `external-secrets`
>
> Synchronise des secrets depuis Vault vers des objets `Secret` Kubernetes. C'est le mécanisme privilégié pour injecter des credentials, des tokens ou des clés API dans les pods sans les stocker dans les dépôts de code.

> **reloader**
>
> Namespace : `reloader`
>
> Redémarre automatiquement un pod lorsque sa ConfigMap ou son Secret associé change. Il évite d'avoir à déclencher manuellement un rollout après une mise à jour de configuration.

## Supervision et divers

> **uptime-kuma-operator**
>
> Namespace : `uptime-operator`
>
> Crée des sondes de disponibilité automatiquement depuis les annotations d'Ingress. Il surveille que vos applications restent accessibles depuis l'extérieur et alerte en cas d'indisponibilité.

> **Stack de supervision**
>
> Namespace : `monitoring`
>
> Rassemble plusieurs agents de collecte :
>
> * **VictoriaMetrics agent** : agrégation des métriques
> * **node-exporter** : métriques des nœuds (CPU, mémoire, disque)
> * **kube-state-metrics** : métriques des objets Kubernetes (pods, déploiements, services)
> * **fluent-bit** : collecte et transfert des journaux vers le serveur de supervision

> **Taiga**
>
> Namespace : `taiga-prod`
>
> Outil interne de gestion de projet. Il n'est pas directement lié au cycle de déploiement mais fait partie du socle mutualisé accessible aux équipes.

## Pourquoi c'est important

> [!NOTE]
>
> Modifier un composant du socle affecte l'ensemble du parc, soit \~326 applications réparties sur 100 namespaces. Les changements se pensent à l'échelle de la plateforme, pas d'une application isolée. Si vous envisagez une modification (changement de version Traefik, rotation d'un ClusterIssuer, ajustement des règles Argo Rollouts), prévenez l'équipe DevOps à `devops@kaeyros-analytics.com` et planifiez l'intervention hors heures de pointe.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.