Kuberian : service de recherche en langage naturel dans le code source de Kubernetes avec un LLM

[Présentation]
Kuberian = Kubernetes + Librarian
C’est un toy project développé avec l’idée d’un « bibliothécaire de Kubernetes ».

[Usage]
L’objectif est de trouver rapidement, parmi plus de 40 000 fonctions présentes dans le dépôt Kubernetes, celles qui remplissent le rôle recherché.

[Mode d’emploi]
Il suffit d’écrire en anglais une phrase qui commence de façon appropriée par that, et le service trouve la fonction la plus proche.

[Exemples de recherche]

• makes scaling decision link
  • Requête utilisée pour comprendre sur quels critères la décision d’autoscaling est prise
• checks if the system supports IPVS link
  • Requête utilisée pour trouver la fonction qui détermine si le système prend en charge IPVS
• make requests for checking readiness of the container link
  • Requête utilisée pour retrouver la fonction qui envoie les requêtes de Readiness Probe

En gros, si vous lui envoyez une phrase sous forme de proposition introduite par that, il retrouve plus ou moins la fonction la plus similaire.

[Raison de la création]
La documentation de Kubernetes est parfois formulée de manière ambiguë, ce qui oblige à aller voir le code d’implémentation. Mais vu la taille du projet, chercher manuellement à chaque fois était pénible, donc je l’ai créé.

[Stack technique]

• Llama 2
• Rust
• eui (interface utilisateur Elasticsearch)
• Knative avec Google Cloud Run

[Retour d’expérience]
Depuis que j’utilise Google Cloud Run, toutes les périodes où je me prenais la tête avec AWS Lambda me paraissent ridicules. C’est probablement l’une des technologies cloud les plus sous-estimées, et en plus le prix est étonnamment bas, donc essayez-le au moins une fois !

[roxie]

C’est un super projet ! Pourquoi ne pas essayer d’en faire la promotion ailleurs aussi, pas seulement sur GeekNews ?

Et j’aimerais aussi beaucoup en entendre davantage sur CloudRun

[kuber]

J’ai laissé mon avis sur CloudRun dans le commentaire ci-dessous. :-)

La publication a d’abord été mise en ligne sur Hacker News pour avoir un aperçu des comportements des utilisateurs, haha.
(J’utilise Google Analytics.)

Auriez-vous d’autres communautés à me recommander ? Il ne m’en vient pas vraiment beaucoup à l’esprit.

[jwseo]

Oh, c’est un projet vraiment intéressant !
Quels aspects de Google Cloud Run vous ont semblé plus satisfaisants qu’AWS Lambda ? Je n’ai utilisé que Lambda moi aussi, donc ça m’intéresse.

[kuber]

J’ai prévu d’expliquer cela plus en détail plus tard, par exemple sous forme d’article de blog, mais si l’on ne retient que quelques points simples en se limitant à l’environnement d’API HTTP :

HTTP
Lambda : il faut implémenter la logique qui reçoit les appels RPC d’API Gateway et traite les requêtes
Cloud Run : communication HTTP classique / possibilité de réutiliser tels quels les bibliothèques ou frameworks basés sur HTTP

Concurrence
Lambda : une instance ne traite de toute façon qu’une seule requête à la fois (si 100 requêtes arrivent en même temps, 100 instances doivent être lancées)
Cloud Run : une instance peut traiter plusieurs requêtes simultanément, jusqu’à la limite définie par l’utilisateur
Explication complémentaire : Cloud Run est environ 1,5 fois plus cher que Lambda à l’heure, mais si une instance autorise une concurrence de 100, cela revient à un coût d’environ 1,5/100

Cold / Warm / Hot
Lambda : en plus des états Cold et Hot, il existe un état Warm dans lequel aucune ressource CPU n’est allouée. Il devient alors très difficile d’envoyer des informations comme les données APM (car si le temps de réponse se dégrade pour les envoyer, c’est généralement perdant...). Des éléments comme les connexions DB peuvent aussi être coupés en état Warm, ou bien les ressources ne sont pas correctement libérées, ce qui peut finir par épuiser tout le pool de connexions DB
Cloud Run : seuls les états Cold et Hot existent. Malgré cela, si l’on raisonne en termes AWS, la facturation ne correspond qu’au temps de réponse d’API Gateway. Lors de l’arrêt, une opportunité de nettoyage correct des ressources est fournie

Environnement de développement
Lambda : mettre en place un environnement de développement local est très complexe, ou bien les contraintes liées à l’écosystème du langage / à l’architecture CPU sont très fortes
Cloud Run : identique à un environnement de développement classique

Portabilité
Lambda : le code écrit pour Lambda dépend de Lambda, ce qui le rend difficile à porter vers d’autres plateformes
Cloud Run : migration possible vers un environnement Kubernetes sans modification du code

Il y a encore beaucoup d’autres points, mais j’ai seulement retenu quelques éléments avec lesquels la plupart des gens pourront probablement se reconnaître haha