OpenClawDocs
Na tej stronie

Na tej stronie

View as MarkdownView this page as plain textOpen in ChatGPTAsk questions about this pageOpen in ClaudeAsk questions about this page

Hosting

Kubernetes

Minimalny punkt wyjścia do uruchamiania OpenClaw w Kubernetes, a nie wdrożenie gotowe do użycia produkcyjnego. Obejmuje podstawowe zasoby i jest przeznaczony do dostosowania do Twojego środowiska.

Dlaczego nie Helm

OpenClaw to pojedynczy kontener z kilkoma plikami konfiguracyjnymi. Istotne możliwości dostosowania dotyczą zawartości agenta (plików Markdown, Skills i nadpisań konfiguracji), a nie szablonów infrastruktury. Kustomize obsługuje nakładki bez narzutu związanego z wykresem Helm. Jeśli wdrożenie stanie się bardziej złożone, możesz utworzyć wykres Helm oparty na tych manifestach.

Czego potrzebujesz

  • Działającego klastra Kubernetes (AKS, EKS, GKE, k3s, kind, OpenShift itp.)
  • Narzędzia kubectl połączonego z klastrem
  • Klucza API co najmniej jednego dostawcy modeli

Szybki start

bash
# Zastąp nazwą dostawcy: ANTHROPIC, GEMINI, OPENAI lub OPENROUTERexport <PROVIDER>_API_KEY="..."./scripts/k8s/deploy.sh kubectl port-forward svc/openclaw 18789:18789 -n openclawopen http://localhost:18789

Skrypt deploy.sh domyślnie tworzy uwierzytelnianie za pomocą tokenu. Pobierz wygenerowany token Gateway dla interfejsu sterowania:

bash
kubectl get secret openclaw-secrets -n openclaw -o jsonpath='{.data.OPENCLAW_GATEWAY_TOKEN}' | base64 -d

Na potrzeby lokalnego debugowania polecenie ./scripts/k8s/deploy.sh --show-token wyświetla token po wdrożeniu.

Testowanie lokalne za pomocą Kind

Jeśli nie masz klastra, utwórz go lokalnie za pomocą narzędzia Kind:

bash
./scripts/k8s/create-kind.sh           # automatycznie wykrywa docker lub podman./scripts/k8s/create-kind.sh --delete  # usuwa środowisko

Następnie wykonaj wdrożenie w zwykły sposób za pomocą polecenia ./scripts/k8s/deploy.sh.

Krok po kroku

1) Wdróż

Opcja A: klucz API w środowisku (jeden krok)

bash
# Zastąp nazwą dostawcy: ANTHROPIC, GEMINI, OPENAI lub OPENROUTERexport <PROVIDER>_API_KEY="..."./scripts/k8s/deploy.sh

Skrypt tworzy obiekt Kubernetes Secret z kluczem API i automatycznie wygenerowanym tokenem Gateway, a następnie wykonuje wdrożenie. Jeśli obiekt Secret już istnieje, zachowuje bieżący token Gateway oraz klucze dostawców, które nie są zmieniane.

Opcja B: utwórz sekret osobno

bash
export <PROVIDER>_API_KEY="..."./scripts/k8s/deploy.sh --create-secret./scripts/k8s/deploy.sh

Dodaj --show-token do dowolnego z tych poleceń, aby na potrzeby lokalnego testowania wyświetlić token na standardowym wyjściu.

2) Uzyskaj dostęp do Gateway

bash
kubectl port-forward svc/openclaw 18789:18789 -n openclawopen http://localhost:18789

Co zostanie wdrożone

text
Przestrzeń nazw: openclaw (konfigurowalna za pomocą OPENCLAW_NAMESPACE)├── Deployment/openclaw        # Pojedynczy pod, kontener inicjujący + Gateway├── Service/openclaw           # ClusterIP na porcie 18789├── PersistentVolumeClaim      # 10 GiB na stan i konfigurację agenta├── ConfigMap/openclaw-config  # openclaw.json + AGENTS.md└── Secret/openclaw-secrets    # Token Gateway + klucze API

Dostosowywanie

Instrukcje agenta

Edytuj plik AGENTS.md w scripts/k8s/manifests/configmap.yaml i ponownie wykonaj wdrożenie:

bash
./scripts/k8s/deploy.sh

Konfiguracja Gateway

