> ## 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.

# Trajet d'une requête HTTP dans la plateforme

> Suivez le parcours complet d'une requête HTTP depuis le navigateur jusqu'à la base de données PostgreSQL. Identifiez chaque étape et les commandes de débogage associées.

Comprendre le trajet d'une requête HTTP vous aide à savoir où regarder quand quelque chose ne va pas. Cette page retrace le parcours complet d'une requête depuis le navigateur de l'utilisateur jusqu'à la base de données PostgreSQL, en passant par Cloudflare, le load balancer Hetzner, Traefik, l'Ingress, le Service, le Rollout et les pods. Chaque étape est accompagnée de commandes pratiques pour l'inspecter et la déboguer.

## Le trajet complet

Le diagramme ci-dessous montre le parcours d'une requête `https://api.exemple.com` à travers la plateforme Kaeyros Analytics.

```mermaid theme={null}
flowchart TB
    A["Navigateur<br/>(https://api.exemple.com)"] --> B["Cloudflare<br/>(résolution DNS, terminaison TLS de bordure)"]
    B --> C["Load balancer Hetzner<br/>(kaeyros.org 95.217.173.179 / sem-a.com 46.225.34.99)"]
    C --> D["Traefik<br/>(entrypoint websecure, HTTP/3, redirection 80→443)"]
    D --> E["Ingress<br/>(className: traefik, sélectionné par nom d'hôte)"]
    E --> F["Service ClusterIP<br/>(nom: &lt;application&gt;-&lt;chart&gt;)"]
    F --> G["Rollout<br/>(Argo Rollouts, pods gérés)"]
    G --> H["Pods<br/>(containers applicatifs)"]
    H --> I["PostgreSQL<br/>(&lt;nom&gt;-0, même namespace ou dans database)"]
```

## Chaque étape en détail

> **Navigateur**
>
> Le navigateur de l'utilisateur envoie une requête HTTPS vers l'URL publique de l'application (par exemple `https://api.exemple.com`). Il résout le nom d'hôte via DNS, établit une connexion TLS, puis transmet la requête HTTP.
>
> **Où déboguer:** Onglet Réseau des outils de développement du navigateur (F12).
>
> **Commande utile:**
>
> ```bash theme={null}
> curl -I -v https://api.exemple.com
> ```

> **Cloudflare**
>
> Cloudflare gère la résolution DNS pour les 18 zones de la plateforme et assure la terminaison TLS de bordure. Il sert également de pare-feu applicatif (WAF) et peut mettre en cache certaines ressources.
>
> **Où déboguer:** Console Cloudflare, onglet DNS et Security Events.
>
> **Commande utile:**
>
> ```bash theme={null}
> dig api.exemple.com
> ```

> **Load balancer Hetzner**
>
> Deux load balancers Hetzner répartissent le trafic entrant: `kaeyros.org` (95.217.173.179 à Helsinki) et `sem-a.com` (46.225.34.99 à Nuremberg). Ils dirigent le trafic vers les nœuds du cluster Kubernetes RKE2.
>
> **Où déboguer:** Console Hetzner Cloud, section Load Balancers.
>
> **Commande utile:**
>
> ```bash theme={null}
> curl -I --resolve api.exemple.com:443:95.217.173.179 https://api.exemple.com
> ```

> **Traefik**
>
> Traefik est l'ingress controller du cluster. Il écoute sur l'entrypoint `websecure`, gère HTTP/3, redirige automatiquement le port 80 vers 443, et route les requêtes vers l'Ingress correspondant en fonction du nom d'hôte.
>
> **Où déboguer:** Dashboard Traefik (accessible via port-forward) ou logs des pods Traefik.
>
> **Commande utile:**
>
> ```bash theme={null}
> kubectl -n traefik get pods
> kubectl -n traefik logs -l app.kubernetes.io/name=traefik --tail=100
> ```

> **Ingress**
>
> L'objet Ingress (avec `ingressClassName: traefik`) définit les règles de routage par nom d'hôte. Il associe un nom de domaine à un Service interne du cluster. Attention: les annotations `nginx.ingress.kubernetes.io/*` présentes dans de nombreux fichiers de valeurs n'ont aucun effet car l'ingress controller est Traefik, pas NGINX.
>
> **Où déboguer:** Description de l'objet Ingress dans le namespace de l'application.
>
> **Commande utile:**
>
> ```bash theme={null}
> kubectl -n <namespace> get ingress
> kubectl -n <namespace> describe ingress <nom-de-l-ingress>
> ```

