KI-Toolkit für Cloud Engineering: Platform Engineering in GKE mit Gemini

1. Einführung

Die Fehlerbehebung bei fehlerhaften Kubernetes-Bereitstellungen ist ein häufiger, oft frustrierender Teil des Arbeitsalltags eines Plattformtechnikers. Normalerweise ist dafür viel manuelle Arbeit erforderlich: Logs durchsuchen, kubectl describe-Befehle ausführen und YAML-Dateien abgleichen, um eine einzelne Abweichung oder Fehlkonfiguration zu finden.

Allgemeine KI-Chatbots können zwar Konzepte erläutern oder einfachen Code schreiben, aber sie arbeiten in einem Vakuum. Sie wissen nichts über Ihre spezifische Codebasis oder den Live-Status Ihres Clusters, was zu viel manuellem Kopieren und Einfügen und Kontextwechseln führt.

In diesem Lab erfahren Sie, wie Sie diese Lücke schließen können, indem Sie KI-Tools mit immer mehr Kontext verwenden. Sie verwenden die Gemini CLI und das Model Context Protocol (MCP), um Probleme mit einer fehlerhaften Anwendung in GKE zu beheben. Am Ende dieses Labs wissen Sie, wie Sie KI einsetzen, die Ihre Dateien und Infrastruktur kennt, um komplexe Probleme schneller zu lösen, und wie Sie diese Workflows in wiederverwendbare „Skills“ für Ihr Team umwandeln.

Wichtige Konzepte

  • Platform Engineering:Platform Engineering ist die Praxis, interne Tools und Workflows zu entwickeln und zu verwalten, mit denen Softwareentwickler ihre eigene Infrastruktur verwalten können, ohne Experten für jeden zugrunde liegenden Cloud-Dienst sein zu müssen. Ziel ist es, technische Probleme zu reduzieren und gleichzeitig Konsistenz und Sicherheit zu gewährleisten. Durch die Erstellung eines standardisierten Golden Path sorgen Plattformteams dafür, dass Anwendungsentwickler sicher und schnell bereitstellen können, während das Plattformteam die Kontrolle über Governance und Kosten behält.
  • Gemini CLI:Die Gemini CLI ist eine Befehlszeile, mit der Sie direkt über Ihr Terminal mit Gemini-Modellen interagieren können. Im Gegensatz zu einem standardmäßigen webbasierten Chatbot ist die CLI für Ihre Entwicklungsumgebung konzipiert. So lässt sich KI einfacher in bestehende Shell-basierte Workflows einbinden. So können Sie die Ausgabe anderer Befehle direkt in das Modell einfügen und Anweisungen ausführen, ohne das Terminal zu verlassen.
  • Model Context Protocol (MCP):MCP ist ein offener Standard, der es einem KI-Modell ermöglicht, sich mit bestimmten Tools oder Datenquellen zu verbinden. Ohne MCP weiß ein KI-Modell nur, womit es trainiert wurde, und kann Ihre spezifischen Ressourcen nicht sehen. Mit dem GKE-MCP-Server kann die Gemini CLI aktiv die API Ihres Google Cloud-Projekts abfragen, den Status Ihrer Cluster prüfen und Befehle in Ihrem Namen ausführen. Es fungiert als Brücke zwischen der Reasoning Engine des Modells und der eigentlichen GKE API.
  • Agenten-Skills:Skills sind Pakete mit Anweisungen, Skripts und Ressourcen, die die Funktionen eines KI‑Agenten für spezielle Aufgaben erweitern. Damit können Sie Organisationsstandards festlegen und komplexe Workflows automatisieren.

Lernziele des Labs

Die Aufgaben in diesem Lab:

  1. Kontextentwicklung:Hier sehen Sie, wie sich die Problemlösung durch KI verbessert, wenn der Kontext zunimmt.
  2. Manuelle Fehlerbehebung im Vergleich zur KI-gestützten Fehlerbehebung:Vergleichen Sie den Schwierigkeitsgrad der manuellen Fehlerbehebung mit dem von KI-gestützten Workflows.
  3. Debugging mit vollständigem Kontext:Verwenden Sie die Gemini CLI mit dem GKE MCP-Server, um Anwendungen mit vollständiger Infrastrukturkenntnis zu debuggen.
  4. Funktionen erweitern:Sie lernen, benutzerdefinierte Skills zu schreiben, um Workflows zu automatisieren.

Hinweis zu LLM-Ausgaben

Aufgrund der Art dieses Labs und der Funktionsweise von LLMs werden die Ausgaben, die Sie erhalten, wahrscheinlich von den gezeigten Beispielausgaben abweichen. Das ist ein erwartetes Verhalten für generative KI. Konzentrieren Sie sich darauf, die Schritte und die vom Modell bereitgestellte Begründung zu verstehen, anstatt zu versuchen, den genauen Text oder die Formatierung in den Beispielen zu replizieren.

