Opanowywanie operacji KCC za pomocą Google Antigravity

1. Wprowadzenie

Z tego ćwiczenia dowiesz się więcej o Google Antigravity (w dalszej części dokumentu nazywanej Antigravity), opartej na agentach platformie dla programistów, która wprowadza środowisko IDE w erę agentów.

W przeciwieństwie do standardowych asystentów kodowania, którzy tylko uzupełniają wiersze, Antigravity zapewnia „centrum dowodzenia” do zarządzania autonomicznymi agentami, którzy mogą planować, kodować, a nawet przeglądać internet, aby Ci pomóc.

Antigravity to platforma zaprojektowana z myślą o agentach. Zakłada ona, że AI to nie tylko narzędzie do pisania kodu, ale autonomiczny podmiot zdolny do planowania, wykonywania, weryfikowania i powtarzania złożonych zadań inżynieryjnych przy minimalnej ingerencji człowieka.

Czego się nauczysz

• Instalowanie i konfigurowanie Antigravity.
• Poznaj kluczowe pojęcia związane z Antigravity, takie jak Menedżer agentów, Edytor, Przeglądarka i inne.
• Tworzenie od podstaw umiejętności KCC Ops na potrzeby środowiska produkcyjnego, aby bezpiecznie i zgodnie z przepisami zarządzać zasobami Google Cloud.

Czego potrzebujesz

Obecnie Antigravity jest dostępna w wersji przedpremierowej na osobistych kontach Gmail. Obejmuje bezpłatny limit wykorzystania modeli najwyższej jakości.

Antigravity musi być zainstalowana lokalnie w systemie. Produkt jest dostępny na komputerach Mac, Windows i wybranych dystrybucjach Linuksa. Oprócz własnego urządzenia potrzebujesz:

• konto Gmail (osobiste konto Gmail);
• Konto Google Cloud i projekt Google Cloud
• przeglądarka internetowa, np. Chrome, obsługująca konsolę Google Cloud i Cloud Shell;

2. Konfiguracja i wymagania

Konfiguracja projektu

Tworzenie projektu Google Cloud

1. W konsoli Google Cloud na stronie selektora projektu wybierz lub utwórz projekt w chmurze Google.
2. Sprawdź, czy w projekcie Cloud włączone są płatności. Dowiedz się, jak sprawdzić, czy w projekcie są włączone płatności.

To ćwiczenie jest przeznaczone dla użytkowników i deweloperów na wszystkich poziomach zaawansowania (w tym dla początkujących).

3. Instalacja

Jeśli nie masz jeszcze zainstalowanej aplikacji Antigravity, zacznij od jej instalacji. Obecnie usługa jest dostępna w wersji podglądowej i możesz zacząć z niej korzystać na osobistym koncie Gmail.

Otwórz stronę pobrań i kliknij odpowiednią wersję systemu operacyjnego. Uruchom instalator aplikacji i zainstaluj ją na komputerze. Po zakończeniu instalacji uruchom aplikację Antigravity.

Kluczowe kroki podczas konfiguracji:

• Wybierz proces konfiguracji: w tym przypadku zalecamy rozpoczęcie od nowa.
• Tworzenie oparte na opiniach (zalecane): wybierz tę opcję. Umożliwia to agentowi podjęcie decyzji i wrócenie do użytkownika w celu uzyskania zgody, co ma kluczowe znaczenie w przypadku operacji infrastrukturalnych.

Następnie skonfiguruj Edytor i zaloguj się w Google. Na koniec zaakceptuj Warunki korzystania z usługi.

4. Konfiguracja infrastruktury: GKE i Config Connector

Zanim zaczniesz tworzyć umiejętność, musisz mieć środowisko Google Cloud z ręcznie zainstalowanym i skonfigurowanym w trybie przestrzeni nazw Config Connector (KCC). Umożliwia to zarządzanie zasobami GCP jako obiektami Kubernetes.

