Page de recherche dans les notes du jardin numérique de Stéphane Klein

Recherche effectué dans :

Tous type de notes (37)

evergreen_note (23)

journal_note (14)

Filtre actif, cliquez pour en enlever un tag :

Kubernetes

Cliquez sur un tag pour affiner votre recherche :

Résultat de la recherche (37 notes) :

Cette note fait partie de la série de notes : "J'ai étudié et testé CoreOS et je suis tombé dans un rabbit hole 🙈".

Note précédente : "Fusion de CoreOS et Atomic Project en 2018".

coreos-installer

L'outil coreos-installer est un composant essentiel de Fedora CoreOS. Il propose différentes méthodes pour installer Fedora CoreOS.

La commande coreos-installer download permet de télécharger tout type de version de CoreOS, sous différents formats, par exemple iso, raw, qemu, cloud image, etc (toutes celles présentes dans la page download).

Ensuite, la commande coreos-installer install permet d'installer la version téléchargée vers un disque. Cette commande est par exemple disponible à la fin du boot d'une image ISO. Contrairement à Fedora Silverblue qui propose d'installer la distribution avec Anaconda, l'installation de CoreOS s'effectue en cli via coreos-installer install.

Ensuite, la commande coreos-installer install permet d'installer la version téléchargée sur un disque. Cette commande est notamment accessible après le démarrage d'une image ISO. Contrairement à Fedora Silverblue qui utilise l'installateur graphique Anaconda, CoreOS s'installe exclusivement en cli via coreos-installer install.

Toutefois, coreos-installer permet de préparer une installation automatique. La commande coreos-installer iso customize modifie une image ISO existante pour y intégrer directement une configuration ignition, rendant l'installation entièrement automatisée au démarrage.

Voici un exemple dans mon playground : atomic-os-playground/create-coreos-custom-iso.sh.

coreos-installer pxe permet aussi d'effectuer une configuration automatique par réseau, via PXE, mais je ne l'ai pas testé.

Graphe de migration de versions

Lors de mes tests d'upgrade de CoreOS à partir d'une ancienne release (environ n-10), j'ai constaté que la transition vers la dernière version ne se faisait pas directement mais nécessitait le passage par des versions intermédiaires.

J'ai découvert que CoreOS maintient un graphe qui définit le parcours d'upgrade requis. Certaines versions intermédiaires doivent être installées pour gérer des breaking changes, comme la migration de configurations.

zincati

Un autre composant important de Fedora CoreOS est zincati, le service responsable de l'exécution des mises à jour automatiques.

zincati décide d'effectuer les mises à jour en fonction du seuil de prudence de déploiement (rollout_wariness) et de la stratégie de mise à jour : immediate ou periodic (plage horaire définie dans la semaine).

CoreOS utilisant par défaut la stratégie immediate, zincati détecte automatiquement les nouvelles releases dès le premier démarrage et lance immédiatement leur téléchargement, suivi d'un redémarrage.

Le téléchargement par deltas rend l'upgrade vers la dernière release très rapide.

zincati permet également de coordonner les mises à jour de plusieurs serveurs, fonctionnalité particulièrement utile dans le contexte d'un cluster Kubernetes. Je n'ai pas encore testé cette fonctionnalité.

Note suivante : "composefs, un filesystem spécialement créé pour les besoins des distributions atomic".

Dans cette issue, #JaiDécouvert le projet Kairos (https://kairos.io).

Je viens de publier le "Projet 34 - "Déployer un cluster k3s et Kubevirt sous CoreOS dans mon Homelab"".

Je continue mon travail de mise à niveau en Kubernetes.

Je viens de réaliser que Helmfile ne fait pas directement partie du projet Helm. Je trouve cela surprenant. Ces deux projets sont réalisés par deux equipes différentes :

Dépôt GitHub de Helm : https://github.com/helm/helm/
- Développeurs principaux :
  - Matt Butcher basé aux États-Unis
  - Adam Reese basé aux États-Unis