Edytuj plik openclaw.json w scripts/k8s/manifests/configmap.yaml. Pełne informacje znajdziesz w dokumentacji konfiguracji Gateway.

Dodawanie dostawców

Uruchom ponownie po wyeksportowaniu dodatkowych kluczy:

bash
export ANTHROPIC_API_KEY="..."export OPENAI_API_KEY="..."./scripts/k8s/deploy.sh --create-secret./scripts/k8s/deploy.sh

Istniejące klucze dostawców pozostają w obiekcie Secret, chyba że je nadpiszesz.

Możesz też bezpośrednio zmodyfikować obiekt Secret:

bash
kubectl patch secret openclaw-secrets -n openclaw \  -p '{"stringData":{"<PROVIDER>_API_KEY":"..."}}'kubectl rollout restart deployment/openclaw -n openclaw

Niestandardowa przestrzeń nazw

bash
OPENCLAW_NAMESPACE=my-namespace ./scripts/k8s/deploy.sh

Niestandardowy obraz

Edytuj pole image w scripts/k8s/manifests/deployment.yaml:

yaml
image: ghcr.io/openclaw/openclaw:slim # główny; oficjalny mirror Docker Hub: openclaw/openclaw

Udostępnianie poza przekierowaniem portów

Domyślne manifesty wiążą Gateway z local loopback wewnątrz poda. Działa to z poleceniem kubectl port-forward, ale nie ze ścieżką Kubernetes Service ani Ingress, która musi uzyskać bezpośredni dostęp do adresu IP poda.

Aby udostępnić Gateway przez Ingress lub moduł równoważenia obciążenia:

  • Zmień powiązanie Gateway w scripts/k8s/manifests/configmap.yaml z loopback na powiązanie inne niż local loopback, zgodne z modelem wdrożenia.
  • Pozostaw włączone uwierzytelnianie Gateway i użyj odpowiedniego punktu wejścia z terminacją TLS.
  • Skonfiguruj interfejs sterowania do dostępu zdalnego przy użyciu obsługiwanego modelu zabezpieczeń sieciowych (na przykład HTTPS/Tailscale Serve oraz jawnie dozwolonych źródeł, gdy jest to wymagane).

Ponowne wdrożenie

bash
./scripts/k8s/deploy.sh

Spowoduje to zastosowanie wszystkich manifestów i ponowne uruchomienie poda w celu uwzględnienia zmian konfiguracji lub sekretów.

Usuwanie wdrożenia

bash
./scripts/k8s/deploy.sh --delete

Spowoduje to usunięcie przestrzeni nazw i wszystkich znajdujących się w niej zasobów, w tym PVC.

Uwagi dotyczące architektury

  • Gateway domyślnie wiąże się z local loopback wewnątrz poda, dlatego dołączona konfiguracja jest przeznaczona dla polecenia kubectl port-forward.
  • Brak zasobów o zasięgu klastra; wszystko znajduje się w jednej przestrzeni nazw.
  • Wzmocnienie zabezpieczeń: readOnlyRootFilesystem, możliwości drop: ALL, użytkownik inny niż root (UID 1000).
  • Domyślna konfiguracja utrzymuje interfejs sterowania na bezpieczniejszej ścieżce dostępu lokalnego: powiązanie z local loopback oraz kubectl port-forward do http://127.0.0.1:18789.
  • Jeśli rozszerzysz dostęp poza localhost, użyj obsługiwanego modelu zdalnego: HTTPS/Tailscale wraz z odpowiednim powiązaniem Gateway i ustawieniami źródeł interfejsu sterowania.
  • Sekrety są generowane w katalogu tymczasowym i stosowane bezpośrednio w klastrze; żadne dane poufne nie są zapisywane w kopii roboczej repozytorium.

Struktura plików

text
scripts/k8s/├── deploy.sh                   # Tworzy przestrzeń nazw i sekret, wdraża za pomocą kustomize├── create-kind.sh              # Lokalny klaster Kind (automatycznie wykrywa docker/podman)└── manifests/    ├── kustomization.yaml      # Baza Kustomize    ├── configmap.yaml          # openclaw.json + AGENTS.md    ├── deployment.yaml         # Specyfikacja poda ze wzmocnionymi zabezpieczeniami    ├── pvc.yaml                # 10 GiB trwałej pamięci masowej    └── service.yaml            # ClusterIP na porcie 18789

Powiązane

Was this useful?