Skip to main content
Kubernetes पर OpenClaw चलाने के लिए एक न्यूनतम शुरुआती आधार, न कि उत्पादन के लिए तैयार परिनियोजन। इसमें मुख्य संसाधन शामिल हैं और इसे आपके परिवेश के अनुसार अनुकूलित किया जाना है।

Helm क्यों नहीं

OpenClaw कुछ कॉन्फ़िगरेशन फ़ाइलों वाला एकल कंटेनर है। उपयोगी अनुकूलन एजेंट सामग्री (Markdown फ़ाइलें, skills, कॉन्फ़िगरेशन ओवरराइड) में होता है, न कि अवसंरचना टेम्पलेटिंग में। Kustomize, Helm चार्ट के अतिरिक्त भार के बिना ओवरले संभालता है। यदि आपका परिनियोजन अधिक जटिल हो जाए, तो इन मैनिफ़ेस्ट के ऊपर Helm चार्ट की परत जोड़ें।

आपको क्या चाहिए

  • एक चालू Kubernetes क्लस्टर (AKS, EKS, GKE, k3s, kind, OpenShift आदि)
  • kubectl आपके क्लस्टर से कनेक्टेड
  • कम-से-कम एक मॉडल प्रदाता की API कुंजी

त्वरित शुरुआत

deploy.sh डिफ़ॉल्ट रूप से टोकन प्रमाणीकरण बनाता है। Control UI के लिए जनरेट किया गया Gateway टोकन प्राप्त करें:
स्थानीय डीबगिंग के लिए, ./scripts/k8s/deploy.sh --show-token परिनियोजन के बाद टोकन प्रिंट करता है।

Kind के साथ स्थानीय परीक्षण

यदि आपके पास क्लस्टर नहीं है, तो Kind के साथ स्थानीय रूप से एक क्लस्टर बनाएँ:
फिर हमेशा की तरह ./scripts/k8s/deploy.sh के साथ परिनियोजित करें।

चरण-दर-चरण

1) परिनियोजित करें

विकल्प A: परिवेश में API कुंजी (एक चरण)
स्क्रिप्ट API कुंजी और स्वतः जनरेट किए गए Gateway टोकन के साथ Kubernetes Secret बनाती है, फिर परिनियोजित करती है। यदि Secret पहले से मौजूद है, तो यह मौजूदा Gateway टोकन और उन सभी प्रदाता कुंजियों को बनाए रखती है जिन्हें बदला नहीं जा रहा है। विकल्प B: सीक्रेट अलग से बनाएँ
स्थानीय परीक्षण के लिए टोकन को stdout पर प्रिंट करने हेतु किसी भी कमांड में --show-token जोड़ें।

2) Gateway तक पहुँचें

क्या परिनियोजित होता है

अनुकूलन

एजेंट निर्देश

scripts/k8s/manifests/configmap.yaml में AGENTS.md संपादित करें और फिर से परिनियोजित करें:

Gateway कॉन्फ़िगरेशन

scripts/k8s/manifests/configmap.yaml में openclaw.json संपादित करें। पूर्ण संदर्भ के लिए Gateway कॉन्फ़िगरेशन देखें।

प्रदाता जोड़ें

अतिरिक्त कुंजियाँ एक्सपोर्ट करके फिर से चलाएँ:
मौजूदा प्रदाता कुंजियाँ तब तक Secret में बनी रहती हैं, जब तक आप उन्हें ओवरराइट नहीं करते। या Secret को सीधे पैच करें:

कस्टम नेमस्पेस

कस्टम इमेज

scripts/k8s/manifests/deployment.yaml में image फ़ील्ड संपादित करें:

पोर्ट-फ़ॉरवर्ड से आगे एक्सपोज़ करें

डिफ़ॉल्ट मैनिफ़ेस्ट Gateway को पॉड के अंदर लूपबैक से बाइंड करते हैं। यह kubectl port-forward के साथ काम करता है, लेकिन ऐसे Kubernetes Service या Ingress पथ के साथ नहीं, जिसे सीधे पॉड IP तक पहुँचना हो। Ingress या लोड बैलेंसर के माध्यम से Gateway को एक्सपोज़ करने के लिए:
  • scripts/k8s/manifests/configmap.yaml में Gateway बाइंड को loopback से बदलकर ऐसे गैर-लूपबैक बाइंड पर सेट करें जो आपके परिनियोजन मॉडल से मेल खाता हो।
  • Gateway प्रमाणीकरण को सक्षम रखें और उचित TLS-टर्मिनेटेड प्रवेश-बिंदु का उपयोग करें।
  • समर्थित वेब सुरक्षा मॉडल का उपयोग करके Control UI को रिमोट एक्सेस के लिए कॉन्फ़िगर करें (उदाहरण के लिए HTTPS/Tailscale Serve और आवश्यकता होने पर स्पष्ट रूप से अनुमत ओरिजिन)।

पुनः परिनियोजन

यह सभी मैनिफ़ेस्ट लागू करता है और कॉन्फ़िगरेशन या सीक्रेट में हुए बदलाव अपनाने के लिए पॉड को पुनः आरंभ करता है।

हटाना

यह नेमस्पेस और उसमें मौजूद PVC सहित सभी संसाधनों को हटा देता है।

आर्किटेक्चर संबंधी टिप्पणियाँ

  • Gateway डिफ़ॉल्ट रूप से पॉड के अंदर लूपबैक से बाइंड होता है, इसलिए शामिल सेटअप kubectl port-forward के लिए है।
  • कोई क्लस्टर-स्कोप वाला संसाधन नहीं है; सब कुछ एक ही नेमस्पेस में रहता है।
  • सुरक्षा सुदृढ़ीकरण: readOnlyRootFilesystem, drop: ALL क्षमताएँ, गैर-रूट उपयोगकर्ता (UID 1000)।
  • डिफ़ॉल्ट कॉन्फ़िगरेशन Control UI को अधिक सुरक्षित स्थानीय-एक्सेस पथ पर रखता है: लूपबैक बाइंड और kubectl port-forward को http://127.0.0.1:18789 पर सेट करना।
  • यदि आप localhost एक्सेस से आगे बढ़ते हैं, तो समर्थित रिमोट मॉडल का उपयोग करें: HTTPS/Tailscale के साथ उपयुक्त Gateway बाइंड और Control UI ओरिजिन सेटिंग्स।
  • सीक्रेट अस्थायी डायरेक्टरी में जनरेट किए जाते हैं और सीधे क्लस्टर पर लागू होते हैं; रिपॉज़िटरी चेकआउट में कोई सीक्रेट सामग्री नहीं लिखी जाती।

फ़ाइल संरचना

संबंधित