Преди две седмици OpenClaw имаше 9 000 звезди в GitHub. Днес има 183 000. Междувременно се появи цяла индустрия. ClawSimple, Kilo Claw, StartClaw, ShipClaw, GetClaw.ai, LobsterLair. Един сайт за сравнение брои 33 доставчика и списъкът продължава да расте. OpenClaw обвивки нахлуват в TrustMRR. DigitalOcean пусна разгръщане с едно кликване. Cloudflare го адаптира като Workers среда за изпълнение. Хората купуваха Mac Mini-та, за да управляват лични AI агенти вкъщи.

Ако искате да хоствате сами в облака, най-честата конфигурация е VPS от Hetzner за 5 долара с 2 vCPU и 4 GB RAM, Docker Compose и API ключ. Стартирайте съветника за настройка, свържете го с Anthropic или OpenRouter, свържете Telegram. Готово за тридесет минути. Или купете Mac Mini, сложете го под бюрото си и го наречете Вашият личен JARVIS. M4 консумира седем вата в покой и служи като локална машина за извод, ако изберете модела Pro с 64 GB.

И двата варианта работят за един агент. Но когато започнах да изграждам OpenClaw.rocks, целта беше да предложа най-надеждния и сигурен начин за хостване на OpenClaw в мащаб, като същевременно запазя лекотата за потребителя. Това изискваше различна основа.

Защо избрах Kubernetes

Преди управлявах блокчейн инфраструктура в Binance, включително защитата на Bitcoin възлите. Когато работата Ви е да поддържате високостойностни натоварвания изолирани, наблюдаеми и възстановими в мащаб, развивате силни убеждения за това как трябва да работи инфраструктурата. Kubernetes е това, на което имам доверие за целта.

OpenClaw е приложение за един потребител. Това е личен асистент, а не многопотребителска платформа. Ако искате да управлявате агенти за десет души, имате нужда от десет инстанции. За сто души, сто инстанции. Всяка със собствена конфигурация, собствени тайни, собствено хранилище, собствени мрежови граници. Само изискванията за изолация изключват всичко по-малко от подходяща оркестрация на контейнери.

Няма да твърдя, че Kubernetes е прост. Не е. За един агент е абсурдно пресилено. Но за управлението на много агенти за много хора решава проблеми, които нищо друго не решава толкова добре. И мисля, че всяка компания, която в крайна сметка ще управлява OpenClaw агенти в мащаб, ще стигне до същото заключение.

Изолация, която наистина се прилага. Всеки агент работи в собствен namespace с NetworkPolicy, която по подразбиране отказва всичко. Агент А не може да комуникира с Агент Б. Агент Б не може да достъпи тайните на Агент А. Това не е конвенция или добра практика. Прилага се от средата за изпълнение на контейнери и CNI. На споделен VPS с Docker Compose мрежовата изолация между контейнери изисква ръчни правила iptables, които никой не поддържа.

Лимити на ресурси, които предотвратяват каскадни повреди. OpenClaw агент с автоматизация на браузъра може да консумира 3 CPU ядра и 6 GB памет, ако му се позволи. На VPS с четири агента един излязъл извън контрол Chromium процес убива останалите три. Kubernetes налага лимити на CPU и памет за контейнер. Един агент, който достига тавана си, не засяга съседите си.

Самовъзстановяване без SSH. Когато процес на VPS се срине, нещо трябва да го забележи и да го рестартира. systemd прави това, но само за хоста. Docker Compose има политики за рестартиране, но те не покриват десетте други неща, които могат да се объркат: OOM убивания, повреди на възли, проблеми с хранилището. Kubernetes рестартира повредени контейнери, преразпределя подове, когато възлите паднат, и изпълнява health проби, които засичат проблеми на ниво приложение, а не само прекратяване на процеси.