Krok 0. Przygotuj środowisko

1. Wymagania wstępne dotyczące klastra

Utwórz nowy klaster GKE z włączonymi niezbędnymi funkcjami:

# 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. Zainstaluj operatora Config Connector

Operator dba o aktualność instalacji.

# 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. Konfigurowanie trybu przestrzeni nazw

Utwórz zasób ConfigConnector, aby określić tryb działania.

# 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. Tworzenie tożsamości i przestrzeni nazw

W tym module użyjemy przestrzeni nazw default i dedykowanego konta usługi Google (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. Skonfiguruj przestrzeń nazw

Utwórz ConfigConnectorContext, aby obserwować przestrzeń nazw.

# 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. Weryfikacja instalacji

Poczekaj, aż kontroler będzie gotowy do użycia przestrzeni nazw default.

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. Menedżer agentów: Centrum dowodzenia

Antigravity korzysta z otwartego kodu źródłowego Visual Studio Code (VS Code), ale radykalnie zmienia sposób obsługi, aby priorytetem było zarządzanie agentami, a nie edytowanie tekstu. Interfejs jest podzielony na 2 główne okna: Editor i Agent Manager.

Menedżer agentów

Po uruchomieniu Antigravity użytkownik zwykle widzi Menedżera agentów. Ten interfejs działa jako panel centrum dowodzenia. Został on zaprojektowany do orkiestracji na wysokim poziomie, umożliwiając programistom tworzenie, monitorowanie i obsługiwanie wielu agentów działających asynchronicznie w różnych obszarach roboczych lub zadaniach.

W tym przypadku deweloper pełni rolę architekta. Określają one cele wysokiego poziomu. Każde z tych żądań powoduje utworzenie dedykowanej instancji agenta. Interfejs użytkownika zawiera wizualizację tych równoległych ścieżek pracy, wyświetlając stan każdego agenta, artefakty, które wygenerował (plany, wyniki, różnice), oraz wszelkie oczekujące prośby o zatwierdzenie przez człowieka.

6. Antigravity Browser & Artifacts

Antigravity tworzy artefakty podczas planowania i wykonywania pracy. Są to pliki Markdown, diagramy architektury, obrazy, nagrania z przeglądarki i różnice w kodzie.

Artefakty rozwiązują problem „luki w zaufaniu”

Gdy agent zgłaszał, że „błąd został naprawiony”, deweloper musiał wcześniej przeczytać kod, aby to sprawdzić. W przypadku Antigravity agent tworzy artefakt, aby to udowodnić.

Artefakty

Oto główne artefakty generowane przez Antigravity:

• Task Lists: uporządkowany plan wygenerowany przed napisaniem kodu.
• Implementation Plan: zaprojektowane zmiany ze szczegółami technicznymi;
• Walkthrough: podsumowanie zmian i sposób ich testowania.
• Browser Recordings: nagrania wideo sesji przeglądarki na potrzeby weryfikacji interfejsu.

Antigravity Browser

Gdy agent musi wejść w interakcję z siecią, wywołuje podagenta przeglądarki. Ten subagent może klikać, przewijać, pisać i odczytywać logi konsoli. Korzysta ze specjalistycznego modelu, który działa na stronach otwartych w przeglądarce zarządzanej przez Antigravity.

7. Widok edytora

Edytor zachowuje znajomy interfejs VS Code. Obejmuje standardowy eksplorator plików, wyróżnianie składni i ekosystem rozszerzeń.

Najważniejsze funkcje edytora kluczy:

• Automatyczne uzupełnianie: inteligentne sugestie akceptowane przez naciśnięcie klawisza Tab.
• Karta importu: sugeruje dodanie brakujących zależności.
• Polecenia (Cmd + I): wywołuj uzupełnianie w tekście za pomocą języka naturalnego.
• Panel boczny agentaCmd + L: włącz panel agenta, aby zadawać pytania lub odwoływać się do plików za pomocą @.

8. Przekazywanie opinii

Podstawą Antigravity jest możliwość łatwego zbierania opinii. Te artefakty umożliwiają przekazywanie informacji zwrotnych agentowi w komentarzach w stylu Dokumentów Google.

Za każdym razem, gdy dodajesz komentarz do planu lub zadania, pamiętaj, aby go przesłać. Dzięki temu agent będzie działać w wybranym przez Ciebie kierunku.

9. Tworzenie umiejętności KCC Ops

Teraz, gdy znasz już platformę, możemy utworzyć umiejętność KCC Ops.

Kubernetes Config Connector (KCC) umożliwia zarządzanie zasobami GCP jako obiektami K8s. Wymaga jednak zabezpieczeń, które zapobiegają dryfowi konfiguracji, naruszeniom zgodności i przypadkowemu ponownemu tworzeniu zasobów.

Krok 1. Określ strukturę umiejętności

W katalogu głównym obszaru roboczego utwórz strukturę katalogów dla umiejętności:

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

Krok 2. Utwórz plik SKILL.md (mózg)

SKILL.md definiuje metadane i podstawową „złotą zasadę” agenta. Utwórz .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
```

Krok 3. Wdróż narzędzie do zarządzania asortymentem

Utwórz .agents/skills/kcc-ops/scripts/inventory.sh, aby odkryć zasoby KCC:

#!/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

Krok 4. Dodaj logikę weryfikacji zasad

Utwórz .agents/skills/kcc-ops/scripts/vet-policy.sh. Ten skrypt będzie używać gator do sprawdzania plików manifestu pod kątem zgodności z zasadami OPA:

#!/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

Krok 5. Wdróż zabezpieczenie pól niezmiennych

Jest to kluczowy element zabezpieczeń. Utwórz .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"

Krok 6. Przywracanie awaryjne (wymuszone usunięcie)

Utwórz .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

Krok 7. Zakończ dodawanie zasobów

Ustaw wszystkie skrypty jako wykonywalne:

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

10. Testowanie nowej umiejętności

Teraz rozpocznij nową rozmowę i sprawdź swoje umiejętności:

1. Odkrywanie: @kcc-ops Show me all KCC resources in my cluster.
2. Zgodność: utwórz plik bucket.yaml z zasobnikiem StorageBucket. Zapytaj: @kcc-ops Vet my bucket.yaml manifest.
3. Bezpieczeństwo: spróbuj zaktualizować location istniejącego zasobnika w bucket.yaml. Zapytaj: @kcc-ops Verify my bucket.yaml for immutable changes.

Zwróć uwagę, jak agent inteligentnie wybiera odpowiedni skrypt i przestrzega „złotej zasady” z SKILL.md.

11. Zabezpieczanie agenta

Udostępnienie agentowi AI dostępu do terminala jest bardzo przydatne, ale wymaga kontroli.

Otwórz Antigravity – Ustawienia – Terminal i zapoznaj się z listą dozwolonych i listą zablokowanych.

• Lista dozwolonych: dodaj tutaj ls, kubectl get i skrypty umiejętności.
• Lista zabronionych: dodaj polecenia sudo, rm -rf lub inne polecenia destrukcyjne, aby mieć pewność, że agent ZAWSZE będzie prosić o pozwolenie.

12. Podsumowanie

Gratulacje! Z instalowania Antigravity przechodzisz do tworzenia zaawansowanej umiejętności KCC Operations.

Wiesz już:

• Jak rozszerzyć możliwości agenta za pomocą niestandardowych narzędzi bash.
• Jak zakodować operacyjne „złote zasady” w SKILL.md.
• Jak zapewnić zabezpieczenia w przypadku złożonego zarządzania infrastrukturą.

Co dalej?

Rozwiń folder resources/policies, dodając więcej ograniczeń OPA, lub dodaj skrypt check-health.sh, aby zautomatyzować sprawdzanie gotowości klastra.