2. Projekt einrichten

Bevor Sie mit dem Lab beginnen, müssen Sie Ihre Umgebung vorbereiten. Öffnen Sie Cloud Shell, wählen Sie Ihr Projekt aus und führen Sie die Einrichtungs-Scripts aus. Los geht's!

Cloud Shell öffnen

Verwenden Sie für dieses Lab Cloud Shell, eine browserbasierte Terminalumgebung von Google Cloud. Sie ist mit allen erforderlichen Tools vorkonfiguriert, darunter die Google Cloud CLI (gcloud), kubectl und die Gemini CLI. So sparen Sie sich die Installation dieser Tools auf Ihrem lokalen Computer.

  1. Rufen Sie die Google Cloud Console auf.
  2. Klicken Sie rechts oben in der Kopfzeile der Konsole auf den Button Cloud Shell aktivieren (er sieht aus wie ein Terminal-Prompt >_).
  3. Am unteren Rand des Browserfensters wird eine Terminalsitzung geöffnet. Wenn Sie dazu aufgefordert werden, klicken Sie auf Weiter.

Projekt auswählen

Achten Sie darauf, dass Sie im Cloud Shell-Terminal im richtigen Projekt arbeiten.

  1. Wählen Sie ein vorhandenes Projekt aus oder erstellen Sie in der Console ein neues Projekt speziell für dieses Lab.
  2. Notieren Sie sich die Projekt-ID. Legen Sie das Projekt in der aktuellen Shell mit dem folgenden Befehl fest: gcloud config set project [YOUR_PROJECT_ID]

Lab einrichten

Führen Sie nun die Einrichtungs-Scripts aus, um die Umgebung vorzubereiten und die Fehler für das Lab einzuführen.

  1. Repository klonen
     👉💻 Führen Sie die folgenden Befehle aus, um nur das Lab-Verzeichnis zu klonen:
    git clone --depth 1 --filter=blob:none --sparse https://github.com/GoogleCloudPlatform/devrel-demos ~/devrel-demos
cd ~/devrel-demos
git sparse-checkout set codelabs/ai-toolkit-lab-1
  2. Zum Lab-Verzeichnis wechseln
     👉💻 Ausführen:
    cd ~/devrel-demos/codelabs/ai-toolkit-lab-1/
  3. Umgebungsvariablen festlegen
     👉💻 Führen Sie die folgenden Befehle aus, um Ihr Projekt und Ihre Region festzulegen:
    export PROJECT_ID=$(gcloud config get-value project)
export REGION=us-central1
  4. Setupskript ausführen
    :Mit diesem Skript werden die unten aufgeführten APIs aktiviert, ein GKE Autopilot-Cluster erstellt und die erforderlichen Tools installiert.
     👉💻 Führen Sie das Skript über das Stammverzeichnis aus:
    ./setup.sh
    Hinweis: Die Clustererstellung kann 5 bis 10 Minuten dauern.
  5. Fehlerhaften Zustand initialisieren
    :Wenn Sie das Szenario simulieren möchten, in dem Ihre Kollegen Ihnen eine fehlerhafte Umgebung hinterlassen haben, führen Sie das Skript break.sh aus. Dadurch werden die fehlerhaften Manifeste in das aktive Codebasisverzeichnis kopiert.
     👉💻 Führen Sie das Skript aus:
    ./break.sh
  6. Für die Lab-Übungen vorbereiten
    :Damit die KI nicht schummelt (die Lösungen sieht), wechseln Sie für den Rest des Labs in das Verzeichnis cymbal-bank.
     👉💻 Ausführen:
    cd ~/devrel-demos/codelabs/ai-toolkit-lab-1/cymbal-bank

Aktivierte APIs

Das Setupscript aktiviert mehrere Google Cloud APIs. Das sind die Funktionen:

  • container.googleapis.com::Die Google Kubernetes Engine API. Sie ist für alle Vorgänge auf Clusterebene erforderlich.
  • generativelanguage.googleapis.com::Die API, über die die Gemini CLI mit Gemini-Modellen kommunizieren kann.
  • cloudresourcemanager.googleapis.com::Erforderlich, um Metadaten auf Projektebene zu prüfen und Berechtigungen zu verwalten.
  • logging.googleapis.com::Dieser Dienst ist für die Fehlerbehebung unerlässlich, da er das Abrufen und Analysieren von Logs aus Ihren Containern ermöglicht.

3. Phase 0: Manuelle Fehlerbehebung (ohne KI)