Мащабиране без гадаене. Управляваме натоварванията на агентите на специален пул от възли. Когато търсенето нараства, cluster autoscaler добавя възли. Когато намалява, възлите се изпразват и премахват. Не поддържаме флота от предварително подготвени VPS инстанции, надявайки се, че сме преценили правилно размера. Инфраструктурата съответства на реалното натоварване.

Декларативно състояние без отклонение. Цялата конфигурация на един агент живее в една custom resource: моделът, каналите, лимитите на ресурси, мрежовите правила, хранилището, контекстът на сигурност. Няма SSH история за възстановяване, няма ръчни редакции за проследяване, няма конфигурационно отклонение между това, което мислите, че работи, и което наистина работи.

Нищо от това няма значение за един агент на една машина. Всичко има значение, когато носите отговорност за надеждната работа на агентите на други хора.

Операторът

Kubernetes предоставя градивните елементи. Операторът е това, което ги прави използваеми.

Без Оператор разгръщането на OpenClaw инстанция на Kubernetes означава ръчно писане на единадесет ресурса: Deployment, Service, ConfigMap, PVC, ServiceAccount, Role, RoleBinding, NetworkPolicy, PodDisruptionBudget, Ingress, ServiceMonitor. С Оператор е нужен само един:

apiVersion: openclaw.rocks/v1alpha1
kind: OpenClawInstance
metadata:
  name: my-agent
spec:
  envFrom:
    - secretRef:
        name: my-api-keys
  storage:
    persistence:
      enabled: true
      size: 10Gi

Операторът следи тази custom resource и създава всичко останало. Това е контролен цикъл: при всяка промяна на който и да е управляван ресурс и поне веднъж на пет минути като предпазна мрежа, сравнява желаното състояние с реалното и изравнява разликата. Ако някой изтрие NetworkPolicy, тя се връща. Ако Deployment се отклони, бива коригиран. Изтрийте custom resource и owner reference-ите каскадно изпълняват почистването. Никакви осиротели Services, никакви останали PVCs.

Днес го правим с отворен код: github.com/OpenClaw-rocks/k8s-operator.

Сигурност по подразбиране, а не от чеклист

SecurityScorecard миналата седмица откри 135 000 OpenClaw инстанции, изложени на публичния интернет. CVE-2026-25253 демонстрира изпълнение на отдалечен код с едно кликване чрез ексфилтрация на gateway токени. Gartner препоръча на организациите да го блокират изцяло. В регистъра на ClawHub бяха открити 341 злонамерени умения.

Такава е реалността на управлението на AI агенти през 2026 година. Конфигурацията по подразбиране на OpenClaw слуша на 0.0.0.0 без удостоверяване. На VPS без правилно конфигурирана защитна стена сте на едно сканиране на портове разстояние от това да дадете на непознат shell достъп до Вашия сървър. Описахме пълния обхват на кризата със сигурността и защо дори gateway токен не е достатъчен.

Операторът възприема обратния подход. Сигурността е структурна, а не незадължителна:

  • Не-root по подразбиране. UID 1000, всички Linux capabilities премахнати, seccomp RuntimeDefault. Валидиращ webhook отхвърля всяка спецификация, която задава runAsUser: 0. Трябва да премахнете webhook-а, за да работите като root.
  • Мрежова изолация по подразбиране. NetworkPolicy с отказ на всичко по подразбиране на всяка инстанция. Входящ: само същият namespace. Изходящ: само DNS и HTTPS. Всичко останало е блокирано, освен ако не го отворите изрично.
  • RBAC с минимални привилегии. Всяка инстанция получава собствен ServiceAccount с Role, който дава само get и watch на собствената ConfigMap. Агент не може да чете тайните, конфигурацията или състоянието на друг агент.
  • Самият Оператор работи като UID 65532 (distroless nonroot), файлова система само за четене, всички capabilities премахнати, HTTP/2 деактивиран за смекчаване на CVE-2023-44487.

Всичко това е активно по подразбиране. Получавате го без да мислите за него.

Автоматизация на браузъра като sidecar

