Anthony's Blog
Pluto : contrôler les versions d'API Kubernetes obsolètes de son projet

Pluto : contrôler les versions d'API Kubernetes obsolètes de son projet

Anthony DASSÉ's photo
Anthony DASSÉ
·

3 min read

Kubernetes et ses ressources sous-jacentes évoluent rapidement, ce qui peut impacter vos déploiements.

En effet, après une mise à jour de Kubernetes, certaines API de ressources peuvent devenir "obsolètes" ou même être complètement supprimées. Une méthode simple consiste à tester un nouveau déploiement de ces ressources sur le cluster pour voir le résultat... mais ce n'est pas l’idéal.

Il serait plus judicieux d'anticiper et de recevoir un avertissement bien à l'avance pour intégrer le changement de version d'API dans la planification de votre projet. C'est là qu'intervient Pluto.

C’est quoi Pluto ?

Pluto est un utilitaire permettant aux utilisateurs de trouver les versions d'API Kubernetes obsolètes dans leurs référentiels de code (template K8S, Helm) ou sur un cluster directement.

Ses avantages :

  1. Détecter des API Dépréciées : Pluto permet de trouver les versions d'API Kubernetes qui ont été dépréciées, ce qui est crucial pour maintenir la compatibilité avec les nouvelles versions de Kubernetes.

  2. Préparer des mises à jour : En identifiant les API dépréciées, Pluto aide les équipes à préparer leurs applications pour les mises à jour de Kubernetes, évitant ainsi les interruptions de service.

  3. S’intégrer dans le CI/CD : Pluto peut être intégré dans les pipelines CI/CD pour automatiser la détection des API dépréciées, garantissant ainsi que le code reste à jour.

Fonctionnement de Pluto

  1. Analyse des Fichiers : Pluto peut analyser les fichiers de manifestes Kubernetes et les charts Helm pour détecter les versions d'API dépréciées. C’est mon utilisation principale avec Helm (avec l’aide de la commande Helm : https://helm.sh/docs/helm/helm_template/ ).

  2. Analyse en Cluster : Il peut également analyser les ressources déployées dans un cluster Kubernetes pour identifier les API dépréciées.

Vous pouvez retrouver la documentation de l’outil ici https://pluto.docs.fairwinds.com/installation/#installation (installation et usage).

Démonstration avec un exemple

Dans un dossier templates, j’ai un template yaml représentant une ressource Ingress (une veille version, mais c’est pour l’exemple).

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: minimal-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  ingressClassName: nginx-example
  rules:
  - http:
      paths:
      - path: /testpath
        pathType: Prefix
        backend:
          service:
            name: test
            port:
              number: 80

Ici ce qui nous intéresse c’est l’apiVersion qui est : networking.k8s.io/v1beta1.

J’ai la possibilité de lancer pluto sur mon répertoire contenant mes manifestes Kubernetes en spécifiant que le cluster cible est en version 1.21.

./pluto detect-files --target-versions k8s=v1.21.0 -d templates/

Je vois que la version de mon API Ingress est dépréciée mais pas encore supprimée … bon là normalement vous rajoutez un tâche pour réaliser la migration.

Un peu tête en l’air, vous oubliez de le faire … hop quelques mois après, l’équipe d’infrastructure parle d’une migration en version 1.22 … et si nous testions avec cette version ?

./pluto detect-files --target-versions k8s=v1.22.0 -d templates/

Ici nous voyons sur l’API sera supprimée lors du passage en 1.22 … ce qui posera des soucis lors de nos futurs déploiements et donc lors de futurs mise en production.

Et dans la pratique ?

Je préconise de rajouter cet outil dans votre chaine d’intégration continue sur la phase de tests.

Généralement, je rajoute les versions Kubernetes cibles, ‘versions’ au pluriel car généralement le cycle de vie des mises à jours des clusters fonctionne de la sorte : update d’un environnement hors production > update d’un environnement de production.

Je me retrouve donc avec deux variables (Gitlab par exemple) :

  • K8S_TARGET_VERSION_HPROD

  • K8S_TARGET_VERSION_PROD

Je mets en place deux jobs pour tester (un job par environnement) les templates yaml de mes déploiements.

De même, l’utilitaire retourne un code retour de 0 si tout se passe bien, et des valeurs 1 à 4 en cas d’erreurs (👉https://pluto.docs.fairwinds.com/advanced/#ci-pipelines). Vous pouvez donc utiliser ce code pour rendre bloquant le job dans votre CI/CD.

Et ultime tips, on peut aussi générer un rapport en Markdown (https://pluto.docs.fairwinds.com/advanced/#ci-pipelines) ce qui permet d’avoir un fichier lisible à utiliser.

Kubernetestoolsci-cd