> **Service ClusterIP**
>
> Le Service de type ClusterIP expose l'application à l'intérieur du cluster. Son nom suit la convention `fullname = <Application>-<chart>`. C'est ce nom DNS interne que les autres services utilisent pour communiquer (par exemple `http://<service>.<namespace>.svc.cluster.local`).
>
> > [!WARNING]
> >
> > Renommer une Application recrée le Service et change son nom DNS interne. Cela casse les appels service-à-service écrits en dur. Planifiez ce type de changement hors heures de pointe.
>
> **Où déboguer:** Endpoints du Service et état des cibles.
>
> **Commande utile:**
>
> ```bash theme={null}
> kubectl -n <namespace> get svc
> kubectl -n <namespace> get endpoints <nom-du-service>
> ```

> **Rollout**
>
> Le chart `rollout` (ou `rollout-v2`, recommandé) gère le déploiement via Argo Rollouts. Il contrôle le nombre de replicas, les mises à jour progressives (canary) et la répartition des pods sur les nœuds. Par défaut, le chart `rollout` éloigne les pods du nœud `big-one-9d0479e4` avec une préférence de poids 100 (`preferredDuringScheduling`).
>
> **Où déboguer:** Interface ArgoCD ou description du Rollout.
>
> **Commande utile:**
>
> ```bash theme={null}
> kubectl -n <namespace> get rollout
> kubectl -n <namespace> describe rollout <nom-du-rollout>
> ```

> **Pods**
>
> Les pods exécutent les conteneurs applicatifs. Le nom complet d'un pod suit le schéma: `<Application>-<chart>-<hash ReplicaSet>-<hash pod>`. Par exemple: `biolab-prod-api-rollout-v2-787d6449d4-vntt5` correspond à l'Application `biolab-prod-api` avec le chart `rollout-v2`.
>
> **Où déboguer:** Logs des pods et événements du namespace.
>
> **Commande utile:**
>
> ```bash theme={null}
> kubectl -n <namespace> get pods
> kubectl -n <namespace> logs <nom-du-pod> --tail=200
> kubectl -n <namespace> describe pod <nom-du-pod>
> ```

> **PostgreSQL**
>
> La base de données PostgreSQL est gérée par l'opérateur Zalando. Le pod principal porte le suffixe `-0` (par exemple `<nom>-0`). La base peut résider dans le même namespace que l'application ou dans le namespace dédié `database`.
>
> **Où déboguer:** État du cluster PostgreSQL via patronictl.
>
> **Commande utile:**
>
> ```bash theme={null}
> kubectl -n <namespace> exec <nom-du-cluster>-0 -- patronictl list
> kubectl -n <namespace> get pods -l cluster-name=<nom-du-cluster>
> ```

## Où regarder quand ça ne marche pas

| Symptôme | Étape à inspecter | Commande |
| - | - | - |
| DNS ne résout pas | Cloudflare | `dig <hôte>` |
| Erreur TLS / certificat invalide | cert-manager / ClusterIssuer | `kubectl get certificate -A \| grep -v ' True '` |
| 404 Traefik | Ingress mal configuré | `kubectl -n <ns> describe ingress <nom>` |
| 502 Bad Gateway / 503 Service Unavailable | Service ou pods | `kubectl -n <ns> get pods,endpoints` |
| Base de données injoignable | PostgreSQL | `kubectl -n <ns> exec <cluster>-0 -- patronictl list` |

> [!NOTE]
>
> Si un certificat reste en attente, des pods `cm-acme-http-solver-*` peuvent persister dans le namespace. Vérifiez que le ClusterIssuer approprié est utilisé: `letsencrypt-dns` pour le cas courant (HTTP-01 via Traefik) ou `letsencrypt-cloudflare` pour les wildcards et domaines proxifiés (DNS-01).

> [!TIP]
>
> Pour les problèmes récurrents, commencez toujours par vérifier les logs Traefik et les événements du namespace concerné. Ils indiquent souvent directement l'étape qui échoue.

Pour toute question ou information manquante, contactez l'équipe DevOps: [devops@kaeyros-analytics.com](mailto:devops@kaeyros-analytics.com)


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