Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.

KCC-Vorgänge mit Google Antigravity optimieren

1. Einführung

In diesem Codelab lernen Sie Google Antigravity (im Rest des Dokuments als Antigravity bezeichnet) kennen, eine agentische Entwicklungsplattform, die die IDE in die Agent-First-Ära weiterentwickelt.

Im Gegensatz zu herkömmlichen Coding-Assistenten, die nur Zeilen automatisch vervollständigen, bietet Antigravity eine „Einsatzzentrale“ für die Verwaltung autonomer KI-Agenten, die planen, codieren und sogar im Web suchen können, um Sie bei der Entwicklung zu unterstützen.

Antigravity ist als Plattform konzipiert, bei der der KI-Agent im Mittelpunkt steht. Es geht davon aus, dass die KI nicht nur ein Tool zum Schreiben von Code ist, sondern ein autonomer Akteur, der komplexe technische Aufgaben mit minimaler menschlicher Interaktion planen, ausführen, validieren und wiederholen kann.

Lerninhalte

Antigravity installieren und konfigurieren.
Wichtige Konzepte von Antigravity wie Agent Manager, Editor und Browser kennenlernen.
Ein produktionsreifes KCC Ops-Skill von Grund auf erstellen , um Google Cloud-Ressourcen sicher und konform zu verwalten.

Voraussetzungen

Antigravity ist derzeit als Vorabversion für private Gmail-Konten verfügbar. Es enthält ein kostenloses Kontingent für die Verwendung von Premium-Modellen.

Antigravity muss lokal auf Ihrem System installiert sein. Das Produkt ist für Mac, Windows und bestimmte Linux-Distributionen verfügbar. Neben Ihrem eigenen Computer benötigen Sie Folgendes:

Ein Gmail-Konto (privates Gmail-Konto)
Ein Google Cloud-Konto und ein Google Cloud-Projekt
Einen Webbrowser wie Chrome, der die Google Cloud Console und Cloud Shell unterstützt

2. Einrichtung und Anforderungen

Projekteinrichtung

Google Cloud-Projekt erstellen

Wählen Sie in der Google Cloud Console auf der Seite der Projektauswahl ein Google Cloud-Projekt aus oder erstellen Sie eines.
Die Abrechnung für das Cloud-Projekt muss aktiviert sein. So prüfen Sie, ob die Abrechnung für ein Projekt aktiviert ist.

Dieses Codelab richtet sich an Nutzer und Entwickler aller Erfahrungsstufen (auch Anfänger).

3. Installation

Wenn Sie Antigravity noch nicht installiert haben, beginnen wir mit der Installation. Das Produkt ist derzeit als Vorabversion verfügbar und Sie können Ihr privates Gmail-Konto verwenden, um loszulegen.

Rufen Sie die Downloadseite auf und klicken Sie auf die entsprechende Betriebssystemversion für Ihren Fall. Starten Sie das Installationsprogramm der Anwendung und installieren Sie sie auf Ihrem Computer. Nachdem Sie die Installation abgeschlossen haben, starten Sie die Antigravity-Anwendung.

Wichtige Schritte bei der Einrichtung:

Einrichtungsablauf auswählen:Wir empfehlen für dieses Codelab einen Neustart.
Überprüfungsgestützte Entwicklung (empfohlen): Wählen Sie diese Option aus. So kann der KI-Agent eine Entscheidung treffen und den Nutzer um Genehmigung bitten, was für Infrastrukturvorgänge entscheidend ist.

Konfigurieren Sie als Nächstes den Editor und melden Sie sich in Google an. Akzeptieren Sie abschließend die Nutzungsbedingungen.

4. Infrastruktureinrichtung: GKE und Config Connector

Bevor Sie das Skill erstellen können, benötigen Sie eine Google Cloud-Umgebung, in der Config Connector (KCC) manuell installiert und im Namespace-Modus konfiguriert ist. So können Sie GCP-Ressourcen als Kubernetes-Objekte verwalten.

Schritt 0: Umgebung vorbereiten

1. Clusteranforderungen

Erstellen Sie einen neuen GKE-Cluster mit den erforderlichen aktivierten Funktionen:

