Architecture

Le problème

Plusieurs équipes ont besoin de conteneurs fonctionnant sur un petit nombre de machines partagées, et chaque équipe ne doit pas pouvoir voir ni perturber les autres. Faire cela avec un seul moteur de conteneurs signifie que quelqu’un garde toute l’image en tête : quelle machine a de la place, quel conteneur appartient à qui, quelle était la configuration en cours d’exécution, et quoi faire quand une machine disparaît à trois heures du matin.

Comment la plateforme résout ce problème

Odysseus divise cette image en trois parties, et une seule d’entre elles fait autorité.

Vous déclarez ce que vous voulez. Un déploiement est une description — une image, combien de copies, ce qu’elles peuvent atteindre, ce qui les façonne. Vous l’écrivez une fois, sur la surface qui vous convient : un manifeste YAML, l’API REST, le tableau de bord, ou un outil d’agent. Les quatre aboutissent au même enregistrement stocké.

Le plan de contrôle décide. Il admet ou refuse votre modification (chaque refus nomme le champ et la forme acceptée — voir rejets et altérations), choisit quel nœud exécute chaque conteneur, et transforme la description stockée en une charge utile de dispatch versionnée. La charge utile porte un hachage de tout ce qui façonne le conteneur, donc la différence entre « vous avez modifié la description » et « le conteneur doit être remplacé » est calculée plutôt que jugée. La colonne de mutabilité du référence du déploiement est ce hachage, mesuré.

L’agent agit. Un agent s’exécute sur chaque nœud. Il reçoit les dispatches, pilote le moteur de conteneurs local, et rapporte ce qu’il voit. Il ne décide jamais du placement et n’invente jamais de configuration : un nœud qui perd le contact continue d’exécuter ce qu’il a plutôt que d’improviser.

Ce qui s’exécute n’est jamais la vérité de ce qui devrait s’exécuter. La description stockée est cette vérité, le hachage indique si les conteneurs la correspondent, et le travail du réconciliateur est de combler l’écart. Les conteneurs sont surveillés en permanence — l’agent rapporte ce qu’il observe, et le plan de contrôle répare à partir de ces rapports — mais une observation ne devient jamais la description.

La même boucle exécute le travail qui se répète. Une planification crée une tâche lorsque la tâche est due, et la plateforme suit si cette tâche a jamais atteint un nœud : une qui ne l’a jamais fait — parce que le nœud auquel elle était attachée n’est pas inscrit, ou parce qu’aucun conteneur pour elle n’a jamais été vu — peut encore être corrigée en modifiant la planification, et une planification dont les déclenchements continuent de ne rien atteindre est signalée comme bloquée plutôt que laissée en apparence saine. Ce que chacun de ces mots signifie est dans travail planifié.

Not this

Cette page ne décrit pas comment installer un nœud, et elle ne répertorie pas les ports, les noms d’hôte ou les variables d’environnement pour une installation particulière. Ceux-ci appartiennent aux guides opérationnels, qui décrivent un déploiement de la plateforme plutôt que la plateforme elle-même.

Elle ne couvre pas non plus le bord de routage. Traefik termine le TLS et route vers les conteneurs ; ce qu’un déploiement déclare à ce sujet est ingress, dans la référence de déploiement.

Où le voir

• La description stockée, champ par champ : manifeste de déploiement.
• Ce que le plan de contrôle refuse, et les modifications qu’il apporte sans que vous les ayez envoyées : rejets et altérations.
• Les termes que cette documentation utilise pour chaque partie : glossaire.