Чому не Helm?
OpenClaw — це один контейнер із кількома файлами конфігурації. Найважливіша кастомізація міститься у вмісті агентів (Markdown-файли, Skills, перевизначення конфігурації), а не в шаблонізації інфраструктури. Kustomize обробляє оверлеї без накладних витрат Helm chart. Якщо ваше розгортання стане складнішим, Helm chart можна накласти поверх цих маніфестів.Що потрібно
- Запущений кластер Kubernetes (AKS, EKS, GKE, k3s, kind, OpenShift тощо)
kubectl, підключений до вашого кластера- API-ключ принаймні для одного постачальника моделей
Швидкий старт
./scripts/k8s/deploy.sh --show-token виводить токен після розгортання.
Локальне тестування з Kind
Якщо у вас немає кластера, створіть його локально за допомогою Kind:./scripts/k8s/deploy.sh.
Крок за кроком
1) Розгортання
Варіант A — API-ключ у середовищі (один крок):--show-token з будь-якою командою, якщо хочете вивести токен у stdout для локального тестування.
2) Доступ до Gateway
Що розгортається
Кастомізація
Інструкції агента
ВідредагуйтеAGENTS.md у scripts/k8s/manifests/configmap.yaml і повторно розгорніть:
Конфігурація Gateway
Відредагуйтеopenclaw.json у scripts/k8s/manifests/configmap.yaml. Повну довідку див. у конфігурації Gateway.
Додавання постачальників
Повторно запустіть із додатковими експортованими ключами:Користувацький namespace
Користувацький образ
Відредагуйте полеimage у scripts/k8s/manifests/deployment.yaml:
Відкриття доступу поза port-forward
Стандартні маніфести прив’язують Gateway до loopback усередині pod. Це працює зkubectl port-forward, але не працює з Kubernetes Service або шляхом Ingress, якому потрібно досягати IP pod.
Якщо ви хочете відкрити Gateway через Ingress або балансувальник навантаження:
- Змініть прив’язку Gateway у
scripts/k8s/manifests/configmap.yamlзloopbackна не-loopback-прив’язку, яка відповідає вашій моделі розгортання - Залиште автентифікацію Gateway увімкненою та використовуйте належну TLS-терміновану точку входу
- Налаштуйте Control UI для віддаленого доступу з використанням підтримуваної моделі веббезпеки (наприклад, HTTPS/Tailscale Serve і явні дозволені origins, коли це потрібно)
Повторне розгортання
Видалення
Архітектурні примітки
- Gateway за замовчуванням прив’язується до loopback усередині pod, тому включене налаштування призначене для
kubectl port-forward - Немає ресурсів на рівні кластера — усе розміщено в одному namespace
- Безпека:
readOnlyRootFilesystem, можливостіdrop: ALL, користувач без root-прав (UID 1000) - Стандартна конфігурація тримає Control UI на безпечнішому шляху локального доступу: прив’язка до loopback плюс
kubectl port-forwardдоhttp://127.0.0.1:18789 - Якщо ви виходите за межі доступу з localhost, використовуйте підтримувану віддалену модель: HTTPS/Tailscale плюс відповідну прив’язку Gateway і налаштування origin для Control UI
- Секрети генеруються в тимчасовій директорії та застосовуються безпосередньо до кластера — жоден секретний матеріал не записується в checkout репозиторію