# Set your variables
export PROJECT_ID=$(gcloud config get-value project)
export CLUSTER_NAME="kcc-ops-cluster"
export REGION="us-central1"

# Create the cluster
gcloud container clusters create ${CLUSTER_NAME} \
    --region ${REGION} \
    --release-channel "regular" \
    --workload-pool=${PROJECT_ID}.svc.id.goog \
    --logging=SYSTEM \
    --monitoring=SYSTEM

# Get cluster credentials
gcloud container clusters get-credentials ${CLUSTER_NAME} --region ${REGION}

2. Config Connector-Operator installieren

Der Operator hält Ihre Installation auf dem neuesten Stand.

# Download the latest Config Connector operator
gcloud storage cp gs://configconnector-operator/latest/release-bundle.tar.gz release-bundle.tar.gz

# Extract the bundle
tar zxvf release-bundle.tar.gz

# Install the operator (Standard Cluster)
kubectl apply -f operator-system/configconnector-operator.yaml

3. Namespace-Modus konfigurieren

Erstellen Sie eine ConfigConnector-Ressource, um den Betriebsmodus anzugeben.

# configconnector.yaml
apiVersion: core.cnrm.cloud.google.com/v1beta1
kind: ConfigConnector
metadata:
  name: configconnector.core.cnrm.cloud.google.com
spec:
  mode: namespaced
  stateIntoSpec: Absent

kubectl apply -f configconnector.yaml

4. Identität und Namespace erstellen

In diesem Lab verwenden wir den default-Namespace und ein dediziertes Google-Dienstkonto (GSA).

# Set your variables
export PROJECT_ID=$(gcloud config get-value project)
export NAMESPACE="default"

# Create the Google Service Account
gcloud iam service-accounts create kcc-identity --project ${PROJECT_ID}

# Grant permissions on the project
gcloud projects add-iam-policy-binding ${PROJECT_ID} \
    --member="serviceAccount:kcc-identity@${PROJECT_ID}.iam.gserviceaccount.com" \
    --role="roles/owner"

# Grant Metric Writer permissions
gcloud projects add-iam-policy-binding ${PROJECT_ID} \
    --member="serviceAccount:kcc-identity@${PROJECT_ID}.iam.gserviceaccount.com" \
    --role="roles/monitoring.metricWriter"

# Bind GSA to KSA via Workload Identity
gcloud iam service-accounts add-iam-policy-binding \
    kcc-identity@${PROJECT_ID}.iam.gserviceaccount.com \
    --member="serviceAccount:${PROJECT_ID}.svc.id.goog[cnrm-system/cnrm-controller-manager-${NAMESPACE}]" \
    --role="roles/iam.workloadIdentityUser"

5. Namespace konfigurieren

Erstellen Sie einen ConfigConnectorContext, um den Namespace zu beobachten.

# configconnectorcontext.yaml
apiVersion: core.cnrm.cloud.google.com/v1beta1
kind: ConfigConnectorContext
metadata:
  name: configconnectorcontext.core.cnrm.cloud.google.com
  namespace: default
spec:
  googleServiceAccount: "kcc-identity@${PROJECT_ID}.iam.gserviceaccount.com"
  stateIntoSpec: Absent

kubectl apply -f configconnectorcontext.yaml

6. Installation bestätigen

Warten Sie, bis der Controller für den default-Namespace bereit ist.

kubectl wait -n cnrm-system \
    --for=condition=Ready pod \
    -l cnrm.cloud.google.com/component=cnrm-controller-manager \
    -l cnrm.cloud.google.com/scoped-namespace=default

5. Agent Manager: Einsatzzentrale

Antigravity basiert auf dem Open-Source-Visual Studio Code (VS Code), ändert aber die Nutzererfahrung grundlegend, um die Agentenverwaltung gegenüber der Textbearbeitung zu priorisieren. Die Benutzeroberfläche ist in zwei separate Hauptfenster unterteilt: den Editor und den Agent Manager.

KI-Agenten-Manager