Dépôt GitHub de Helmfile : https://github.com/helmfile/helmfile/
- Développeurs principaux :
  - Yusuke Kuoka basé au Japon
  - yxxhero basé en Chine

D'après ce que je comprends, si je simplifie, Helmfile est pour Helm l'équivalent de ce qu'est docker-compose.yml pour Docker.

Je m'intéresse aujourd'hui à Helmfile parce que je souhaite effectuer une tâche qui correspond au use-case numéro 2 décrit dans la documentation :

ArgoCD has support for kustomize/manifests/helm chart by itself. Why bother with Helmfile?

The reasons may vary:

1. You do want to manage applications with ArgoCD, while letting Helmfile manage infrastructure-related components like Calico/Cilium/WeaveNet, Linkerd/Istio, and ArgoCD itself.

2. You want to review the exact K8s manifests being applied on pull-request time, before ArgoCD syncs.

3. This is often better than using a kind of HelmRelease custom resources that obfuscates exactly what manifests are being applied, which makes reviewing harder.

source

Suite à cette lecture, voici comment j'ai mis en application une partie du use-case 2.

J'ai ce helmfile.yaml :

environments:
  dev:
    values:
      - version: 6.1.0
  production:
    values:
      - version: 6.1.0
---
repositories:
  - name: open-webui
    url: https://helm.openwebui.com/
---
releases:
  - name: openwebui
    namespace: {{ .Namespace }}
    chart: open-webui/open-webui
    values:
      - ./env.d/{{ .Environment.Name }}/values.yaml
    version: {{ .Values.version }}

Et ensuite, j'ai exécuté :

$ helmfile template -e dev --output-dir-template $(pwd)/gitops/{{.Release.Name}}
Adding repo open-webui https://helm.openwebui.com/
"open-webui" has been added to your repositories

Templating release=openwebui, chart=open-webui/open-webui
wrote .../gitops/openwebui/open-webui/charts/pipelines/templates/service-account.yaml
wrote .../gitops/openwebui/open-webui/templates/service-account.yaml
wrote .../gitops/openwebui/open-webui/charts/pipelines/templates/service.yaml
wrote .../gitops/openwebui/open-webui/templates/service.yaml
wrote .../gitops/openwebui/open-webui/charts/pipelines/templates/deployment.yaml
wrote .../gitops/openwebui/open-webui/templates/workload-manager.yaml
wrote .../gitops/openwebui/open-webui/templates/ingress.yaml

Cela me permet ensuite de pouvoir observer avec précision ce qui va être déployé par ArgoCD.

Alexandre m'a partagé kubectx et kubens (https://github.com/ahmetb/kubectx) :

What are kubectx and kubens?

kubectx is a tool to switch between contexts (clusters) on kubectl faster. kubens is a tool to switch between Kubernetes namespaces (and configure them for kubectl) easily.

source

#JaiDécouvert Kubebuilder (https://github.com/kubernetes-sigs/kubebuilder) (from)

Kubebuilder is a framework for building Kubernetes APIs using custom resource definitions (CRDs).

source

#JaiDécouvert Krew (https://github.com/kubernetes-sigs/krew) :

Krew is a tool that makes it easy to use kubectl plugins. Krew helps you discover plugins, install and manage them on your machine. It is similar to tools like apt, dnf or brew. Today, over 200 kubectl plugins are available on Krew.

source

#JaiDécouvert MetalLB (https://metallb.io/) :

MetalLB is a load-balancer implementation for bare metal Kubernetes clusters, using standard routing protocols.

source

#JaiDécouvert cert-manager (https://github.com/cert-manager/cert-manager)

cert-manager adds certificates and certificate issuers as resource types in Kubernetes clusters, and simplifies the process of obtaining, renewing and using those certificates.

It supports issuing certificates from a variety of sources, including Let's Encrypt (ACME), HashiCorp Vault, and Venafi TPP / TLS Protect Cloud, as well as local in-cluster issuance.

