Erfahrungen als LFX-Mentee bei Chaos Mesh
Diese Seite wurde von PageTurner AI übersetzt (Beta). Nicht offiziell vom Projekt unterstützt. Fehler gefunden? Problem melden →
Ich bin Masterstudent der Softwaretechnik an der Nanjing University und forsche im Bereich DevOps, das intrinsische Verbindungen zu Chaos Engineering und Observability aufweist. Um mich in die Open-Source-Community einzubringen, Kubernetes tiefer zu verstehen und die tägliche Infrastrukturarbeit kennenzulernen, bewarb ich mich für das CNCF LFX Mentorship im Herbst 2021, um am Chaos Mesh-Projekt mitzuwirken.
Bewerbungsprozess
Ende August beendete ich ein kaufmännisches Praktikum. Wie erwartet, merkte ich, dass mich geschäftsorientierte Arbeit nicht sonderlich reizt. Doch meine Leidenschaft für Infrastrukturtechnologien blieb ungebrochen. Zufällig entdeckte ich das Chaos-Mesh-Projekt im CNCF LFX Mentorship. Ich sah darin eine perfekte Gelegenheit, an einem Open-Source-Projekt mitzuarbeiten – ein langgehegter Traum. Da ich auch über den passenden Tech-Stack verfügte, reichte ich meinen Lebenslauf kurz vor Fristende ein.
Drei Tage später erhielt ich eine Interview-Einladung meines Mentors. Als Teil des Auswahlverfahrens bekam ich eine kleine Aufgabe: einen Mini-Node-Exporter zu entwickeln, der Prometheus-Metriken bereitstellt und in einem Grafana-Dashboard visualisiert. Zudem sollte ich den Exporter mit konfiguriertem Prometheus und Grafana-Dashboard auf Kubernetes deployen. Design und Implementierung verliefen reibungslos. Die einzige Herausforderung war, das Grafana-Dashboard als Konfigurations-YAML für das Kubernetes-Deployment zu erstellen. Nach intensiver Recherche in Dokumentationen und Experimenten löste ich dieses Problem schließlich.
Am 30. August erhielt ich die erfreuliche Nachricht, dass ich das Interview bestanden hatte. Im Einzelgespräch mit meinem Mentor besprachen wir kurz meine Kubernetes-Kenntnisse, die Hauptaufgaben und wichtige Meilensteine. Ich äußerte auch Bedenken, etwa zum Zeitdruck durch mein Forschungsprojekt und zu Metriken-Designrichtlinien. Mein Mentor zeigte Verständnis und ging auf alle Punkte ein.
Projektablauf
Mein Projekt trug den Titel Monitoring Metrics about Chaos Mesh und zielte darauf ab, die Observability von Chaos Mesh durch Metrikensammlung und ein Grafana-Dashboard zu verbessern.
In den ersten zwei Projektwochen eignete ich mir die Geschäftsprozesse und Code-Details von Chaos Mesh an. In den folgenden zwei Wochen erstellte ich ein Designdokument, um alle Metriken und Erfassungsmethoden zu strukturieren. Parallel studierte ich Metriken-Designrichtlinien und klärte mit meinem Mentor Details des Proposals sowie Code-Logiken.
Die meisten Metriken ließen sich einfach erfassen – durch einfache Abfragen von Datenbankobjekten, k8s-Objekten oder Zähloperationen. Einige spezielle Metriken erwiesen sich jedoch als komplex. Beispielsweise musste ich Daten durch Befehlsausführung im Netzwerk-Namespace des entsprechenden Containers abfragen, alle Container eines Daemons über drei verschiedene Runtimes ansprechen oder Kommunikationsdaten zwischen gRPC-Client und Server sammeln.
Diese Aufgaben waren mir neu. Daher holte ich regelmäßig technischen Support bei meinem Mentor ein, der stets prompt reagierte. Ich war beeindruckt von seinem umfassenden Fachwissen und seiner Erfahrung. Unter seiner Anleitung konnte ich schließlich das RFC-Dokument für mein Design fertigstellen. Zur Fortschrittsverfolgung erstellte ich später ein Tracking-Issue.
Während der anschließenden Programmierarbeit tauchten jedoch diverse Probleme auf. Rückblickend hätte ich viele davon bereits im Voraus lösen können. Daher hier einige gesammelte Empfehlungen:
Denke stets kritisch nach. Als ich den Projektvorschlag annahm, entwickelte ich spontan Lösungen für jede Metrik, übersah dabei aber grundlegende Fragen: Sind diese Metriken überhaupt notwendig? Gibt es eine bessere, verfügbare Lösung? Diese Grundfragen hätten bereits in der Konzeptphase geklärt werden müssen, wurden aber in die spätere Implementierungsphase verschleppt. Beispielsweise wiesen mich mein Mentor und Reviewer beim Einreichen des RFC darauf hin, dass einige Metriken bereits in der controller-runtime-Bibliothek implementiert waren. Bei der Arbeit an BPM-bezogenen Metriken kam eine ähnliche Rückfrage vom Reviewer. Erst dann wurde mir bewusst, dass ich diese Aspekte nie berücksichtigt hatte.
Kommuniziere kontinuierlich. Effektive Kommunikation war eine entscheidende Herausforderung in diesem Mentoring. Ich habe viele Lektionen gelernt, aber die wichtigste ist: Biete stets Optionen an, bevor du um Rat fragst. Wenn du Hilfe benötigst, liefere mehrere Lösungsvorschläge zur Diskussion. Selbst wenn diese nicht optimal sind – sie zeigen deine eigenständige Denkarbeit. Vermeide es, andere mitten in deine unstrukturierten Fragen zu stellen, es sei denn, du hast wirklich keine Ansatzpunkte nach gründlicher Überlegung.
Open Source verstehen. Dies war meine erste praktische Erfahrung mit Open Source. Im Vergleich zur Unternehmensarbeit gibt es erhebliche Unterschiede:
-
Informationssynchronisation: Anders als im Unternehmen mit häufigen persönlichen Meetings erfolgt die Kommunikation in Open-Source-Communities primär über Slack-Kanäle, GitHub-Issues und Pull Requests. Daher ist eine konsequente Dokumentation der Arbeit essenziell, damit andere den Fortschritt nachvollziehen können. In den ersten Wochen pflegte ich aus Gewohnheit ein Online-Forschungsdokument. Später erkannte ich, dass ein GitHub-Kanban oder Issue besser geeignet ist, um meinen Mentor nicht mit zusätzlichen Plattformen zu belasten.
Online-Forschungsdokument -
Umfassendere automatische Tests: Während in Unternehmen oft nur statische Codeanalyse, Unit-Tests und einfache Smoke-Tests automatisiert sind und manuelle Tests dominieren, umfassen Open-Source-Pipelines detailliertere Testfälle wie Integrationstests, End-to-End-Tests und Lizenzprüfungen. Codequalität und Sicherheit werden hier bereits vorab geprüft.
-
Code Reviews: An Reviews beteiligen sich viele Personen – Nutzer, Maintainer oder Community-Mitglieder, freiwillig oder zugewiesen. Im Gegensatz zu dedizierten Reviewern im Unternehmen kann dies zu längeren Review-Zyklen führen.
Nach dem Projekt
Diese 12 Wochen waren eine bereichernde Erfahrung. Ich vertiefte mein Verständnis für Kubernetes, CRDs und Observability, erkannte aber auch Wissenslücken in Code-Strukturierung, Linux-Grundlagen und Container-Technologien. Hier gibt es noch viel zu lernen!
Gleichzeitig konnte ich aufgrund unerwarteten Drucks in meinem Forschungsprojekt nicht genug Zeit für das Mentoring aufbringen. Selbst das Design des Grafana-Dashboards blieb unvollendet. Ich werde dies definitiv nachholen und das Projekt zu einem echten Abschluss bringen.
Ich möchte meinem Mentor @STRRL danken. Während meines Praktikums stieß ich auf viele Herausforderungen im Projekt, etwa bei Git-Operationen, Lösungen für Zirkelabhängigkeiten oder der Suche nach der Runtime-Schnittstelle für CRI-O. Ohne die Geduld und Anleitung meines Mentors hätte ich diese ungewohnten technischen Probleme kaum bewältigen können. Ebenso danke ich den Maintainern von Chaos Mesh für ihre Code-Reviews sowie dem CNCF LFX Mentorship-Projekt, das uns allen eine hervorragende Plattform bietet, um an der Open-Source-Community teilzuhaben.
Abschließend hoffe ich, dass jeder Studierende, der Teil der Open-Source-Community werden möchte, mit LFX Mentorship den ersten Schritt wagen kann!