Avril 2025, quelle est mon expérience Kubernetes ?

Journal du vendredi 25 avril 2025 à 17:50

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 :

Journaux liées à cette note :

Journal du jeudi 01 mai 2025 à 16:22 #Kubernetes, #DevOps, #JaiDécouvert

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