Skip to main content
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.)
  • kubectl kü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.yaml içindeki gateway bağlama ayarını loopback değ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-forward içindir.
  • Küme kapsamlı kaynak yoktur; her şey tek bir ad alanında bulunur.
  • Güvenlik güçlendirmesi: readOnlyRootFilesystem, drop: ALL yetenekleri, 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-forward değerinin http://127.0.0.1:18789 olarak 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.

​
Dosya yapısı

​
İlgili konular