Kuberian: Natürlichsprachlicher Suchdienst für Kubernetes-Quellcode mit LLMs

[Einführung]
Kuberian = Kubernetes + Librarian
Dies ist ein Toy-Projekt, das ich mit dem Gefühl eines „Kubernetes-Bibliothekars“ entwickelt habe.

[Zweck]
Ziel ist es, unter den mehr als 40.000 Funktionen im Kubernetes-Repository
schnell die Funktion zu finden, die genau die gewünschte Aufgabe erfüllt.

[Verwendung]
Wenn man auf Englisch einen passend formulierten Satz schreibt, der mit that beginnt, findet der Dienst die ähnlichste Funktion.

[Suchbeispiele]

• makes scaling decision link
  • Query, die verwendet wurde, um herauszufinden, nach welchen Kriterien über Autoscaling entschieden wird
• checks if the system supports IPVS link
  • Query, die verwendet wurde, um die Funktion zu finden, die prüft, ob das System IPVS unterstützt
• make requests for checking readiness of the container link
  • Query, die verwendet wurde, um die Funktion zu finden, die Readiness-Probe-Requests ausführt

Wenn man grob einen Satz mit einem that-Nebensatz eingibt, findet der Dienst ziemlich passend die ähnlichste Funktion.

[Warum ich das gebaut habe]
Die Kubernetes-Dokumentation ist manchmal etwas vage formuliert, sodass man im Implementierungscode nachsehen muss. Bei einem Projekt dieser Größe war es mir aber zu mühsam, alles einzeln manuell zu suchen, also habe ich das gebaut.

[Tech-Stack]

• Llama 2
• Rust
• eui (Elasticsearch UI)
• Knative w/ Google Cloud Run

[Fazit]
Seit ich Google Cloud Run benutze, kommen mir die Zeiten, in denen ich mit AWS Lambda herumüberlegt habe, ziemlich albern vor. Für mich ist das eine der am meisten unterschätzten Cloud-Technologien, und dazu auch noch erstaunlich günstig — unbedingt mal ausprobieren!

[roxie]

Tolles Projekt! Wie wäre es, wenn Sie es nicht nur auf GeekNews, sondern auch anderswo bewerben?

Und ich würde auch gern mehr über Ihre Gedanken zu CloudRun hören

[kuber]

Meine Meinung zu CloudRun habe ich im Kommentar unten hinterlassen. :-)

Für Hacker News habe ich es vorab veröffentlicht, um einen ersten Eindruck vom Nutzerverhalten zu bekommen, haha.
(Ich nutze Google Analytics.)

Gibt es vielleicht noch andere Communities, die ihr empfehlen würdet? Mir fallen ehrlich gesagt nicht besonders viele ein.

[jwseo]

Oh, das ist ja ein spannendes Projekt!
In welchen Punkten war Google Cloud Run im Vergleich zu AWS Lambda für euch zufriedenstellender? Ich habe bisher auch nur Lambda genutzt und bin neugierig.

[kuber]

Ich plane, das später in Form eines Blogposts o. Ä. ausführlicher darzulegen, aber wenn wir uns auf die HTTP-API-Umgebung beschränken und nur ein paar Punkte herausgreifen, dann etwa diese:

HTTP
Lambda: Man muss die Logik implementieren, die RPC-Aufrufe von API Gateway entgegennimmt und die Anfragen verarbeitet.
Cloud Run: Normale HTTP-Kommunikation / HTTP-basierte Bibliotheken oder Frameworks können unverändert genutzt werden.

Concurrency
Lambda: Eine einzelne Instanz verarbeitet grundsätzlich immer nur eine Anfrage gleichzeitig. (Wenn 100 Anfragen gleichzeitig eingehen, müssen 100 Instanzen laufen.)
Cloud Run: Eine einzelne Instanz kann gleichzeitig bis zu der vom Nutzer festgelegten Grenze verarbeiten.
Zusätzliche Erläuterung: Cloud Run ist im Vergleich zu Lambda pro Stunde zwar etwa 1,5-mal teurer, aber wenn eine einzelne Instanz 100 gleichzeitige Anfragen zulässt, wird es um etwa den Faktor 1,5/100 günstiger.

Cold / Warm / Hot
Lambda: Neben Cold und Hot gibt es auch einen Warm-Zustand, in dem keine CPU-Ressourcen zugeteilt werden. Dadurch wird es sehr schwierig, Dinge wie APM-Informationen zu senden. (Wenn sich die Antwortzeit verzögert, nur um APM-Informationen zu senden, ist das in der Regel ein Nachteil …) Auch Dinge wie DB-Verbindungen können im Warm-Zustand getrennt werden oder Ressourcen werden nicht sauber freigegeben, sodass am Ende der gesamte DB Connection Pool aufgebraucht wird.
Cloud Run: Es gibt nur Cold und Hot. Trotzdem wird, in AWS-Begriffen gesprochen, nur in Höhe der Antwortzeit von API Gateway abgerechnet. Beim Beenden bekommt man außerdem die Gelegenheit zu einer ordentlichen Ressourcenbereinigung.

Entwicklungsumgebung
Lambda: Es ist sehr umständlich, lokal eine Entwicklungsumgebung aufzubauen, oder die Einschränkungen durch das Sprach-Ökosystem / die CPU-Architektur sind sehr groß.
Cloud Run: Entspricht einer normalen Entwicklungsumgebung.

Portabilität
Lambda: Für Lambda geschriebener Code ist an Lambda gebunden und daher schwer auf andere Plattformen portierbar.
Cloud Run: Kann ohne Codeänderungen in eine Kubernetes-Umgebung migriert werden.

Es gibt noch viel mehr, aber ich habe nur ein paar Punkte herausgegriffen, bei denen die meisten wahrscheinlich zustimmen würden, haha.