Nachdem Sie sich nun im Verzeichnis cymbal-bank befinden, versuchen wir, die Fehler manuell zu finden. Das ist der „harte Weg“. Sehen Sie sich die Baseline an, bevor Sie KI die Arbeit abnehmen lassen. Bei der manuellen Fehlerbehebung werden Standardtools wie kubectl verwendet, um den Clusterstatus zu prüfen, Logs abzurufen und YAML-Dateien zu lesen, um Unstimmigkeiten zu erkennen. Das ist oft langsam, mühsam und erfordert Fachwissen, um die Zusammenhänge zu erkennen. Dies dient als perfekter Referenzpunkt für die KI-Tools, die Sie später verwenden.

  1. Bereitstellung versuchen:Sehen wir uns an, was Kubernetes von diesen Manifesten hält.
     👉💻 Führen Sie den folgenden Befehl aus, um die Manifeste anzuwenden:
    kubectl apply -f kubernetes-manifests/
    Es kann einige Sekunden dauern, bis die Pods hochfahren. Sie können den Start mit „watch kubectl get pods“ beobachten. Wenn sie hochgefahren wurden, beenden Sie die Beobachtung mit Strg+C.In der Liste werden zwei fehlerhafte Pods angezeigt:
    • Der frontend-Pod gibt einen CreateContainerConfigError zurück. Dieser Fehlertyp deutet in der Regel darauf hin, dass der Container Probleme beim Laden der erforderlichen Konfiguration hat. Überlegen Sie, welche externen Ressourcen ein Container zum Starten benötigt. Sind Umgebungsvariablen, Secrets oder ConfigMaps falsch konfiguriert oder fehlen sie? Untersuchen Sie die Konfiguration des Pods, um den genauen Grund für den Fehler zu finden.
    • Der userservice-Pod hat den Status ImagePullBackOff. Das bedeutet in der Regel, dass der Cluster das Container-Image, das er verwenden soll, nicht abrufen kann. Prüfen Sie die Details der Image-Anfrage: Sind der Image-Name und das Tag genau richtig? Gibt es möglicherweise Berechtigungsprobleme mit der Registry? Sehen Sie nach, woher das Image abgerufen wird, um herauszufinden, warum die Anfrage fehlschlägt.
  2. Schaden untersuchen:Verwenden Sie Standard-Kubernetes-Befehle, um zu sehen, was fehlschlägt.
    • 👉💻 Prüfen Sie den Status der Pods sowie ihre Namen:
      kubectl get pods
      • Beobachtung:Sie sehen Pods in ImagePullBackOff, CrashLoopBackOff, Pending oder CreateContainerConfigError.
      • Hinweis:Ein Pod im Status Running funktioniert nicht unbedingt richtig. Möglicherweise fehlen beispielsweise genügend Systemdiagnosen (Aktivitäts-/Bereitschaftsprüfungen), sodass der Status als „Wird ausgeführt“ angezeigt wird, obwohl die Anwendung darin fehlerhaft ist. In den Logs können Fehler angezeigt werden, obwohl ein Pod scheinbar ausgeführt wird. Insgesamt müssen 11 Fehler behoben werden.
    • 👉💻 Beschreiben Sie einen fehlerhaften Pod, um Ereignisse zu sehen (ersetzen Sie [POD_NAME] durch einen tatsächlichen Pod-Namen):
      kubectl describe pod [POD_NAME]
    • 👉💻 Anwendungsfehler in den Logs eines fehlerhaften Pods ansehen:
      kubectl logs [POD_NAME]

Screenshot mit der Ausgabe von „kubectl get pods“

  1. Fehlerbehebung:Öffnen Sie die Manifeste in kubernetes-manifests/ mit Cloud Shell Editor oder cat im Terminal. Versuchen Sie, die Fehler, die in den Logs und Ereignissen angezeigt werden, mit der Konfiguration in den YAML-Dateien in Beziehung zu setzen.Herausforderung:Versuchen Sie, NUR EINEN Fehler manuell zu beheben. Sie werden feststellen, dass Sie zwischen Dateien wechseln müssen, um den Rest der Fehlerkette zu ermitteln.

4. Phase 1: Fragen im Web stellen (Gemini-Web-UI)

Da die manuelle Fehlerbehebung langsam ist, versuchen wir es mit einem KI-Assistenten. Die Gemini Web-App ist eine leistungsstarke Mehrzweck-Chatoberfläche. Es eignet sich hervorragend zum Erklären von Konzepten und zum Generieren von Code-Snippets. Allerdings wird sie ohne Kontext zu Ihrer spezifischen Umgebung ausgeführt. Es kann Ihre Dateien nicht sehen, Ihren Cluster nicht untersuchen und keine Befehle ausführen. Sie müssen Fehlermeldungen und Dateiinhalte manuell kopieren und einfügen.

Screenshot der Gemini-Web-UI

  1. Zu Gemini wechseln:Öffnen Sie gemini.google.com in einem neuen Tab. Sie müssen sich mit Ihrem eigenen Google-Konto anmelden.
  2. Hilfe bei einem bestimmten Fehler anfordern:Angenommen, du siehst den Fehler ImagePullBackOff auf dem Pod userservice.
     👉💬 Gib diesen Prompt in die Gemini Web-UI ein:
    My Kubernetes deployment for 'userservice' is failing with ImagePullBackOff. Here is the image name: us-central1-docker.pkg.dev/bank-of-anthos-ci/bank-of-anthos/user-service:v0.6.9. What is wrong?
  3. Antwort der KI:Gemini gibt Ihnen eine Liste mit häufigen Ursachen:
    • Das Bild ist nicht vorhanden.
    • Sie sind nicht berechtigt, sie zu entfernen.
    • Es liegt ein Tippfehler vor.
    Es wird empfohlen, die Registrierung oder die IAM-Berechtigungen zu prüfen. Das Tool kann aber nicht wissen, dass der tatsächliche Bildname userservice (ohne Bindestrich) ist, wenn es Ihr Projekt nicht sieht.

Der Hauptknackpunkt ist, dass Gemini keinen Einblick in Ihre lokale Umgebung hat. Um den erforderlichen Kontext zu erhalten, müssten Sie ihn manuell bereitstellen, indem Sie Prompts eingeben und Text kopieren und einfügen. Das ist zeitaufwendig und fehleranfällig.

5. Phase 2: Terminal-Power (Gemini CLI)

Wechseln Sie nun zum Terminal und verwenden Sie die Gemini CLI. Mit der Gemini CLI können Sie die Leistungsfähigkeit von Gemini-Modellen direkt in Ihrem Terminal nutzen. Die CLI ist dort verfügbar, wo Sie arbeiten. Sie kann lokale Dateien lesen, Eingaben über Pipes entgegennehmen und sogar Shell-Befehle in Ihrem Namen ausführen (mit Ihrer Genehmigung). Das macht sie unglaublich nützlich, um KI in Ihre Arbeitsabläufe zu integrieren, ohne den Kontext wechseln zu müssen. Weitere Informationen und erweiterte Anwendungsfälle finden Sie in der offiziellen Gemini CLI-Dokumentation.

Hinweis:Die Antigravity CLI wurde offiziell veröffentlicht und ist der Nachfolger der Gemini CLI. In diesem Lab wird weiterhin die Gemini CLI verwendet. Weitere Informationen zur Antigravity CLI finden Sie in der offiziellen Dokumentation zur Antigravity CLI.

Kontext und Sichtbarkeit

Bevor Sie mit der Anleitung fortfahren, beachten Sie, dass die Sichtbarkeit von Gemini CLI für Ihr Projekt davon abhängt, wo Sie sie starten. Das Modell kann Dateien und Ordner relativ zu Ihrem aktuellen Arbeitsverzeichnis sehen. Wenn Sie es im Stammverzeichnis Ihres Projekts ausführen, hat es Zugriff auf alle Dateien in diesem Projekt. Wenn Sie es in einem Unterverzeichnis ausführen, ist die Ansicht auf dieses Unterverzeichnis und seine untergeordneten Elemente beschränkt. Achten Sie immer darauf, dass Sie sich im richtigen Verzeichnis befinden, bevor Sie das Modell bitten, Dateien zu analysieren oder zu ändern.

Gemini CLI starten

Gemini CLI ist standardmäßig in Cloud Shell enthalten. Starten Sie es einfach, um es mit Ihren lokalen Dateien zu verwenden.

  1. Zum Verzeichnis „Cymbal Bank“ wechseln
     👉💻 Führen Sie den folgenden Befehl aus, um sicherzugehen, dass Sie sich im richtigen Verzeichnis befinden:
    cd ~/devrel-demos/codelabs/ai-toolkit-lab-1/cymbal-bank
  2. Gemini CLI starten
     👉💻 Führen Sie den folgenden Befehl aus, um die Gemini CLI zu starten:
    gemini

Screenshot, der zeigt, wie die Gemini CLI aussieht

Gemini CLI verwenden

Sie wissen nur, wo sich der Code befindet und dass er nicht funktioniert. Lassen Sie uns mehr herausfinden und sehen, wie Gemini Ihnen helfen kann, die Anwendung zu reparieren. Testen Sie zuerst, ob Gemini den Kontext erfassen kann, indem Sie eine Frage zu den Anwendungsdateien stellen, die Gemini sehen können sollte.

  1. Codebasis untersuchen:Fragen Sie Gemini, was diese Anwendung ist und was sie tut.
    👉💬 Geben Sie diesen Prompt in die Gemini CLI ein:
    What is this application and what does it do?
    Die Gemini CLI liest die Dateien im aktuellen Verzeichnis und gibt einen allgemeinen Überblick über das Projekt.
  2. Problem in der Codebasis suchen:Da Gemini CLI Ihre Dateien sehen kann, können Sie das Tool bitten, nach einer Unstimmigkeit zu suchen.
     👉💬 Geben Sie diesen Prompt in die Gemini CLI ein:
    The contacts service pod is running, but I can't reach the service. Review kubernetes-manifests/contacts.yaml and check for common issues
    Die Gemini CLI liest die Dateien und erkennt die Diskrepanz zwischen app: contacts-backend und app: contacts. Das ist ein großer Fortschritt gegenüber den vorherigen Phasen.
  3. Gemini CLI bitten, das Problem zu beheben
     👉💬 Geben Sie diesen Prompt in die Gemini CLI ein:
    Fix the label mismatch in contacts.yaml so the service matches the deployment.
    Die Gemini CLI zeigt Ihnen das korrigierte YAML an oder wendet die Änderung sogar an, wenn Sie den Befehl genehmigen.
  4. Die Einschränkung:Obwohl die Dateien angezeigt werden, ist nicht ersichtlich, was tatsächlich in Ihrem Cluster ausgeführt wird. Wenn ein Pod aufgrund eines Laufzeitfehlers fehlschlägt, der im statischen YAML nicht offensichtlich ist, kann ohne Protokolle oder Clusterstatus nicht geholfen werden.

Hinweis:Die Gemini CLI fragt Sie um Ihre Einwilligung, wenn Befehle ausgeführt oder Änderungen an Dateien vorgenommen werden. So behalten Sie die Kontrolle über Ihre Umgebung. Wenn Sie eine Aufforderung wie die unten sehen, können Sie mit der Eingabetaste antworten: „1. „Einmal zulassen“ für jede Aktionsanfrage. Sie können auch die Pfeil-nach-unten-Taste drücken und die Eingabetaste betätigen, um „2. „Für diese Sitzung zulassen“ aus, damit die Gemini CLI diese Aktion während dieser Unterhaltung immer unabhängig ausführt, ohne Sie um Erlaubnis zu fragen. Wenn Sie die Gemini CLI jedoch schließen und wieder öffnen, hat sie diese Berechtigung nicht mehr und fragt Sie vor jeder Aktion noch einmal um Erlaubnis.

Screenshot der Einwilligungsansicht der Gemini CLI

Hinweis:Wenn Sie nicht weiterkommen oder noch einmal von vorn beginnen möchten, können Sie die Kubernetes-Manifeste jederzeit in ihren ursprünglichen fehlerhaften Zustand zurücksetzen, indem Sie ../break.sh im Verzeichnis cymbal-bank ausführen.

Hinweis:Wenn Sie ein Nutzungslimit erreichen, wählen Sie „Stop“ aus und führen Sie dann /model aus, um zu sehen, welche Modelle ihre Limits erreicht haben. Wechseln Sie zu einem anderen Modell, z. B. gemini-2.5-flash-lite. Fordern Sie das Modell dann mit „continue“ auf, das Lab mit dem neuen Modell fortzusetzen.

6. Phase 3: Debugging mit vollständigem Kontext (Gemini CLI + GKE MCP)

In Phase 2 wurde gezeigt, wie leistungsstark KI sein kann, wenn sie Ihre Dateien sehen kann. Allerdings war die Interaktion auch sehr aufwendig. Sie mussten jeden einzelnen Dateilesevorgang und jede Toolaktion manuell genehmigen, was bei einer komplexen Debugging-Sitzung zu erheblichen Reibungsverlusten führt. In Phase 3 wird der GKE MCP-Server eingeführt, um dieses Problem zu beheben. Er bietet der KI direkte „Infrastrukturinformationen“. So kann Gemini Logs, Ereignisse und Metadaten mit weniger manuellen Unterbrechungen analysieren und einen automatisierteren und zusammenhängenderen Ablauf für die Fehlerbehebung schaffen.

Was ist das MCP?

Um das MCP zu verstehen, ist es hilfreich, zuerst das Konzept von Tools in der Welt der KI zu verstehen. Ein Tool ist im Grunde eine externe Funktion oder Anwendung, die ein LLM verwenden kann, um Aktionen auszuführen oder Daten abzurufen, auf die es sonst nicht zugreifen könnte, z. B. um das Wetter abzurufen, ein bestimmtes Skript auszuführen oder eine Datenbank abzufragen. Einzelne Tools sind zwar leistungsstark, aber es war schon immer eine Herausforderung, sie sicher und konsistent zwischen verschiedenen KI-Agents und ‑Umgebungen zu teilen. Das MCP löst dieses Problem, indem es als standardisierte Plattform fungiert, auf der diese Tools gehostet und für jeden kompatiblen KI-Client verfügbar gemacht werden können.

Das Model Context Protocol (MCP) ist ein Open-Source-Protokoll, das es KI-Modellen ermöglicht, sicher auf externe Datenquellen und Tools zuzugreifen. Anstatt Integrationen für jedes spezifische Tool oder jede spezifische Datenbank fest zu codieren, bietet MCP eine standardisierte Möglichkeit für Modelle, mit ihrer Umgebung zu interagieren.

Sie können die verfügbaren Tools in der Gemini CLI aufrufen, indem Sie /mcp in der Gemini CLI ausführen.

In diesem Lab ermöglicht der GKE MCP-Server der Gemini CLI, direkt mit Ihrem GKE-Cluster zu interagieren. So kann sie Ressourcen prüfen, Logs lesen und Ihnen bei der Fehlerbehebung helfen, da sie den Live-Status des Clusters kennt. Dadurch wird die KI von einem statischen Code-Analyzer zu einem aktiven Assistenten für die Fehlerbehebung, der den Live-Status Ihrer Infrastruktur versteht.

GKE MCP-Erweiterung konfigurieren

Standardmäßig ist die Gemini CLI ein Tool für allgemeine Zwecke. Konfigurieren Sie den GKE-MCP-Server, indem Sie eine Konfigurationsdatei erstellen.

  1. 👉💻 Beenden Sie zuerst die Gemini CLI, falls Sie sich noch darin befinden, indem Sie /quit eingeben.
  2. 👉💻 Führen Sie den folgenden Befehl aus, um das Erweiterungsverzeichnis zu erstellen:
    mkdir -p ~/.gemini/extensions/gke
  3. 👉💻 Führen Sie den folgenden Befehl aus, um die Konfigurationsdatei zu erstellen. Mit diesem Befehl wird Ihr PROJECT_ID automatisch in die Datei eingefügt:
    cat << EOF > ~/.gemini/extensions/gke/gemini-extension.json
{
  "name": "gke",
  "version": "1.0.0",
  "mcpServers": {
    "container": {
      "httpUrl": "https://container.googleapis.com/mcp",
      "authProviderType": "google_credentials",
      "oauth": {
        "scopes": ["https://www.googleapis.com/auth/container"]
      },
      "timeout": 30000,
      "headers": {
        "x-goog-user-project": "$PROJECT_ID"
      }
    }
  }
}
EOF
  4. 👉💻 Gemini CLI starten:
    gemini
  5. Prüfen Sie, ob der MCP-Server aktiviert ist, indem Sie /mcp in die Gemini CLI eingeben.

Gemini auffordern, anhand des Clusterstatus zu debuggen

  1. Fehlerbehebung bei fehlgeschlagener Bereitstellung:Bitten Sie Gemini, den Cluster zu untersuchen und die Manifeste basierend auf den Ergebnissen zu korrigieren.
     👉💬 Geben Sie diesen Prompt in die Gemini CLI ein:
    The frontend deployment is failing. Can you use your tools to check the logs and events of the pods, and then fix it?
    Gemini verwendet MCP-Tools, um im Hintergrund kubectl-Befehle aufzurufen. Es erkennt den Fehler ImagePullBackOff, erklärt die Ursache und schlägt die richtige Lösung vor.
  2. Komplexe Probleme beheben:Bitten Sie den Assistenten, in den Logs nach Fehlern auf Anwendungsebene zu suchen.
     👉💬 Geben Sie diesen Prompt in die Gemini CLI ein:
    Check the logs for the 'contacts' pod. Why is it failing to connect to the database?
    Die Gemini CLI erkennt den Fehler „Verbindung abgelehnt“ und führt ihn auf die Port- oder Dienstnamensabweichung in config.yaml zurück.
  3. Wiederholen:Bitten Sie Gemini, die anderen Probleme zu beheben, die Sie in Phase 0 gefunden haben.
     👉💬 Geben Sie diesen Prompt in die Gemini CLI ein:
    Check if the service 'contacts' is correctly routing traffic to its pods
     👉💬 Geben Sie diesen Prompt in die Gemini CLI ein:
    Are there any pods failing due to resource limits?

Hinweis:Wenn Sie nicht weiterkommen oder noch einmal von vorn beginnen möchten, können Sie die Kubernetes-Manifeste jederzeit in ihren ursprünglichen fehlerhaften Zustand zurücksetzen, indem Sie ../break.sh im Verzeichnis cymbal-bank ausführen.

7. Phase 4: Team stärken (Agent Skills)

Sie können die KI-Funktionen auch an Ihre spezifischen Anforderungen anpassen, indem Sie benutzerdefinierte Agent Skills erstellen.

Was sind Agent-Skills?

Agenten-Skills sind Pakete mit Anweisungen, Skripts und Ressourcen, die einen KI-Agenten für spezielle Aufgaben erweitern. Damit können Sie Organisationsstandards festlegen und komplexe Workflows automatisieren. Ein Skill befindet sich in einem bestimmten Verzeichnis und enthält eine SKILL.md-Datei, in der sein Verhalten definiert ist. Durch das Erstellen von Skills sorgen Sie dafür, dass die KI einem konsistenten, wiederholbaren Prozess folgt, anstatt zu improvisieren.

Ein typisches Skill-Verzeichnis sieht so aus:

my-skill/
├── SKILL.md          # Main instruction file (Required)
├── scripts/           # Helper scripts (Optional)
└── resources/         # Templates or data files (Optional)

Skill zur Fehlerbehebung bei Kubernetes entwickeln

Anstatt diese Dateien manuell zu erstellen, bietet die Gemini CLI eine leistungsstarke Möglichkeit, Skills mithilfe von natürlicher Sprache zu erstellen.

Angenommen, Sie möchten einen Skill namens k8s-troubleshooter erstellen, um die gerade ausgeführten Schritte zu automatisieren.

  1. Skill über Prompts erstellen:Sie können die Gemini CLI bitten, den Skill für Sie zu erstellen, basierend auf dem, was Sie heute gelernt haben.
     👉💬 Geben Sie diesen Prompt in die Gemini CLI ein
    :Create a new skill called 'k8s-troubleshooter' that helps diagnose issues with Kubernetes manifests and cluster state. It should be able to analyze pod logs, events, and resource descriptions to identify common deployment problems and configuration errors.
    Ähnlich wie beim Aufrufen eines Tools oder Ausführen einer Aktion sollte die Gemini CLI Ihnen mitteilen, dass Ihr Prompt den Skill „skill-creator“ aktiviert hat. Dies ist ein vorkonfigurierter Skill in der Gemini CLI, mit dem Gemini Agent Skills erstellen kann.
    Gemini sollte Sie um die Erlaubnis bitten, das Skill-Verzeichnis zu erstellen. Genehmigen Sie dies, indem Sie 1. Einmal erlauben auswählen.
    Gemini führt automatisch folgende Schritte aus:
    • Erstellt ein Verzeichnis unter ~/.gemini/skills/k8s-troubleshooter/.
    • Generiert eine SKILL.md-Datei mit Anweisungen basierend auf Ihrem Prompt.
    • Erstellt Standardressourcenverzeichnisse.
  2. Gemini CLI neu starten
     👉💻 Schließen Sie die Gemini CLI (/quit) und starten Sie sie dann neu:
    gemini
  3. Prüfen, ob der Skill geladen wurde
     👉💻 Prüfen Sie, ob der Skill aktiv ist, indem Sie /skills in die Gemini CLI eingeben. k8s-troubleshooter sollte in der Liste angezeigt werden.
  4. So funktioniert es in der Praxis:Rufen Sie den Skill jetzt auf:
     👉💬 Geben Sie diesen Prompt in die Gemini CLI ein:
    Use the k8s-troubleshooter skill to find out why the contacts service is failing.
    Die KI folgt dem strukturierten Plan in SKILL.md, anstatt zu improvisieren, was zu konsistenteren Ergebnissen führt.

Übung: Eigene Skills konzipieren

Denken Sie an Ihren täglichen Workflow. Welche sich wiederholende Aufgabe könnten Sie mit einem Skill automatisieren?

  • Idee:Ein Skill, mit dem Manifeste vor der Bereitstellung auf Best Practices für die Sicherheit geprüft werden können.
  • Idee:Ein Skill zum Generieren komplexer GKE-Clusterkonfigurationen basierend auf dem Arbeitslasttyp.

8. Fazit

In diesem Lab wird eine neue Möglichkeit zur Interaktion mit der Cloud-Infrastruktur demonstriert, indem verschiedene Ebenen des KI-Kontexts durchlaufen werden. Wenn Sie von keinem Kontext zu einem vollständigen Infrastrukturkontext (Gemini CLI + GKE MCP) wechseln, sehen Sie, wie viel effektiver ein KI-Assistent wird, wenn er Ihre Dateien und den Clusterstatus sieht.

Lab-Zusammenfassung

  • Kontext ist wichtig:Sie sehen, dass KI-Tools ohne Kontext bei spezifischen Problemen mit der Codebasis nicht helfen können.
  • Terminalkontext:Sie verwenden die Gemini CLI, um lokale Dateien zu analysieren und Konfigurationsfehler direkt in Ihrem Arbeitsbereich zu identifizieren.
  • Debugging mit vollständigem Kontext:Sie verwenden die Gemini CLI mit MCP, damit die KI komplexe Probleme diagnostizieren und beheben kann, indem sie Codebase-Dateien mit dem Live-Clusterstatus in Beziehung setzt.
  • Erweiterbarkeit:Sie lernen Skills kennen und erfahren, wie Sie sie verwenden, um Organisationswissen zu codieren.

Bereinigen

Um laufende Gebühren zu vermeiden, führen Sie das Teardown-Script aus. Dieser Schritt ist nicht erforderlich, wenn Sie das Lab in Qwiklabs ausführen.