Beim Starten von Antigravity wird der Nutzer in der Regel vom Agent Manager begrüßt. Diese Benutzeroberfläche fungiert als Einsatzzentrale. Sie ist für die Orchestrierung auf hoher Ebene konzipiert und ermöglicht es Entwicklern, mehrere KI-Agenten zu starten, zu überwachen und mit ihnen zu interagieren, die asynchron in verschiedenen Arbeitsbereichen oder an verschiedenen Aufgaben arbeiten.

In dieser Ansicht fungiert der Entwickler als Architekt. Er definiert Ziele auf hoher Ebene. Jede dieser Anfragen startet eine dedizierte Agenteninstanz. Die Benutzeroberfläche bietet eine Visualisierung dieser parallelen Arbeitsabläufe und zeigt den Status jedes KI-Agenten, die von ihm erstellten Artefakte (Pläne, Ergebnisse, Unterschiede) und alle ausstehenden Anfragen zur Genehmigung durch den Nutzer an.

6. Antigravity-Browser und Artefakte

Antigravity erstellt Artefakte , während es plant und seine Arbeit erledigt. Dabei handelt es sich um Markdown-Dateien, Architekturdiagramme, Bilder, Browseraufzeichnungen und Code-Unterschiede.

Artefakte schließen die „Vertrauenslücke“

Wenn ein KI-Agent behauptet, einen Fehler behoben zu haben, musste der Entwickler bisher den Code lesen, um das zu überprüfen. In Antigravity erstellt der KI-Agent ein Artefakt, um das zu beweisen.

Artefakte

Dies sind die wichtigsten Artefakte, die von Antigravity erstellt werden:

Task Lists: Ein strukturierter Plan, der vor dem Schreiben von Code erstellt wird.
Implementation Plan: Architekturänderungen mit technischen Details.
Walkthrough: Eine Zusammenfassung der Änderungen und wie sie getestet werden können.
Browser Recordings: Videoaufzeichnungen von Browsersitzungen zur Überprüfung der Benutzeroberfläche.

Antigravity-Browser

Wenn der KI-Agent mit dem Web interagieren muss, ruft er einen Browser-Sub-Agenten auf. Dieser Sub-Agent kann klicken, scrollen, tippen und Konsolenprotokolle lesen. Er verwendet ein spezielles Modell, um auf den Seiten zu arbeiten, die im von Antigravity verwalteten Browser geöffnet sind.

7. Editor

Der Editor behält die Vertrautheit von VS Code bei. Er enthält den Standard-Datei-Explorer, die Syntaxhervorhebung und das Erweiterungs-Ökosystem.

Wichtige Editorfunktionen:

Automatische Vervollständigung: Intelligente Vorschläge, die durch Drücken der Tabulatortaste akzeptiert werden.
Tabulatortaste zum Importieren: Schlägt das Hinzufügen fehlender Abhängigkeiten vor.
Befehle (Cmd + I): Löst Inline-Vervollständigungen in natürlicher Sprache aus.
Agenten-Seitenleiste (Cmd + L): Blendet die Agenten-Seitenleiste ein oder aus, um Fragen zu stellen oder mit @ auf Dateien zu verweisen.

8. Feedback geben

Ein Kernstück von Antigravity ist die Möglichkeit, mühelos Feedback zu erhalten. Diese Artefakte bieten Ihnen die Möglichkeit, dem KI-Agenten Kommentare im Google Docs-Stil zu geben.

Wenn Sie einem Plan oder einer Aufgabe einen Kommentar hinzufügen, denken Sie daran, den Kommentar zu senden. So lenken Sie den KI-Agenten in die gewünschte Richtung.

9. KCC Ops-Skill erstellen

Nachdem Sie die Plattform kennengelernt haben, erstellen wir das KCC Ops-Skill.

Mit Kubernetes Config Connector (KCC) können Sie GCP-Ressourcen als K8s-Objekte verwalten. Dazu sind jedoch Sicherheitsvorkehrungen erforderlich, um Konfigurationsabweichungen, Verstöße gegen Compliance-Anforderungen und versehentliche Ressourcenerstellung zu verhindern.

Schritt 1: Skill strukturieren

Erstellen Sie im Stammverzeichnis Ihres Arbeitsbereichs die Verzeichnisstruktur für Ihr Skill:

