Kubernetes Deployment (ReasonKit MCP (Pro))
ReasonKit MCP (Pro) is designed to be cloud-native and scales horizontally within any standard Kubernetes cluster.
1. Core Deployment Manifest
The standard ReasonKit deployment consists of a set of stateless nodes running the Rust core engine.
deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: reasonkit-core
namespace: reasonkit
spec:
replicas: 3
selector:
matchLabels:
app: reasonkit-core
template:
metadata:
labels:
app: reasonkit-core
spec:
containers:
- name: reasonkit
image: ghcr.io/reasonkit/core:latest
ports:
- containerPort: 3000
env:
- name: REASONKIT_PROTOCOLS_PATH
value: "/etc/reasonkit/protocols"
- name: ANTHROPIC_API_KEY
valueFrom:
secretKeyRef:
name: reasonkit-secrets
key: anthropic-key
volumeMounts:
- name: protocols-volume
mountPath: /etc/reasonkit/protocols
volumes:
- name: protocols-volume
configMap:
name: reasonkit-protocols
2. Service Exposure
Expose ReasonKit internally within your cluster or externally via an Ingress.
service.yaml
apiVersion: v1
kind: Service
metadata:
name: reasonkit-svc
spec:
selector:
app: reasonkit-core
ports:
- protocol: TCP
port: 80
targetPort: 3000
3. Scaling (HPA)
Scale ReasonKit pods based on custom metrics like reasonkit_logic_backpressure or standard CPU/Memory usage.
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: reasonkit-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: reasonkit-core
minReplicas: 3
maxReplicas: 50
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 70
4. Configuration Management
Use ConfigMaps to manage your ThinkTool YAML definitions globally across the cluster. This allows you to update reasoning logic by updating the ConfigMap and performing a rollout restart.
kubectl rollout restart deployment/reasonkit-core
5. Persistence (RAG)
When running the RAG layer (Qdrant/Tantivy) in-cluster, use a StatefulSet with PersistentVolumeClaims to ensure that vector indices are not lost during node restarts.