Skip to content
Snippets Groups Projects
Commit 99fe4c02 authored by kaiyou's avatar kaiyou
Browse files

Improve hepto architecture docs

parent 4c59730d
No related branches found
No related tags found
No related merge requests found
Pipeline #5819 passed
Stage: pages
Stage: deploy
Hide whitespace changes
Inline Side-by-side
Showing
with 141 additions and 341 deletions
content/docs/hepto/architecture.md deleted 100644 → 0
+ 0
− 208
View file @ 4c59730d
---
title: Architecture
---
## Vue générale
### Description d'un *cluster*
Un *cluster* hepto est constitué :
- d'hôtes physiques, possédés par les contributeurs au *cluster* ;
- de nœuds du cluster, chaque nœud étant instancié sur un hôte physique ;
- d'une surcouche réseau, regroupant ces nœuds sur un même réseau privé
virtuel (VPN) sécurisant les communications à suivre ;
- d'une surcouche orchestration, exploitant le CPU, la RAM et le stockage
des nœuds pour y déployer des applications et rendre des services ;
- d'une surcouche de contribution, permettant le travail collaboratif sur
les ressources du *cluster*, l'historisation des modifications, le
déploiement continu, etc. ;
- d'outils pré-déployés, tels que les *reverse proxy* d'accès aux services,
la gestion des certificats TLS, la supervision des ressources, la
collecte et le traitement des journaux, etc.
Il est distribué, c'est à dire que les ressources sont mises à disposition
par des individus collaborant, mais pas nécessairement appartenant à la même
association, entreprise, collectif, etc. Chaque contributeur peut par exemple
disposer d'un hôte à son domicile, et décider de l'allouer pour partie à un
nœud d'un premier *cluster*, pour partie à un nœud d'un autre *cluster*, et
d'en conserver la maîtrise pour stocker ses documents personnels.
Il est résilient, c'est à dire qu'une application déployée et ses données ne
sont pas gérées sur le nœud d'un unique contributeur. En cas de panne de
courant, d'accès à Internet, de déménagement, ou simplement si le contributeur
décide subitement de déconnecter son nœud, le *cluster* continue d'exister
et les applications continuent de fonctionner sur les autres nœuds.
Il est économe, c'est à dire qu'il peut reposer sur des machines à faible
consommation, et que la somme des ressources peut approcher la somme des
besoins des applications, au facteur de réplication près. Egalement, la
configuration de l'orchestration tient compte de la topologie du *cluster*
et du coût -- financier et énergétique -- des communications à travers
Internet, pour les minimiser tant que possible.
### Terminologie
Un hôte est une machine physique, il s'agit généralement d'un ordinateur
personnel de récupération ou d'un micro-serveur. Il peut être utilisé pour
contribuer à un ou plusieurs *clusters* hepto, voire servir en parallèle
d'autres applications de son propriétaire.
Un nœud matérialise l'allocation de tout ou partie des ressources de
l'hôte sur lequel il repose au profit d'un *cluster* hepto. Un nœud est
concrètement constitué de deux programmes : la contribution à la surcouche
réseau et la contribution à la surcouche orchestration.
Le *cluster* hepto est réalisé par l'ensemble des nœuds qui le constituent,
il fournit les primitives réseau et d'orchestration aux applications qui
y sont hébergées.
Dans le contexte de hepto, un *pod* peut techniquement faire référence à
un *pod* Podman, technologie employée pour gérer les nœuds, ou bien un
*pod* kubernetes, technologie employée pour la couche d'orchestration.
Sauf précision, il s'agit d'un *pod* au sens kubernetes.
Un *namespace* représente un espace de nommage de la couche orchestration,
il s'agit de l'unité d'allocation des ressources dans un environnement
multi-utilisateurs.
### Technologies
Les technologies suivantes sont celles actuellement employées dans le
laboratoires hepto. Elles sont susceptibles d'évoluer régulièrement :
- les hôtes sont limités aux machines de l'architecture AMD64, avec
au minimum 1Go de mémoire vive et 50Go de stockage ;
- les nœuds sont constitués par des *pods* Podman, eux-mêmes
organisés en deux conteneurs, l'un pour la surcouche réseau, l'autre
pour la surcouche orchestration ;
- la surcouche réseau est opérée par wesher, qui négocie et configure des
VPN Wireguard en *full-mesh* entre tous les membres du cluster ;
- la surcouche orchestration est opérée par k3s, une version allégée
de l'orchestration de conteneur kubernetes ;
- la surcouche contribution repose sur Git (par exemple un dépôt sur
une instance Gitlab) et ArgoCD, une solution de déploiement continu
conforme aux principes GitOps.
### Périmètres de responsabilités
Un *cluster* hepto est initié et géré généralement par un groupement,
nommé responsable du *cluster*. Ce groupement dispose des privilèges
d'administration du *cluster* au niveau de la surcouche d'orchestration
et dispose de l'ensemble des clés de sécurité du *cluster*, y compris
celles protégeant la surcouche réseau.
Un nœud hepto fait partie du *cluster*, et est donc sous la
responsabilité du responsable du *cluster*, de même que l'ensemble des
ressources qui y sont orchestrées, sauf délégation.
Un hôte abritant un nœud hepto est sous la responsabilité du propriétaire
de l'équipement. Il peut s'agir de la même entité que le responsable du
*cluster*, mais il peut également s'agir d'un individu ou d'un groupement
tiers. Par exemple, des associations peuvent mettre à disposition chacune
des hôtes pour héberger les nœuds d'un *cluster* hepto géré en fédération
d'associations ; ou bien une association gérer un *cluster* hepto reposant
pour une part sur des nœuds hébergés sur ses propres hôtes et sur des
nœuds contribués par ses membes mais dont l'association n'est pas
propriétaire.
Au sein d'un *cluster* hepto, le responsable du *cluster* peut décider
de déléguer la gestion d'un ou plusieurs *namespaces* à des tiers. Dans
ce cas, la convention de délégation précise les périmètres de responsabilité.
### Représentation globale
## Choix de conception
L'architecture de hepto, simple en apparence, repose sur des choix de
conception non triviaux, dont les principaux sont explicités à suivre.
### Socle réseau et socle orchestration
Les ressources mises en commun dans le cadre d'un *cluster* sont :
- la puissance CPU ;
- la capacité mémoire ;
- la capacité de stockage ;
- la connectivité réseau ;
- l'espace d'adressage et de nommage.
Ces ressources sont principalement divisées entre les ressources réseau,
à savoir la connectivité et la capacité de routage associée d'une part ;
et les ressources d'orchestration -- le reste.
Lors de la conception d'un *cluster* distribué géographiquement, il apparaît
que la connectivité réseau est essentielle et associée à des propriétés
encore peu systématisées dans le déploiement de *clusters* traditionnels,
à commencer par la sécurité des communications internes au *cluster*.
Aussi, il apparaît que les deux types de ressources doivent être gérés par
deux technologies distinctes bien que complémentaires. En résultent deux
approches envisageables :
- soit disposer d'une connectivité réseau sécurisée entre les nœuds du
cluster, sur la base de laquelle l'orchestration est construite ;
- soit construire une orchestration indépendamment des propriétés de
sécurité réseau et déployer en sus les outils pour sécuriser les
communications au sein des applications.
La première approche est assez traditionnelle, orientée *VPN* (réseau
privé virtuel, construit par dessus l'infrastructure réseau existante),
tandis que la seconde s'inscrit dans la logique contemporaine du *zero trust*,
ne postulant ni de la confiance dans l'infrastructure sous-jacente à
l'orchestration, ni dans la confiance des applications entre elles au sein
du *cluster*.
#### Les limites du zero-trust
L'approche *zero-trust*, non seulement par sa modernité, mais également par
sa vision très conservatrice de la sécurité, est particulièrement séduisante
pour construire un système moderne.
Les technologies associées sont largement regroupées sous la dénomination de
*service mesh*, parmi lesquels Istio, linkerd ou bien Consul. A la marge, des
orchestrateurs réseau pour kubernetes, tels que Cilium, offrent des propriétés
de sécurité du trafic entre les applications du *cluster*.
Ces technologies ont un point commun principal : elles reposent pour leur
fonctionnement sur des primitives supposées sécurisées, quelques-unes sur une
infrastructure de gestion de clés, et toutes sur un orchestrateur, le plus
souvent kubernetes (certaines supportent également Swarm ou Nomad).
Or, la sécurisation de la surcouche d'orchestration, en particulier à travers
Internet sans disposer de réseau sécurisé sous-jacent, est une tâche délicate.
Les guides de sécurisation existent, mais tous ne sont pas toujours applicables.
Par exemple, k3s, une distribution de kubernetes allégée -- aujourd'hui
employée dans hepto --, ne supporte pas TLS sur les connexions du *master* vers
les *nodes* kubernetes.
Pour ces raisons principalement, la mise en oeuvre de l'approche *zero-trust*
pour hepto est repoussée.
#### VPN et mesh
Pour qu'une surcouche réseau à base de VPN soit efficace, il faut que le
trafic circule entre les nœuds sans transiter par un nœud central. Il faut
également que tous les nœuds puissent échanger avec tous les autres nœuds,
et que chacun puisse disposer d'un espace d'adressage complet pour les
applications hébergées.
Une telle infrastructure, dénommée *VPN full-mesh*, n'est pas triviale à
mettre en place. C'est en reprenant et en étendant un logiciel existant,
« wesher », que hepto parvient à gérer un *VPN full-mesh* entre l'ensemble
des nœuds garantissant la confidentialité et l'intégrité du trafic échangé,
et servant de base à la surcouche orchestration.
### Machines virtuelles, conteneurs, processus
TODO
### Stockage blocs, objets, fichiers
TODO
### Optimisations topologiques
TODO
content/docs/hepto/architecture/_index.md
+ 126
− 1
View file @ 99fe4c02
---
title: Architecture
---
\ No newline at end of file
---
## Composition d'un cluster
Un *cluster* hepto est constitué :
- d'hôtes physiques, possédés par les contributeurs au *cluster* ;
- de noeuds du cluster, chaque noeud étant instancié sur un hôte physique ;
- d'une surcouche réseau, regroupant ces noeuds sur un même réseau privé
virtuel (VPN) sécurisant les communications à suivre ;
- d'une surcouche orchestration, exploitant le CPU, la RAM et le stockage
des noeuds pour y déployer des applications et rendre des services ;
- d'une surcouche de contribution, permettant le travail collaboratif sur
les ressources du *cluster*, l'historisation des modifications, le
déploiement contrinu, etc. ;
- d'outils pré-déployés, tels que les *reverse proxy* d'accès aux services,
la gestion des certificats TLS, la supervision des ressources, la
collecte et le traitement des journaux, etc.
## Propriétés d'un cluster
### Distribué
Il est distribué, c'est à dire que les ressources sont mises à disposition
par des individus collaborant, mais pas nécessairement appartenant à la même
association, entreprise, collectif, etc. Chaque contributeur peut par exemple
disposer d'un hôte à son domicile, et décider de l'allouer pour partie à un
noeud d'un premier *cluster*, pour partie à un noeud d'un autre *cluster*, et
d'en conserver la maîtrise pour stocker ses documents personnels.
La distribution contribue à la sécurité, la vie privée, et au respect des
libertés des individus.
### Résilient
Il est résilient, c'est à dire qu'une application déployée et ses données ne
sont pas gérées sur le noeud d'un unique contributeur. En cas de panne de
courant, d'accès à Internet, de déménagement, ou simplement si le contributeur
décide subitement de déconnecter son noeud, le *cluster* continue d'exister
et les applications continuent de fonctoinner sur les autres noeuds.
La résilience n'est pas une propriété inhérente à la distribution. En
particulier, pour assurer sa résilience, le *cluster* doit contre-balancer
les difficultés imposées par la distirbution et la distance entre les noeuds.
La résilience résulte ainsi de l'équilibre atteint entre disponibilité et
cohérence des données.
### Econome
Il est économe, c'est à dire qu'il peut reposer sur des machines à faible
consommation, et que la somme des ressources peut approcher la somme des
besoins des applications, au facteur de réplication près. Egalement, la
configuration de l'orchestration tient compte de la topologie du *cluster*
et du coût -- financier et énergétique -- des communications à travers
Internet, pour les minimiser tant que possible.
## Terminologie
Un **hôte** est une machine physique, il s'agit généralement d'un ordinateur
personnel de récupération ou d'un micro-serveur. Il peut être utilisé pour
contribuer à un ou plusieurs *clusters* hepto, voire servir en parallèle
d'autres applications de son propriétaire.
Un **noeud** matérialise l'allocation de tout ou partie des ressources de
l'hôte sur lequel il repose au profit d'un *cluster* hepto. Un noeud est
concrètement constitué de deux programmes : la contribution à la surcouche
réseau et la contribution à la surcouche orchestration.
Le **cluster** hepto est réalisé par l'ensemble des noeuds qui le constituent,
il fournit les primitives réseau et d'orchestration aux applications qui
y sont hébergées.
Dans le contexte de hepto, un **pod** peut techniquement faire référence à
un *pod* Podman, technologie employée pour gérer les noeuds, ou bien un
*pod* kubernetes, technologie employée pour la couche d'orchestration.
Sauf précision, il s'agit d'un *pod* au sens kubernetes.
Un **namespace** représente un espace de nommage de la couche orchestration,
il s'agit de l'unité d'allocation des ressources dans un environnement
multi-utilisateurs.
## Technologies
Les technologies suivantes sont celles actuellement employées dans le
laboratoires hepto. Elles sont susceptibles d'évoluer régulièrement :
- les hôtes sont limités aux machines de l'architecture AMD64, avec
au minimum 1Go de mémoire vive et 50Go de stockage ;
- les noeuds sont constitués par des *pods* Podman, eux-mêmes
organisés en deux conteneurs, l'un pour la surcouche réseau, l'autre
pour la surcouche orchestration ;
- la surcouche réseau est opérée par wesher, qui négocie et conigure des
VPN Wireguard en *full-mesh* entre tous les membres du cluster ;
- la surcouche orchestration est opérée par k3s, une version allégée
de l'orchestration de conteneur kubernetes ;
- la surcouche contribution repose sur Git (par exemple un dépôt sur
une instance Gitlab) et ArgoCD, une solution de déploiement continu
conforme aux principes GitOps.
## Périmètres de responsabilités
Un *cluster* hepto est initié et géré généralement par un groupement,
nommé responsable du *cluster*. Ce groupement dispose des privilèges
d'administration du *cluster* au niveau de la surcouche d'orchestration
et dispose de l'ensemble des clés de sécurité du *cluster*, y compris
celles protégeant la surcouche réseau.
Un noeud hepto fait partie du *cluster*, et est donc sous la
responsabilité du responsable du *cluster*, de même que l'ensemble des
ressources qui y sont orchestrées, sauf délégation.
Un hôte abritant un noeud hepto est sous la responsable du propriétaire
de l'équipement. Il peut s'agit de la même entité que le responsable du
*cluster*, mais il peut également s'agit d'un individu ou d'un groupement
tiers. Par exemple, des associations peuvent mettre à disposition chacune
des hôtes pour héberger les noeuds d'un *cluster* hepto géré en fédération
d'associations ; ou bien une association gérer un *cluster* hepto reposant
pour une part sur des noeuds hébergés sur ses propres hôtes et sur des
noeuds contribués par ses membes mais dont l'association n'est pas
propriétaire.
Au sein d'un *cluster* hepto, le responsable du *cluster* peut décider
de déléguer la gestion d'un ou plusieurs *namespaces* à des tiers. Dans
ce cas, la convention de délégation précise les périmètres de responsabilité.
content/docs/hepto/architecture/administration.md
+ 3
− 0
View file @ 99fe4c02
---
title: Accès administrateur
---
\ No newline at end of file
content/docs/hepto/architecture/networking.md
+ 3
− 0
View file @ 99fe4c02
---
title: Gestion du réseau
---
\ No newline at end of file
content/docs/hepto/architecture/orchestration.md
+ 3
− 0
View file @ 99fe4c02
---
title: Orchestration
---
\ No newline at end of file
content/docs/hepto/architecture/overview.md deleted 100644 → 0
+ 0
− 129
View file @ 4c59730d
---
title: Vue générale
weight: 10
---
## Composition d'un cluster
Un *cluster* hepto est constitué :
- d'hôtes physiques, possédés par les contributeurs au *cluster* ;
- de noeuds du cluster, chaque noeud étant instancié sur un hôte physique ;
- d'une surcouche réseau, regroupant ces noeuds sur un même réseau privé
virtuel (VPN) sécurisant les communications à suivre ;
- d'une surcouche orchestration, exploitant le CPU, la RAM et le stockage
des noeuds pour y déployer des applications et rendre des services ;
- d'une surcouche de contribution, permettant le travail collaboratif sur
les ressources du *cluster*, l'historisation des modifications, le
déploiement contrinu, etc. ;
- d'outils pré-déployés, tels que les *reverse proxy* d'accès aux services,
la gestion des certificats TLS, la supervision des ressources, la
collecte et le traitement des journaux, etc.
## Propriétés d'un cluster
### Distribué
Il est distribué, c'est à dire que les ressources sont mises à disposition
par des individus collaborant, mais pas nécessairement appartenant à la même
association, entreprise, collectif, etc. Chaque contributeur peut par exemple
disposer d'un hôte à son domicile, et décider de l'allouer pour partie à un
noeud d'un premier *cluster*, pour partie à un noeud d'un autre *cluster*, et
d'en conserver la maîtrise pour stocker ses documents personnels.
La distribution contribue à la sécurité, la vie privée, et au respect des
libertés des individus.
### Résilient
Il est résilient, c'est à dire qu'une application déployée et ses données ne
sont pas gérées sur le noeud d'un unique contributeur. En cas de panne de
courant, d'accès à Internet, de déménagement, ou simplement si le contributeur
décide subitement de déconnecter son noeud, le *cluster* continue d'exister
et les applications continuent de fonctoinner sur les autres noeuds.
La résilience n'est pas une propriété inhérente à la distribution. En
particulier, pour assurer sa résilience, le *cluster* doit contre-balancer
les difficultés imposées par la distirbution et la distance entre les noeuds.
La résilience résulte ainsi de l'équilibre atteint entre disponibilité et
cohérence des données.
### Econome
Il est économe, c'est à dire qu'il peut reposer sur des machines à faible
consommation, et que la somme des ressources peut approcher la somme des
besoins des applications, au facteur de réplication près. Egalement, la
configuration de l'orchestration tient compte de la topologie du *cluster*
et du coût -- financier et énergétique -- des communications à travers
Internet, pour les minimiser tant que possible.
## Terminologie
Un **hôte** est une machine physique, il s'agit généralement d'un ordinateur
personnel de récupération ou d'un micro-serveur. Il peut être utilisé pour
contribuer à un ou plusieurs *clusters* hepto, voire servir en parallèle
d'autres applications de son propriétaire.
Un **noeud** matérialise l'allocation de tout ou partie des ressources de
l'hôte sur lequel il repose au profit d'un *cluster* hepto. Un noeud est
concrètement constitué de deux programmes : la contribution à la surcouche
réseau et la contribution à la surcouche orchestration.
Le **cluster** hepto est réalisé par l'ensemble des noeuds qui le constituent,
il fournit les primitives réseau et d'orchestration aux applications qui
y sont hébergées.
Dans le contexte de hepto, un **pod** peut techniquement faire référence à
un *pod* Podman, technologie employée pour gérer les noeuds, ou bien un
*pod* kubernetes, technologie employée pour la couche d'orchestration.
Sauf précision, il s'agit d'un *pod* au sens kubernetes.
Un **namespace** représente un espace de nommage de la couche orchestration,
il s'agit de l'unité d'allocation des ressources dans un environnement
multi-utilisateurs.
## Technologies
Les technologies suivantes sont celles actuellement employées dans le
laboratoires hepto. Elles sont susceptibles d'évoluer régulièrement :
- les hôtes sont limités aux machines de l'architecture AMD64, avec
au minimum 1Go de mémoire vive et 50Go de stockage ;
- les noeuds sont constitués par des *pods* Podman, eux-mêmes
organisés en deux conteneurs, l'un pour la surcouche réseau, l'autre
pour la surcouche orchestration ;
- la surcouche réseau est opérée par wesher, qui négocie et conigure des
VPN Wireguard en *full-mesh* entre tous les membres du cluster ;
- la surcouche orchestration est opérée par k3s, une version allégée
de l'orchestration de conteneur kubernetes ;
- la surcouche contribution repose sur Git (par exemple un dépôt sur
une instance Gitlab) et ArgoCD, une solution de déploiement continu
conforme aux principes GitOps.
## Périmètres de responsabilités
Un *cluster* hepto est initié et géré généralement par un groupement,
nommé responsable du *cluster*. Ce groupement dispose des privilèges
d'administration du *cluster* au niveau de la surcouche d'orchestration
et dispose de l'ensemble des clés de sécurité du *cluster*, y compris
celles protégeant la surcouche réseau.
Un noeud hepto fait partie du *cluster*, et est donc sous la
responsabilité du responsable du *cluster*, de même que l'ensemble des
ressources qui y sont orchestrées, sauf délégation.
Un hôte abritant un noeud hepto est sous la responsable du propriétaire
de l'équipement. Il peut s'agit de la même entité que le responsable du
*cluster*, mais il peut également s'agit d'un individu ou d'un groupement
tiers. Par exemple, des associations peuvent mettre à disposition chacune
des hôtes pour héberger les noeuds d'un *cluster* hepto géré en fédération
d'associations ; ou bien une association gérer un *cluster* hepto reposant
pour une part sur des noeuds hébergés sur ses propres hôtes et sur des
noeuds contribués par ses membes mais dont l'association n'est pas
propriétaire.
Au sein d'un *cluster* hepto, le responsable du *cluster* peut décider
de déléguer la gestion d'un ou plusieurs *namespaces* à des tiers. Dans
ce cas, la convention de délégation précise les périmètres de responsabilité.
content/docs/hepto/architecture/publication.md
+ 3
− 0
View file @ 99fe4c02
---
title: Publication de services
---
\ No newline at end of file
content/docs/hepto/architecture/storage.md
+ 3
− 0
View file @ 99fe4c02
---
title: Stockage
---
\ No newline at end of file
content/docs/hepto/stories.md deleted 100644 → 0
+ 0
− 3
View file @ 4c59730d
---
title: Exemples de déploiements
---
\ No newline at end of file
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment