Roadmap de migrations de services vers Kubernetes #6

New issue

Open

opened 2026-08-01 23:41:39 +02:00 by jad · 1 comment

jad commented

2026-08-01 23:41:39 +02:00

Owner

Il s'agit de planifier la migration de nos services vers Kubernetes en privilégiant les services les plus isolés et donc les moins risqués à migrer.

Il y a plusieurs points de frictions auxquels réfléchir:

Les routes sur notre ingress sont déclarées dans un Caddyfile, tandis que sur Kubernetes ça devra se faire à l'aide d'un Custom Resource Declaration (CRD) pour chaque service, qui fait référence à une ingress déclaré séparément.
La topologie network des conteneurs est plutôt convoluted sur nos manifestes Quadlets actuellement, avec un network dédié pour donner accès à Internet à des conteneurs, et un autre qui permet à Caddy, l'ingress, de router le traffic, ainsi que les networks privés de chaque service entre ses conteneurs.
- Avec les nomenclatures de conteneurs rassemblés en pods, la gestion des networks privés disparaitraient.
- Les routes networks explicites entre ingress et service devraient aussi disparaître et être provisionnés automatiquement quand on déclare les routes.
Le stockage ZFS d'Anastasia devra être mis à disposition aux services Kubernetes à travers un Container Storage Interface (CSI) driver.
- Ce driver se chargera probablement d'exposer automatiquement les datasets demandés par ZFS.

Il s'agit de planifier la migration de nos services vers Kubernetes en privilégiant les services les plus isolés et donc les moins risqués à migrer. Il y a plusieurs points de frictions auxquels réfléchir: - Les routes sur notre ingress sont déclarées dans un `Caddyfile`, tandis que sur Kubernetes ça devra se faire à l'aide d'un Custom Resource Declaration (CRD) pour chaque service, qui fait référence à une ingress déclaré séparément. - La topologie network des conteneurs est plutôt convoluted sur nos manifestes Quadlets actuellement, avec un network dédié pour donner accès à Internet à des conteneurs, et un autre qui permet à Caddy, l'ingress, de router le traffic, ainsi que les networks privés de chaque service entre ses conteneurs. - Avec les nomenclatures de conteneurs rassemblés en pods, la gestion des networks privés disparaitraient. - Les routes networks explicites entre ingress et service devraient aussi disparaître et être provisionnés automatiquement quand on déclare les routes. - Le stockage ZFS d'Anastasia devra être mis à disposition aux services Kubernetes à travers un Container Storage Interface (CSI) driver. - Ce driver se chargera probablement d'exposer automatiquement les datasets demandés par ZFS.

jad added this to the Migration vers Kubernetes milestone

2026-08-01 23:41:39 +02:00

jad added the

work

plan

label

2026-08-01 23:41:39 +02:00

jad added this to the Borealis Operations project

2026-08-01 23:41:45 +02:00

jad self-assigned this

2026-08-01 23:41:46 +02:00

jad commented

2026-08-05 21:37:15 +02:00

Author

Owner

Voici d'autres points qui me sont venus en tête:

On pourrait migrer progressivement les services vers le cluster Kubernetes, tout en exposant sa gateway à la gateway Caddy actuelle sur Anastasia.
- Caddy routerait progressivement les services vers Kubernetes à mesure qu'on les migre là bas.
- Quand la migration est terminée, il ne reste qu'à mettre la gateway Kubernetes en face à la place de Caddy.
La gestion de la politique de stockage resterait locale à Anastasia à travers zrepl. Le CSI se charge seulement de permettre l'accès au datasets à n'importe quel node sur le cluster qui a des pods qui en ont besoin.
La GitOps à l'aide de Flux CD permettrait de recenser nos déploiements sur le cluster.
On pourrait mettre en place OIDC avec PocketID pour permettre une interface au cluster avec RBAC (seulement avec VPN pour pouvoir auditer sérieusement les machines sur le réseau).
- Ça permettrait à des personnes familières avec les lignes de commandes et les déploiements comme Antoine et moi de déployer des services sans avoir besoin de SSH.
- Ça ouvrirait la porte pour développer un service qui permette à des personnes pas tech-savvy de déployer facilement leur instance d'un service (Synapse (Matrix), AT Proto PDS, Serveur mail etc.)

Voici d'autres points qui me sont venus en tête: - On pourrait migrer progressivement les services vers le cluster Kubernetes, tout en exposant sa gateway à la gateway Caddy actuelle sur Anastasia. - Caddy routerait progressivement les services vers Kubernetes à mesure qu'on les migre là bas. - Quand la migration est terminée, il ne reste qu'à mettre la gateway Kubernetes en face à la place de Caddy. - La gestion de la politique de stockage resterait locale à Anastasia à travers [zrepl](https://zrepl.github.io). Le CSI se charge seulement de permettre l'accès au datasets à n'importe quel node sur le cluster qui a des pods qui en ont besoin. - La GitOps à l'aide de [Flux CD](https://fluxcd.io/) permettrait de recenser nos déploiements sur le cluster. - On pourrait mettre en place OIDC avec PocketID pour permettre une interface au cluster avec RBAC (seulement avec VPN pour pouvoir auditer sérieusement les machines sur le réseau). - Ça permettrait à des personnes familières avec les lignes de commandes et les déploiements comme Antoine et moi de déployer des services sans avoir besoin de SSH. - Ça ouvrirait la porte pour développer un service qui permette à des personnes pas tech-savvy de déployer facilement leur instance d'un service (Synapse (Matrix), AT Proto PDS, Serveur mail etc.)