source

J'ai commencé à utiliser Kubernetes pour la première fois en janvier 2016. C'était dans un cadre professionnel, quand je travaillais chez Tech-Angels / Gemnasium.

Mes deux premiers projets étaient les suivants :

Opérer et continuer à améliorer un cluster de 3 nodes basé sur OpenShift (surcouche Kubernetes de Red Hat) qui permettait d'héberger les services web de nos clients.
L'objectif était de fournir un service un peu comme Heroku, c'est-à-dire permettre un déploiement via un simple "git push".
Avec le recul, l'objectif ressemblait à ce que propose actuellement Clever Cloud.
Implémenter une version OnPremise de Gemnasium propulsée par Kubernetes.

En janvier 2016, Kubernetes était un projet très jeune, avec seulement 20 mois d'existence depuis la sortie de la première version 0.2. L'écosystème était bien plus petit que maintenant. Par exemple, Helm n'était pas encore populaire.

J'ai commencé par installer la version 1.1 de Kubernetes avec les playbooks officiels Ansible.

Ce fut une expérience difficile, avec de nombreux crashs de clusters, tout particulièrement lors des montées en version.
L'expérience fut très enrichissante. Cela m'a permis de monter en compétence avec Docker, Kubernetes, Ceph…

J'ai ensuite utilisé Kubernetes de novembre 2018 à avril 2019, dans la team Kubernetes Kapsule de Scaleway.

La mission de cette équipe était de créer un produit qui permettait de déployer des clusters Kubernetes managés.

Je suis arrivé dans cette équipe 10 mois après le début du projet. J'ai contribué au projet pendant 5 mois, jusqu'au lancement du produit en production.

Cette fois encore, une partie du travail était de déployer des clusters Kubernetes from "scatch".

Expérience intéressante : j'ai appris à déployer des clusters Kubernetes via Kubernetes !
L'implémentation était inspirée de la méthode présentée dans cet article : Gardener - The Kubernetes Botanist.

Depuis avril 2019, je n'ai plus opéré de cluster Kubernetes. J'ai seulement continué à suivre de loin les actualités de cet écosystème. Je n'ai plus eu d'expérience pratique.

Maintenant que j'ai rejoint une mission dont le produit est déployé sur Kubernetes, je souhaite mettre à jour mes compétences pratiques dans ce domaine.

Voici quelques sujets sur lesquels je souhaite monter en compétence ces prochains mois :

