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

# Placement des pods et exclusion de big-one-9d0479e4

> Deux règles de placement Kubernetes expliquent pourquoi la plupart des pods évitent le nœud big-one-9d0479e4 et pourquoi les traitements data-precompute refusent de s'y planifier.

Deux règles de placement méritent d'être connues dès le départ, parce qu'elles expliquent des comportements surprenants : pourquoi certains pods ne se posent jamais sur le nœud `big-one-9d0479e4`, et pourquoi d'autres restent bloqués en `Pending` si ce nœud est le seul disponible. Cette page détaille ces règles, leurs conséquences pratiques et comment diagnostiquer un pod qui refuse de démarrer.

## Règle 1 : le chart rollout évite big-one-9d0479e4

En l'absence d'affinity explicite dans votre fichier de valeurs, le chart `rollout` injecte automatiquement une préférence négative qui demande au scheduler d'éviter le nœud `big-one-9d0479e4` tant qu'un autre convient.

Il s'agit d'une règle de type `preferredDuringSchedulingIgnoredDuringExecution` avec un poids de 100. Le scheduler essaiera donc de placer le pod ailleurs, mais acceptera `big-one-9d0479e4` si les trois autres nœuds sont pleins.

Voici ce que cela donne dans le manifeste rendu :

```yaml theme={null}
affinity:
  nodeAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 100
        preference:
          matchExpressions:
            - key: kubernetes.io/hostname
              operator: NotIn
              values:
                - big-one-9d0479e4
```

Cette règle s'applique à toutes les applications déployées avec le chart `rollout` (ou `rollout-v2`) sauf si vous redéfinissez explicitement le bloc `affinity` dans votre fichier de valeurs.

## Règle 2 : data-precompute exclut strictement

Les manifestes de `values/data-precompute/` appliquent la même exclusion, mais en version stricte : `requiredDuringSchedulingIgnoredDuringExecution`. Ces pods REFUSENT de se planifier sur le nœud `big-one-9d0479e4`.

> [!WARNING]
>
> Si le nœud `big-one-9d0479e4` est le seul disponible (par exemple si les trois masters sont saturés ou en maintenance), les pods `data-precompute` restent en `Pending` indéfiniment. Le scheduler ne les placera jamais sur ce nœud.

## Conséquence pratique

L'essentiel de la charge repose sur les trois nœuds du plan de contrôle. C'est inhabituel pour un cluster Kubernetes, où l'on attend plutôt que les masters restent dédiés à la gestion du cluster.

```mermaid theme={null}
flowchart LR
    subgraph "Plan de contrôle + workload"
        A["antid<br/>(master)"]
        B["ubuntu-2204-jammy<br/>(master)"]
        C["ubuntu-2404-noble<br/>(master)"]
    end
    D["big-one-9d0479e4<br/>(worker)"]

    A -->|"charge normale"| A
    B -->|"charge normale"| B
    C -->|"charge normale"| C
    D -->|"sous-utilisé, évité"| D
```

> [!NOTE]
>
> L'essentiel de la charge repose sur les 3 nœuds du plan de contrôle. C'est inhabituel pour un cluster Kubernetes, et cela signifie que vos 3 masters portent aussi du workload applicatif. Prenez cela en compte lorsque vous dimensionnez les ressources CPU et mémoire de vos pods.

## Raison historique

> [!WARNING]
>
> La raison exacte de cette exclusion n'est pas documentée. C'est une question à poser à l'équipe infrastructure ([devops@kaeyros-analytics.com](mailto:devops@kaeyros-analytics.com)) avant de dimensionner quoi que ce soit ou de modifier ces règles. Ne supprimez pas le bloc `affinity` sans validation.

## Diagnostiquer un pod bloqué en Pending

Si un pod reste en `Pending`, vérifiez d'abord s'il est victime d'une règle d'affinity.

```bash Pourquoi Pending theme={null}
kubectl -n <ns> describe pod <pod>
# Regardez la section Events en bas: "0/4 nodes are available: 1 node(s) didn't match affinity"
```

```bash Voir les règles theme={null}
kubectl -n <ns> get pod <pod> -o yaml | grep -A20 affinity
```

```bash Contourner (à discuter) theme={null}
# Retirer ou adapter le bloc affinity dans le fichier de valeurs Helm,
# puis redéployer via ArgoCD. Validez avec l'équipe infrastructure avant.
```


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