Агентите на OpenClaw могат да сърфират в мрежата. На VPS това означава да се стартира Chromium процес до агента и да се надяваме, че няма да се борят за ресурси. Операторът управлява това като правилен sidecar:

spec:
  chromium:
    enabled: true
    resources:
      requests:
        cpu: "250m"
        memory: "512Mi"
      limits:
        cpu: "1000m"
        memory: "2Gi"

Операторът добавя контейнер Browserless Chromium към пода, свързва Chrome DevTools Protocol на порт 9222, инжектира CHROMIUM_URL=ws://localhost:9222 в основния контейнер и дава на Chromium собствен контекст за сигурност (UID 999, capabilities премахнати), собствени лимити на ресурси и поддържан от паметта /dev/shm. Двата контейнера комуникират през localhost вътре в пода. Без мрежов скок, без допълнителен Service, без излагане на сигурността. На OpenClaw.rocks активираме Chromium sidecar по подразбиране за всяка инстанция.

Какво има в хранилището

Написан на Go 1.24 с controller-runtime (Kubebuilder шаблон). Лиценз Apache 2.0.

  • Пълна CRD със 127 KB OpenAPI валидационна схема
  • Helm Chart (също като OCI артефакт на GHCR)
  • Kustomize наслагвания за тези, които ги предпочитат
  • Grafana табло и Prometheus сигнали в docs/monitoring/
  • E2E тестове на Kind в CI
  • Мулти-архитектурни компилации (amd64/arm64)

Операторът е също така включен в OperatorHub и Artifact Hub, така че можете да го откриете и инсталирате чрез регистрите, които вече използвате.

Инсталация:

helm install openclaw-operator \
  oci://ghcr.io/openclaw-rocks/charts/openclaw-operator \
  --namespace openclaw-operator-system \
  --create-namespace

Разгръщане на агент:

apiVersion: openclaw.rocks/v1alpha1
kind: OpenClawInstance
metadata:
  name: my-agent
spec:
  config:
    raw:
      agents:
        defaults:
          model:
            primary: "anthropic/claude-sonnet-4-20250514"
  envFrom:
    - secretRef:
        name: my-api-keys
  chromium:
    enabled: true
  storage:
    persistence:
      enabled: true

Автоматизация на браузъра, постоянно хранилище, мрежова изолация, наблюдение на здравето, автоматични разгръщания на конфигурации. Един ресурс. kubectl apply.

Защо с отворен код

Създадох този Оператор, за да реша собствения си проблем. Управлявам хостинг платформа за OpenClaw агенти и имах нужда от инструменти за Kubernetes с продукционно качество. Операторът е резултат от тази работа.

Но също така смятам, че всяка компания, управляваща OpenClaw агенти в мащаб, в крайна сметка ще стигне до Kubernetes и ще се сблъска със същите проблеми като мен: настройките за сигурност по подразбиране, свързването на NetworkPolicy, Chromium sidecar, разгръщанията на конфигурации. Екосистемата е на две седмици и вече е фрагментирана. Всеки решава тези проблеми самостоятелно.

Разходите за създаване на софтуер се приближават до нула. И както аргументирах в OpenClaw е новият Linux, откритостта предотвратява фрагментацията. Операторът не е моята защита от конкуренция. Ако нещо е, то е марката и доверието, което изграждам, споделяйки работа като тази. И ако дори това не устои, аз се забавлявам, създавайки, пишейки и споделяйки. Това е достатъчно. Запазването на Оператора като собственически би означавало, че всеки инфраструктурен екип преоткрива същите капани, които аз открих. Това е разхищение, а не конкурентно предимство.

Използваме този Оператор в продукция. Всеки агент на OpenClaw.rocks минава през него.

Кодът е на github.com/OpenClaw-rocks/k8s-operator. Проблеми и заявки за промени са добре дошли.

Ако предпочитате да не го управлявате сами, точно за това е OpenClaw.rocks.