M'entrainement à utiliser et à créer des Helm Charts
Déployer un ArgoCD pour apprendre à bien l'utiliser
Jouer avec k3s
Tester Postgres Operator
Étudier et tester https://tilt.dev/
kind (https://kind.sigs.k8s.io/)
Grafana Tanka
kustomize (https://github.com/kubernetes-sigs/kustomize)

#JaiDécouvert Cloud Pi Native (https://github.com/cloud-pi-native)

Alexandre m'a partagé le projet Postgres Operator, que j'avais peut-être croisé par le passé, mais que j'avais oublié.

Postgres Operator permet entre autres de déployer des instances PostgreSQL dans un cluster Kubernetes mais aussi de mettre en place des systèmes de backup logique et backup binaire.

Début novembre un ami me posait la question :

Quand tu déploies des conteneurs en prod, sans k8s, tu fais comment ?

Après 3 mois d'attente, voici ma réponse 🙂.

Mon contexte

Tout d'abord, un peu de contexte. Cela fait 25 ans que je travaille sur des projets web, et tous les projets sur lesquels j'ai travaillé pouvaient être hébergés sur un seul et unique serveur baremetal ou une Virtual machine, sans jamais nécessiter de scalabilité horizontale.

Je n'ai jamais eu besoin de serveurs avec plus de 96Go de RAM pour faire tourner un service en production. Il convient de noter que, dans 80% des cas, 8 Go ou 16 Go étaient largement suffisants.

Cela dit, j'ai également eu à gérer des infrastructures comportant plusieurs serveurs : 10, 20, 30 serveurs. Ces serveurs étaient généralement utilisés pour héberger une infrastructure de soutien (Platform infrastructure) à destination des développeurs. Par exemple :

Environnements de recettage
Serveurs pour faire tourner Gitlab-Runner
Sauvegarde des données
Etc.

Ce contexte montre que je n'ai jamais eu à gérer le déploiement de services à très forte charge, comme ceux que l'on trouve sur des plateformes telles que Deezer, le site des impôts, Radio France, Meetic, la Fnac, Cdiscount, France Travail, Blablacar, ou encore Doctolib. La méthode que je décris dans cette note ne concerne pas ce type d'infrastructure.

Ma méthode depuis 2015

Dans cette note, je ne vais pas retracer l'évolution complète de mes méthodes de déploiement, mais plutôt me concentrer sur deux d'entre elles : l'une que j'utilise depuis 2015, et une déclinaison adoptée en 2020.

Voici les principes que j'essaie de suivre et qui constituent le socle de ma doctrine en matière de déploiement de services :

Je m'efforce de suivre le modèle Baking autant que possible (voir ma note 2025-02-07_1403), sans en faire une approche dogmatique ou extrémiste.
J'applique les principes de The Twelve-Factors App.
Je privilégie le paradigme Remote Task Execution, ce qui me permet d'adopter une approche GitOps.
J'utilise des outils d'orchestration prenant en charge le mode push (voir note 2025-02-07_1612), comme Ansible, et j'évite le mode pull.

En pratique, j'utilise Ansible pour déployer un fichier docker-compose.yml sur le serveur de production et ensuite lancer les services.

Je précise que cette note ne traite pas de la préparation préalable du serveur, de l'installation de Docker, ni d'autres aspects similaires. Afin de ne pas alourdir davantage cette note, je n'aborde pas non plus les questions de Continuous Integration ou de Continuous Delivery.

Imaginons que je souhaite déployer le lecteur RSS Miniflux connecté à un serveur PostgreSQL.
Voici les opérations effectuées par le rôle Ansible à distance sur le serveur de production :

1. Création d'un dossier /srv/miniflux/
1. Upload de /srv/miniflux/docker-compose.yml avec le contenu suivant :

services:
  postgres:
    image: postgres:17
    restart: unless-stopped
    environment:
      POSTGRES_DB: miniflux
      POSTGRES_USER: miniflux
      POSTGRES_PASSWORD: password
    volumes:
      - postgres:/var/lib/postgresql/data/
    healthcheck:
      test: ['CMD', 'pg_isready']
      interval: 10s
      start_period: 30s

  miniflux:
    image: miniflux/miniflux:2.2.5
    ports:
    - 8080:8080
    environment:
      DATABASE_URL: postgres://miniflux:password@postgres/miniflux?sslmode=disable
      RUN_MIGRATIONS: 1
      CREATE_ADMIN: 1
      ADMIN_USERNAME: johndoe
      ADMIN_PASSWORD: secret
    healthcheck:
      test: ["CMD", "/usr/bin/miniflux", "-healthcheck", "auto"]
    depends_on:
      postgres:
        condition: service_healthy

volumes:
  postgres:
     name: miniflux_postgres

1. Depuis le dossier /srv/miniflux/ lancement de la commande docker compose up -d --remove-orphans --wait --pull always

Voilà, c'est tout 🙂.

En 2020, j'enlève "une couche"

J'aime enlever des couches et en 2020, je me suis demandé si je pouvais pratiquer avec élégance la méthode Remote Execution sans Ansible.
Mon objectif était d'utiliser seulement ssh et un soupçon de Bash.

Voici le résultat de mes expérimentations.

J'ai besoin de deux fichiers.

_payload_deploy_miniflux.sh
deploy_miniflux.sh

Voici le contenu de _payload_deploy_miniflux.sh :

#!/usr/bin/env bash
set -e

PROJECT_FOLDER="/srv/miniflux/"

mkdir -p ${PROJECT_FOLDER}

cat <<EOF > ${PROJECT_FOLDER}docker-compose.yaml
services:
  postgres:
    image: postgres:17
    restart: unless-stopped
    environment:
      POSTGRES_DB: miniflux
      POSTGRES_USER: miniflux
      POSTGRES_PASSWORD: {{ .Env.MINIFLUX_POSTGRES_PASSWORD }}
    volumes:
      - postgres:/var/lib/postgresql/data/
    healthcheck:
      test: ['CMD', 'pg_isready']
      interval: 10s
      start_period: 30s

  miniflux:
    image: miniflux/miniflux:2.2.5
    ports:
    - 8080:8080
    environment:
      DATABASE_URL: postgres://miniflux:{{ .Env.MINIFLUX_POSTGRES_PASSWORD }}@postgres/miniflux?sslmode=disable
      RUN_MIGRATIONS: 1
      CREATE_ADMIN: 1
      ADMIN_USERNAME: johndoe
      ADMIN_PASSWORD: {{ .Env.MINIFLUX_ADMIN_PASSWORD }}
    healthcheck:
      test: ["CMD", "/usr/bin/miniflux", "-healthcheck", "auto"]
    depends_on:
      postgres:
        condition: service_healthy

volumes:
  postgres:
     name: miniflux_postgres

EOF

cd ${PROJECT_FOLDER}

docker compose pull
docker compose up -d --remove-orphans --wait

Voici le contenu de deploy_miniflux.sh :

#!/usr/bin/env bash
set -e

cd "$(dirname "$0")/../"

gomplate -f _payload_deploy_miniflux.sh | ssh root@$SERVER1_IP 'bash -s'

J'utilise gomplate pour remplacer dynamiquement les secrets dans le script _payload_deploy_miniflux.sh.

En conclusion, pour déployer une nouvelle version, j'ai juste à exécuter :

$ ./deploy_miniflux.sh

Je trouve cela minimaliste et de plus, l'exécution est bien plus rapide que la solution Ansible.

Ce type de script peut ensuite être exécuté aussi bien manuellement par un développeur depuis sa workstation, que via GitLab-CI ou même Rundeck.

Pour un exemple plus détaillé, consultez ce repository : https://github.com/stephane-klein/poc-bash-ssh-docker-deployement-example

Bien entendu, si vous souhaitez déployer votre propre application que vous développez, vous devez ajouter à cela la partie baking, c'est-à-dire, le docker build qui prépare votre image, l'uploader sur un Docker registry… Généralement je réalise cela avec GitLab-CI/CD ou GitHub Actions.

Objections

Certains DevOps me disent :

« Mais on ne fait pas ça pour de la production ! Il faut utiliser Kubernetes ! »
« Comment ! Tu n'utilises pas Kubernetes ? »

Et d'autres :

« Il ne faut au grand jamais utiliser docker-compose en production ! »

Ne jamais utiliser docker compose en production ?

J'ai reçu cette objection en 2018. J'ai essayé de comprendre les raisons qui justifiaient que ce développeur considère l'usage de docker compose en production comme un Antipattern.

Si mes souvenirs sont bons, je me souviens que pour lui, la bonne méthode conscistait à déclarer les états des containers à déployer avec le module Ansible docker_container (le lien est vers la version de 2018, depuis ce module s'est grandement amélioré).

Je n'ai pas eu plus d'explications 🙁.

J'ai essayé d'imaginer ses motivations.

J'en ai trouvé une que je ne trouve pas très pertinente :

Uplodaer un fichier docker-compose.yml en production pour ensuite lancer des fonctions distantes sur celui-ci est moins performant que manipuler docker-engine à distance.

J'en ai imaginé une valable :

En déclarant la configuration de services Docker uniquement dans le rôle Ansible cela garantit qu'aucun développeur n'ira modifier et manipuler directement le fichier docker-compose.yml sur le serveur de production.

Je trouve que c'est un très bon argument 👍️.

Cependant, cette méthode a à mes yeux les inconvénients suivants :

Je maitrise bien mieux la syntaxe de docker compose que la syntaxe du module Ansible community.docker.docker_container
J'utilise docker compose au quotidien sur ma workstation et je n'ai pas envie d'apprendre une syntaxe supplémentaire uniquement pour le déploiement.
Je pense que le nombre de développeurs qui maîtrisent docker compose est suppérieur au nombre de ceux qui maîtrisent le module Ansible community.docker.docker_container.
Je ne suis pas utilisateur maximaliste de la méthode Remote Execution. Dans certaines circonstances, je trouve très pratique de pouvoir manipuler docker compose dans une session ssh directement sur un serveur. En période de stress ou de debug compliqué, je trouve cela pratique. J'essaie d'être assez rigoureux pour ne pas oublier de reporter mes changements effectués directement le serveur dans les scripts de déploiements (configuration as code).

Tu dois utiliser Kubernetes !

Alors oui, il y a une multitude de raisons valables d'utiliser Kubernetes. C'est une technologie très puissante, je n'ai pas le moindre doute à ce sujet.
J'ai une expérience dans ce domaine, ayant utilisé Kubernetes presque quotidiennement dans un cadre professionnel de janvier 2016 à septembre 2017. J'ai administré un petit cluster auto-managé composé de quelques nœuds et y ai déployé diverses applications.

Ceci étant dit, je rappelle mon contexte :

Cela fait 25 ans que je travaille sur des projets web, et tous les projets sur lesquels j'ai travaillé pouvaient être hébergés sur un seul et unique serveur baremetal ou une Virtual machine, sans jamais nécessiter de scalabilité horizontale.

Je n'ai jamais eu besoin de serveurs avec plus de 96Go de RAM pour faire tourner un service en production. Il convient de noter que, dans 80% des cas, 8 Go ou 16 Go étaient largement suffisants.

Je pense que faire appel à Kubernetes dans ce contexte est de l'overengineering.

Je dois avouer que j'envisage d'expérimenter un usage minimaliste de K3s (attention au "3", je n'ai pas écrit k8s) pour mes déploiements. Mais je sais que Kubernetes est un rabbit hole : Helm, Kustomize, Istio, Helmfile, Grafana Tanka… J'ai peur de tomber dans un Yak!.

D'autre part, il existe déjà un pourcentage non négligeable de développeur qui ne maitrise ni Docker, ni docker compose et dans ces conditions, faire le choix de Kubernetes augmenterait encore plus la barrière à l'entrée permettant à des collègues de pouvoir comprendre et intervenir sur les serveurs d'hébergement.

C'est pour cela que ma doctrine d'artisan développeur consiste à utiliser Kubernetes seulement à partir du moment où je rencontre des besoins de forte charge, de scalabilité.

#JaiDécouvert Flagger et Argo Rollouts.

#JaiDécouvert Karpenter (from).

Alexandre m'a partagé le projet Grafana Tanka.

Flexible, reusable and concise configuration for Kubernetes.

Je découvre ce thread Hacker News que je n'ai pas pris le temps de lire : Tanka: Our way of deploying to Kubernetes.

#JaiLu Why not Helm?.

En cherchant des informations au sujet de l'origine de la fonctionnalité compose watch, #JaiDécouvert Tilt (from).

https://karpenter.sh/

Define your dev environment as code. For microservice apps on Kubernetes.

https://github.com/tilt-dev/tilt

Site officiel : https://kustomize.io/

Dépôt GitHub : https://github.com/helmfile/helmfile

Flexible, reusable and concise configuration for Kubernetes.

https://github.com/grafana/tanka

Dépôt GitHub : https://github.com/zalando/postgres-operator

Organisation GitHub : https://github.com/cloud-pi-native

L'offre Cloud Pi Native

La direction de la transformation numérique du ministère de l'Intérieur et des outre-mer propose une offre de services autour de deux instances de la plateforme (OVH SecNumCloud / Cloud π) à destination des administrations ou des entreprises de services numériques travaillant pour leur compte.

source

Article Wikipedia anglais : https://en.wikipedia.org/wiki/Kubernetes

Page officielle : https://www.scaleway.com/en/kubernetes-kapsule/

Site officiel : https://helm.sh/

Documentation : https://kind.sigs.k8s.io/

Dépôt GitHub : https://github.com/cert-manager/cert-manager

https://metallb.io/

Dépôt GitHub : https://github.com/kubernetes-sigs/krew

Dépôt GitHub : https://github.com/kubernetes-sigs/kubebuilder

Site officiel : https://github.com/kubernetes-sigs/kubebuilder

Dépôt GitHub : https://github.com/ahmetb/kubectx

Compte GitHub : https://github.com/mumoshu

Page LinkedIn : https://www.linkedin.com/in/ykuoka/

Un développeur de Helmfile.

Page LinkedIn : https://www.linkedin.com/in/mattbutcher/

Page GitHub : https://github.com/technosophos

Développeur créateur de Helm.

Page GitHub : https://github.com/adamreese

Page Linkedin : https://www.linkedin.com/in/adamreeselinked/

Un développeur de Helm.

Compte GitHub : https://github.com/yxxhero

Un développeur de Helmfile.

Date de la création de cette note : 2025-04-25 .

Quel est l'objectif de ce projet ?

Ce projet est la suite du Projet 28. Le but est de créer un dépôt GitHub playground d'installation d'Open WebUI chez Scaleway, sur un k8s, en utilisant Open WebUI Helm Charts.

Quelques précisions sur l'objectif :

[ ] Utiliser le Kubernetes managé de Scaleway : Kubernetes Kapsule
[ ] Connecter Open WebUI à Scaleway Generative APIs
[ ] Connecter Open WebUI à un Object Storage (voir)
[ ] Setup Redis Websocket Support
[ ] Connecter Open WebUI à un PostgreSQL (voir)
[ ] Déployer Open WebUI sur 3 nodes Kubernetes différents

Autres projets en lien avec celui-ci

Pourquoi je souhaite réaliser ce projet ?

J'ai commencé une mission liée à Open WebUI, service qui est déployé sur un cluster Kubernetes avec ArgoCD.

Je souhaite mieux comprendre le projet Open WebUI et remettre à niveau mon expérience pratique en Kubernetes.

Repository de ce projet :

https://github.com/stephane-klein/open-webui-k8s-deployment-playground/ (travail en cours dans la branche wip)

Ressources :

https://github.com/open-webui/helm-charts

Date de la création de cette note : 2025-09-22.

Quel est l'objectif de ce projet ?

Ce projet est de type "macro", une Epic, qui sera probablement découpé en plusieurs sous-projets.

Je veux déployer sur les serveurs de mon Homelab :

le système d'exploitation Linux Fedora CoreOS stable
LUKS encryption + boot automatique avec clevis et TPM2
un cluster k3s
dans ce cluster K3s, installer :
- KubeVirt
  - installer Jellyfin dans une VM sous KubeVirt
    - donner à cette VM un accès direct au moniteur
- Installer le VPN headscale
Permettre l'accès à des services :
- soit directement via une IPv4 publique
- soit via une IPv6 publique
- soit via le VPN

J'envisage peut être d'installer le tout via un serveur PXE déployé sur ma workstation Fedora.

Pourquoi je souhaite réaliser ce projet ?

Pour le plaisir, j'ai envie de tester KubeVirt à la place de Proxmox.

J'ai envie d'apprendre à utiliser et idéalement de maîtriser les OS immutables comme Fedora Silverblue ou CoreOS.

J'ai envie de tester k3s et headscale.

Dernière page.