Bu sayfada
Bu sayfada
Hosting
Kubernetes
OpenClaw'ı Kubernetes üzerinde çalıştırmak için minimal bir başlangıç noktasıdır; üretime hazır bir dağıtım değildir. Temel kaynakları kapsar ve ortamınıza uyarlanması amaçlanır.
Neden Helm değil
OpenClaw, bazı yapılandırma dosyaları içeren tek bir konteynerdir. Asıl özelleştirme altyapı şablonlamasında değil, ajan içeriğindedir (Markdown dosyaları, Skills, yapılandırma geçersiz kılmaları). Kustomize, bir Helm chart'ının ek yükü olmadan katmanları yönetir. Dağıtımınız daha karmaşık hâle gelirse bu manifestlerin üzerine bir Helm chart'ı ekleyin.
Gereksinimler
- Çalışan bir Kubernetes kümesi (AKS, EKS, GKE, k3s, kind, OpenShift vb.)
kubectlkümenize bağlı- En az bir model sağlayıcısı için API anahtarı
Hızlı başlangıç
deploy.sh varsayılan olarak token kimlik doğrulaması oluşturur. Control UI için oluşturulan gateway token'ını alın:
Yerel hata ayıklama için ./scripts/k8s/deploy.sh --show-token, dağıtımdan sonra token'ı yazdırır.
Kind ile yerel test
Bir kümeniz yoksa Kind ile yerel olarak bir küme oluşturun:
Ardından her zamanki gibi ./scripts/k8s/deploy.sh ile dağıtın.
Adım adım
1) Dağıtın
Seçenek A: Ortam değişkeninde API anahtarı (tek adım)
Betik, API anahtarını ve otomatik oluşturulan gateway token'ını içeren bir Kubernetes Secret oluşturur, ardından dağıtımı gerçekleştirir. Secret zaten varsa mevcut gateway token'ını ve değiştirilmeyen tüm sağlayıcı anahtarlarını korur.
Seçenek B: Secret'ı ayrı olarak oluşturun
Yerel test amacıyla token'ı standart çıktıya yazdırmak için komutlardan birine --show-token ekleyin.
2) Gateway'e erişin
Dağıtılan kaynaklar
Özelleştirme
Ajan talimatları
scripts/k8s/manifests/configmap.yaml içindeki AGENTS.md dosyasını düzenleyin ve yeniden dağıtın:
Gateway yapılandırması
scripts/k8s/manifests/configmap.yaml içindeki openclaw.json dosyasını düzenleyin. Tam başvuru için Gateway yapılandırması bölümüne bakın.
Sağlayıcı ekleme
Ek anahtarları dışa aktarıp yeniden çalıştırın:
Üzerlerine yazmadığınız sürece mevcut sağlayıcı anahtarları Secret içinde kalır.
Alternatif olarak Secret'a doğrudan yama uygulayın:
Özel ad alanı
Özel imaj
scripts/k8s/manifests/deployment.yaml içindeki image alanını düzenleyin:
Port yönlendirmenin ötesinde erişime açma
Varsayılan manifestler, gateway'i pod içindeki loopback adresine bağlar. Bu, kubectl port-forward ile çalışır ancak pod IP'sine doğrudan erişmesi gereken bir Kubernetes Service veya Ingress yolu ile çalışmaz.
Gateway'i bir Ingress veya yük dengeleyici üzerinden erişime açmak için:
scripts/k8s/manifests/configmap.yamliçindeki gateway bağlama ayarınıloopbackdeğerinden, dağıtım modelinize uygun loopback olmayan bir bağlama değeriyle değiştirin.- Gateway kimlik doğrulamasını etkin tutun ve TLS sonlandırmalı uygun bir giriş noktası kullanın.
- Desteklenen web güvenliği modelini kullanarak Control UI'ı uzaktan erişim için yapılandırın (örneğin HTTPS/Tailscale Serve ve gerektiğinde açıkça belirtilmiş izin verilen kaynaklar).
Yeniden dağıtma
Bu işlem tüm manifestleri uygular ve tüm yapılandırma veya Secret değişikliklerinin alınması için pod'u yeniden başlatır.
Kaldırma
Bu işlem, PVC dâhil olmak üzere ad alanını ve içindeki tüm kaynakları siler.
Mimari notları
- Gateway varsayılan olarak pod içindeki loopback adresine bağlanır; dolayısıyla dâhil edilen kurulum
kubectl port-forwardiçindir. - Küme kapsamlı kaynak yoktur; her şey tek bir ad alanında bulunur.
- Güvenlik güçlendirmesi:
readOnlyRootFilesystem,drop: ALLyetenekleri, root olmayan kullanıcı (UID 1000). - Varsayılan yapılandırma, Control UI'ı daha güvenli yerel erişim yolunda tutar: loopback bağlaması ve
kubectl port-forwarddeğerininhttp://127.0.0.1:18789olarak ayarlanması. - Yerel ana makine erişiminin ötesine geçerseniz desteklenen uzak modeli kullanın: HTTPS/Tailscale ve uygun gateway bağlama ile Control UI kaynak ayarları.
- Secret'lar geçici bir dizinde oluşturulur ve doğrudan kümeye uygulanır; depo çalışma kopyasına hiçbir gizli veri yazılmaz.