👉💻 Führen Sie den folgenden Befehl im Verzeichnis des Workshops aus:

cd ~/devrel-demos/codelabs/ai-toolkit-lab-1/
./teardown.sh

Nächste Schritte

Hier sind einige Empfehlungen für weitere Informationen:

9. Anhang: Lösung für Manifest-Fehler

Wenn Sie nicht weiterkommen oder die Fehler überprüfen möchten, finden Sie hier eine Liste der Änderungen, die im Verzeichnis manifests-broken/ eingeführt wurden, und Informationen dazu, wie Sie sie beheben können:

  1. Fehlerhafte URLs in config.yaml
      :
    • Fehler: TRANSACTIONS_API_ADDR: "ledgerwriter::8080" (doppelter Doppelpunkt).
    • Grund:Die Anwendung kann die Adresse nicht parsen, was zu Verbindungsfehlern führt.
    • Problembehebung:Ändern Sie die Einstellung wieder in "ledgerwriter:8080".
  2. Nicht übereinstimmende Labels in contacts.yaml
      :
    • Fehler:Die Dienstauswahl ist auf app: contacts-backend anstelle von contacts festgelegt.
    • Grund:Der Dienst kann die Pods (die noch app: contacts haben) nicht finden, sodass kein Traffic weitergeleitet wird.
    • Lösung:Ändern Sie die Auswahl in app: contacts.
  3. Port-Fehler in userservice.yaml:
    • Fehler:Der Dienst targetPort ist auf 8081 anstatt auf 8080 festgelegt.
    • Grund:An den Dienst gesendeter Traffic wird an den falschen Containerport weitergeleitet, was zu einer verweigerten Verbindung führt.
    • Problembehebung:Ändern Sie targetPort wieder in 8080.
  4. Nicht übereinstimmende Dienstnamen in config.yaml:
    • Fehler : BALANCES_API_ADDR: "balance-reader:8080" (statt balancereader).
    • Grund:Der Hostname kann im DNS nicht aufgelöst werden, da der Dienst den Namen balancereader hat.
    • Problembehebung:Ändern Sie die Einstellung wieder in "balancereader:8080".
  5. Image-Pull-Richtlinien in contacts.yaml
      :
    • Fehler: imagePullPolicy: Never.
    • Grund:K8s ruft das Image nicht aus der Registry ab, da es davon ausgeht, dass es lokal ist. Der Vorgang schlägt mit ErrImagePull fehl.
    • Korrektur:Entfernen Sie die Zeile oder legen Sie sie auf IfNotPresent fest.
  6. Fehler bei Bereitschaftsprobes in userservice.yaml:
    • Fehler:Der Pfad wurde in /healthz anstelle von /ready geändert.
    • Grund:Der Container stellt /healthz nicht bereit. Daher schlägt die Probe fehl und der Pod wird nie als bereit markiert.
    • Problembehebung:Ändern Sie den Pfad zurück zu /ready.
  7. Ressourcenlimits in contacts.yaml
      :
    • Fehler:Das Speicherlimit wurde auf 10Mi anstelle von 128Mi festgelegt.
    • Grund:Die App benötigt mehr Arbeitsspeicher, um gestartet zu werden, was dazu führt, dass sie aufgrund von Arbeitsspeichermangel beendet wird.
    • Lösung:Stellen Sie das Speicherlimit wieder her.
  8. Fehlende Umgebungsvariablen in frontend.yaml:
    • Fehler:Die Umgebungsvariable REGISTERED_OAUTH_CLIENT_ID wurde entfernt.
    • Grund:Die App kann fehlschlagen oder Funktionen deaktivieren, wenn erwartete Umgebungsvariablen fehlen.
    • Lösung:Stellen Sie die Definition der Umgebungsvariable wieder her.
  9. ConfigMap-Schlüssel stimmen in frontend.yaml nicht überein
      :
    • Fehler : key: DEMO_USER statt DEMO_LOGIN_USERNAME.
    • Grund:K8s kann den Schlüssel in der ConfigMap nicht finden, sodass der Container nicht gestartet werden kann.
    • Lösung:Ändern Sie den Schlüssel zurück zu DEMO_LOGIN_USERNAME.
  10. Tippfehler im Bildnamen in userservice.yaml
    • Fehler : user-service statt userservice.
    • Grund:Das Image ist nicht in der Registry vorhanden, was zu ImagePullBackOff führt.
    • Lösung:Korrigieren Sie den Bildnamen.
  11. Probleme mit Dienstkonten in contacts.yaml
    • Fehler : bank-of-anthos-sa statt bank-of-anthos.
    • Grund:Das Dienstkonto ist nicht vorhanden oder hat keine Berechtigungen.
    • Lösung:Verwenden Sie den richtigen Namen des Dienstkontos.