mkdir -p .agents/skills/kcc-ops/scripts
mkdir -p .agents/skills/kcc-ops/resources/policies/templates
mkdir -p .agents/skills/kcc-ops/resources/policies/constraints

Schritt 2: SKILL.md erstellen (das Gehirn)

In der Datei SKILL.md werden die Metadaten und die wichtigste „Goldene Regel“ für den KI-Agenten definiert. Erstellen Sie .agents/skills/kcc-ops/SKILL.md:

---
name: kcc-ops
description: Assists with Config Connector (KCC) configuration, resource generation, and troubleshooting on Google Cloud.
---

# Config Connector (KCC) Operations Skill

Use this skill to manage Google Cloud resources using Kubernetes-style configuration (Config Connector).

## 🛑 GOLDEN RULE: Separate Generation from Application

**NEVER generate and apply a manifest in a single autonomous step.**

1. **Craft:** Write the generated manifest to a local file.
2. **Analyze:** Present the manifest to the user. Perform Impact Analysis and Dry Runs. Explain the consequences of the change (e.g., "If this topic is deleted, the attached subscription becomes orphaned").
3. **Wait:** Pause execution and explicitly wait for user permission to proceed.
4. **Apply:** Only run `kubectl apply` *after* the user has reviewed the manifest and the impact analysis, and then unequivocally confirmed you should proceed.

## Core Responsibilities

0. **Context Verification**: Verify the execution context (cluster, namespace, GCP project, user account) with the user before performing any operations.
1. **Installation & Health**: Verify KCC is properly installed and healthy on the target cluster.
2. **Resource Inventory**: Query and summarize existing KCC resources within a namespace.
3. **Brownfield Bulk Export (Adoption)**: Export existing GCP project resources into valid KCC YAML manifests.
4. **Manifest Generation**: Generate valid YAML manifests for GCP resources using KCC CRDs.
5. **Impact Analysis**: Identify ancillary services and resources (e.g., Cloud Run, Apps) that depend on a resource being modified.
6. **Change Differentiation**: Generate diff summaries for resource edits to support change control.
7. **Policy Compliance**: Vet KCC manifests against OPA/Gatekeeper policies.
8. **Troubleshooting**: Analyze resource status, and consult the troubleshooting guide to resolve reconciliation issues.

## Guidelines for Operations

### 0. Context Verification

Before performing **any operations or executing commands** (including health checks), you **MUST** verify the current execution context and obtain explicit user confirmation.

1. **Read Context:** Use commands like `kubectl config current-context`, `kubectl config view --minify -o jsonpath='{.contexts[0].context.namespace}'`, `gcloud config get-value project`, and `gcloud config get-value account` to determine the active environment.
2. **Present & Ask:** Show this information to the user clearly (e.g., "I see my context is X, namespace is Y, project is Z, and account is A. Is this correct?").
3. **Wait:** Do not proceed with any other steps or scripts until the user has confirmed or provided corrections.

### 1. Installation & Health Check

Before performing operations, ensure the environment is ready:

- **Automation**: You MUST use `./scripts/check-health.sh` to verify namespaces, controllers, and CRDs. Do not use manual kubectl commands for health checks, as the script enforces standard formatting and context verification.

### 2. Resource Inventory & Discovery

To understand the current state of infrastructure:

- **Automation**: You MUST use `./scripts/inventory.sh` to get a summary table of all KCC resources. Do not use manual kubectl queries, as the script is optimized to securely discover all CRDs with context validation.

### 3. Manifest Structure

- All KCC resources belong to the `cnrm.cloud.google.com` API group.
- Use the `cnrm.cloud.google.com/project-id` annotation for cross-project resource management if not using Namespaced Mode.
- Always include `apiVersion`, `kind`, `metadata`, and `spec`.

### 4. Official Resource Reference (Agent Action)

When generating or troubleshooting manifests, you **must not guess** the API schema. Always consult the [Official Config Connector Reference](https://cloud.google.com/config-connector/docs/reference/overview) for the exact API version, kind, and required fields for the specific resource and cross reference with the official [github repository](https://github.com/GoogleCloudPlatform/k8s-config-connector/tree/master/config/crds/resources).

### 5. Troubleshooting Checklist

When a resource is not reconciling (check `kubectl get <kind> <name> -o yaml`):

- **Ready Condition**: Look for `status.conditions` where `type: Ready` and `status: "False"`.
- **Reason/Message**: Check the `reason` and `message` fields in the status conditions.
- **Consult the Guide**: Immediately check `./resources/troubleshooting-guide.md` for definitions of the error reason (e.g. `DependencyInvalid`, `ManagementConflict`) and follow its resolution steps.
- **Common Issues**:
  - Permissions: The KCC service account lacks IAM roles.
  - Quotas: GCP project quota exceeded.
  - Conflicts: Resource already exists or is managed by another tool.
  - Immutable Fields: Attempting to change a field that requires resource recreation. Look for "Update failed" errors related to immutable fields.
  - Reference Resolution: Check if the resource is waiting for a dependency (e.g., `referenced project not found`).

### 6. Impact Analysis (Ancillary Services)

Before modifying a resource (e.g., GCS Bucket, Pub/Sub Topic), verify whatElse depends on it:

- **Reference Search (Cluster-wide)**: Search for other KCC resources that reference the item.

  ```bash
  # Example: Find resources referencing a bucket named 'my-data-bucket'
  kubectl get-all -n <namespace> -o yaml | grep -C 5 "my-data-bucket"
  ```

- **IAM-based Analysis**: Check for IAM Service Accounts that have roles on the specific resource. A Cloud Run job or GKE Workload Identity might be using those permissions.
- **Common Ancillary Dependencies**:
  - **Storage Buckets**: Look for Cloud Run/GKE mounts (CSI), Cloud Functions triggers, or Dataflow jobs.
  - **Networks**: Check for Firewall rules, Forwarding rules, and GKE cluster assignments.
  - **IAM Policies**: Changing a policy might break access for external applications not managed by KCC.
- **Resource Graph**: Use `gcloud asset search-all-resources` to find resources that might have implicit links.

### 3. Policy Compliance & Best Practices

Evaluate KCC manifests against security and governance policies. The vetting tool supports three source modes:

- **Built-in Mode (Default)**: Uses the skill's high-fidelity `v1beta1` library (300+ Anthos constraints).
  - `Usage: ./scripts/vet-policy.sh <manifest-path>`
- **Remote Mode**: Clones and vets against an external Git repository.
  - `Usage: ./scripts/vet-policy.sh <manifest-path> <repo-url> [git-ref]`
  - ⚠️ **Note**: External libraries like the legacy GCP Policy Library may be out-of-date and cause schema validation errors with modern `gator`.
- **Local Mode**: Vets against a local directory of policies.
  - `Usage: ./scripts/vet-policy.sh <manifest-path> /path/to/local/policies`

**Interaction Model:**

1. Call `./scripts/vet-policy.sh` with the appropriate arguments.
2. Interpret the `=== KCC Best Practices ===` and `=== OPA/Gatekeeper ===` reports.
3. Supplement automated findings with manual review for specific security features not yet covered by OPA (e.g., `publicAccessPrevention: enforced`, `versioning: {enabled: true}`).

  ```bash
  # Run the skill's helper script (repo URL and branch are optional)
  ./scripts/vet-policy.sh manifest.yaml [policy-repo-url] [policy-ref]
  ```

## Skill Assets

This skill includes additional resources to streamline operations:

- **`scripts/`**: Automation scripts (e.g., `vet-policy.sh`, `bulk-export.sh`).
- **`examples/`**: Reference KCC manifests (e.g., `restricted-bucket.yaml`).
- **`resources/`**: Common templates, documentation snippets, and troubleshooting guides (e.g., `troubleshooting-guide.md`).

### 4. Safety Rails for Applying Manifests

Before applying any KCC manifest update to an existing resource, you MUST:

- **Verify Immutable Fields**: Call `./scripts/verify-immutable.sh <manifest-path>` to detect updates to fields (like `location`, `name`, `project-id`) that trigger destructive resource recreation.
- **Explain Impact**: If destructive changes are detected, you MUST warn the user and explain the downtime/data loss implications before requesting approval.

### 5. Emergency Recovery & Troubleshooting

If a resource is stuck in a "Deletion" or "Error" state:

- **Check for Abondon Flag**: Check if the resource has the `cnrm.cloud.google.com/deletion-policy: abandon` annotation. If it does, you will need to remove the annotation and then force delete the resource.
- **Force Delete**: Call `./scripts/force-delete.sh <kind> <name> [namespace]` to bypass Kubernetes finalizers and remove the resource from the cluster.
- **Orphan Warning**: Inform the user that force-deleting a KCC object may leave an orphaned resource in Google Cloud that requires manual cleanup.

### 6. Change Differentiation

When editing an existing resource, always generate a diff to summarize the change for reviewers or Git history:

- **Local Diff**:

  ```bash
  # Diff a local file against the cluster state
  kubectl diff -f modified-resource.yaml
  ```

- **Commit Summary Template**:

  ```text
  [KCC Change] Update <ResourceName> (<Kind>)
  - Field 'spec.foo' changed from 'X' to 'Y'
  - Impact: Ancillary service <ServiceName> will see updated <Config>
  ```

### 9. Best Practices

- **Namespaced Mode**: Prefer namespaced mode for better isolation.
- **Sensitive Data**: Use `spec.credential.secretRef` or similar for sensitive fields.
- **Resource Naming**: Use consistent naming conventions that match your Kubernetes/GCP standards.
- **Annotations**:
  - `cnrm.cloud.google.com/deletion-policy: abandon`: Keep GCP resource on KCC deletion.
  - `cnrm.cloud.google.com/state-into-spec: absent`: Prevents KCC from syncing GCP state back into the Kubernetes object (useful for avoiding reconciliation loops on fields like node counts).

## Common Resource Examples

### Compute Instance

```yaml
apiVersion: compute.cnrm.cloud.google.com/v1beta1
kind: ComputeInstance
metadata:
  name: instance-sample
  annotations:
    cnrm.cloud.google.com/project-id: "my-project-id"
spec:
  machineType: n1-standard-1
  zone: us-central1-a
  bootDisk:
    initializeParams:
      sourceImage: projects/debian-cloud/global/images/family/debian-11
  networkInterface:
    - networkRef:
        name: default
```

### Storage Bucket

```yaml
apiVersion: storage.cnrm.cloud.google.com/v1beta1
kind: StorageBucket
metadata:
  name: bucket-sample
spec:
  location: US
```

### Pub/Sub Topic & Subscription

```yaml
apiVersion: pubsub.cnrm.cloud.google.com/v1beta1
kind: PubSubTopic
metadata:
  name: order-events-topic
---
apiVersion: pubsub.cnrm.cloud.google.com/v1beta1
kind: PubSubSubscription
metadata:
  name: order-processor-sub
spec:
  topicRef:
    name: order-events-topic
  ackDeadlineSeconds: 30
```

Schritt 3: Inventartool implementieren

Erstellen Sie .agents/skills/kcc-ops/scripts/inventory.sh, um KCC-Ressourcen zu ermitteln:

#!/bin/bash
# List all resources in the cnrm.cloud.google.com group
KCC_KINDS=$(kubectl api-resources --no-headers | awk '/\.cnrm\.cloud\.google\.com/ {print $1}')
KCC_KINDS_CSV=$(echo "$KCC_KINDS" | paste -sd, -)

printf "%-40s %-30s %-10s %s\n" "KIND" "NAME" "READY" "STATUS/MESSAGE"
kubectl get "$KCC_KINDS_CSV" -A -o custom-columns="KIND:.kind,NAME:.metadata.name,READY:.status.conditions[?(@.type=='Ready')].status,MSG:.status.conditions[?(@.type=='Ready')].message" --ignore-not-found --no-headers

Schritt 4: Logik zur Überprüfung von Richtlinien hinzufügen

Erstellen Sie .agents/skills/kcc-ops/scripts/vet-policy.sh. Dieses Skript verwendet gator, um Manifeste anhand von OPA-Richtlinien zu überprüfen:

#!/bin/bash
MANIFEST=$1
SKILL_ROOT=$(dirname "$(dirname "$0")")
POLICY_SRC="$SKILL_ROOT/resources/policies"

echo "=== OPA/Gatekeeper Policy Vetting ==="
if command -v gator >/dev/null 2>&1; then
    gator test -f "$MANIFEST" -f "$POLICY_SRC/templates" -f "$POLICY_SRC/constraints"
else
    echo "Gator not found. Skipping OPA audit."
fi

Schritt 5: Schutz für unveränderliche Felder implementieren

Dies ist eine wichtige Sicherheitsvorkehrung. Erstellen Sie .agents/skills/kcc-ops/scripts/verify-immutable.sh:

#!/bin/bash
MANIFEST=$1
KIND=$(grep "^kind:" "$MANIFEST" | awk '{print $2}')
NAME=$(grep "name:" "$MANIFEST" | head -n 1 | awk '{print $2}')

# Check for changes in common immutable fields
IMMUTABLE_FIELDS=("location" "project-id" "name" "zone" "region")
TEMP_FILE=$(mktemp)
kubectl get "$KIND" "$NAME" -o yaml > "$TEMP_FILE" 2>/dev/null

for field in "${IMMUTABLE_FIELDS[@]}"; do
    NEW=$(grep "$field:" "$MANIFEST" | awk '{print $2}')
    OLD=$(grep "$field:" "$TEMP_FILE" | awk '{print $2}')
    if [ -n "$NEW" ] && [ -n "$OLD" ] && [ "$NEW" != "$OLD" ]; then
        echo "🚨 WARNING: Immutable field '$field' is changing! Potential resource recreation."
    fi
done
rm "$TEMP_FILE"

Schritt 6: Notfallwiederherstellung (erzwungenes Löschen)

Erstellen Sie .agents/skills/kcc-ops/scripts/force-delete.sh:

#!/bin/bash
KIND=$1; NAME=$2; NS=${3:-default}
echo "Removing finalizers for $KIND/$NAME in $NS..."
kubectl patch "$KIND" "$NAME" -n "$NS" -p '{"metadata":{"finalizers":null}}' --type=merge
kubectl delete "$KIND" "$NAME" -n "$NS" --wait=false

Schritt 7: Ressourcen abschließen

Machen Sie alle Skripts ausführbar:

chmod +x .agents/skills/kcc-ops/scripts/*.sh

10. Neues Skill testen

Starten Sie jetzt eine neue Unterhaltung und testen Sie Ihr Skill:

Ermittlung: @kcc-ops Show me all KCC resources in my cluster.
Compliance: Erstellen Sie eine Datei bucket.yaml mit einem StorageBucket. Fragen Sie: @kcc-ops Vet my bucket.yaml manifest.
Sicherheit: Versuchen Sie, den location eines vorhandenen Buckets in bucket.yaml zu aktualisieren. Fragen Sie: @kcc-ops Verify my bucket.yaml for immutable changes.

Beachten Sie, wie der KI-Agent auf intelligente Weise das richtige Skript auswählt und die „Goldene Regel“ aus Ihrer SKILL.md-Datei befolgt.

11. KI-Agent sichern

Einem KI-Agenten Zugriff auf Ihr Terminal zu gewähren ist leistungsstark, erfordert aber Kontrollen.

Rufen Sie Antigravity – Einstellungen – Terminal auf und sehen Sie sich die Zulassungsliste und die Sperrliste an.

Zulassungsliste: Fügen Sie hier ls, kubectl get und Ihre Skill-Skripts hinzu.
Sperrliste: Fügen Sie sudo, rm -rf oder andere destruktive Befehle hinzu, damit der KI-Agent IMMER um Erlaubnis fragt.

12. Fazit

Das wars! Sie haben Antigravity installiert und ein hochgenaues KCC Operations-Skill erstellt.

Sie haben Folgendes gelernt:

Wie Sie den KI-Agenten mit benutzerdefinierten Bash-Tools erweitern.
Wie Sie operative „Goldene Regeln“ in einer SKILL.md-Datei codieren.
Wie Sie Sicherheitsvorkehrungen für die komplexe Infrastrukturverwaltung treffen.

Wie geht es weiter?

Erweitern Sie den Ordner resources/policies mit weiteren OPA-Einschränkungen oder fügen Sie ein check-health.sh-Skript hinzu, um die Bereitschaftsprüfungen für Cluster zu automatisieren.