Kubernetes deployment
Three manifests run the rule server as a highly available, autoscaled service.
Three manifests run the rule server as a highly available, autoscaled service.
| File | What it gives you |
|---|---|
deployment.yaml | 3 replicas spread across zones and nodes, zero-downtime rolling updates, startup, readiness and liveness probes, non-root read-only container |
service.yaml | One stable address in front of the replicas |
autoscaling.yaml | Scale from 3 to 20 replicas on CPU, and a disruption budget that keeps at least 2 running |
# 1. The rules: *.ruleset.yaml files plus the schemas they reference, compiled *.bundle.json files, or both
kubectl create configmap rule-cascade-rules --from-file=examples/contracts
# 2. Required: the token for evaluations, the server manifest, bundles and server-only rule details
kubectl create secret generic rule-cascade-server --from-literal=token="$(openssl rand -hex 32)"
# 3. The service
kubectl apply -f deploy/kubernetes/What the server loads
The rules directory (RULES_DIR, here the ConfigMap mounted at /rules) may hold two kinds of files:
| File | At start-up and on reload |
|---|---|
*.ruleset.yaml, *.ruleset.yml, *.ruleset.json with the schemas they reference | Compiled by the server: schema validation, inheritance and every load check |
*.bundle.json | Read as a bundle that was compiled elsewhere, for example in CI. Only the bundle format is checked |
A ruleset id may be defined once. When CI already compiles bundles, deploy those: the server then
serves exactly what was built and reviewed. If any ruleset fails a load check or any bundle is
unusable, the process exits before it listens, so the pod never becomes ready (GET /readyz).
GET /rulesets/{id}/bundle, the server manifest, POST /evaluations and server-only rule details need
Authorization: Bearer <token>; the client manifest, the list of rulesets and the probes do not, so
browsers and the kubelet need no token. The server speaks plain HTTP, so keep the Service inside the
cluster and put TLS and external authentication in your gateway.
The server fails closed: it exits 1 at start-up when RULE_SERVER_TOKEN is not set, and the Deployment
reads it from the rule-cascade-server Secret without optional, so a pod without the Secret stays in
CreateContainerConfigError instead of serving evaluations to anyone. To run without a token on a
private network, replace the RULE_SERVER_TOKEN entry in deployment.yaml with
{ name: RULE_SERVER_ALLOW_OPEN, value: "1" }; the server logs a warning at start-up. Rotate the token by
updating the Secret and restarting the Deployment.
The image runs the rule-cascade-server command, which registers no custom operators. A ruleset
that uses one is served, a warning is logged, and its rules that need the operator fail closed. To
supply operators, build an image around createRuleServer as
packages/server describes.
Publishing new rules
Treat rules like code: a new ConfigMap and a rolling restart.
kubectl create configmap rule-cascade-rules --from-file=examples/contracts -o yaml --dry-run=client | kubectl apply -f -
kubectl rollout restart deployment/rule-cascade-server
kubectl rollout status deployment/rule-cascade-serverA pod whose rules fail to load never becomes ready, and maxUnavailable: 0 keeps every old pod serving
until a new one is ready. A broken ruleset or bundle therefore stops the rollout at the first pod and
production keeps running the previous rules.
Status
These manifests and the Dockerfile are written to the Kubernetes and Docker documentation but were not run
against a cluster while this repository was put together. Build the image and apply them in a test
namespace before relying on them. The image name in deployment.yaml is a placeholder until you publish one.
Rendered from deploy/kubernetes/README.md in the repository. Edit it there.
Bindings for language models
Two JSON files let a language-model agent work with Rule Cascade without being trusted with the rules. The agent can ask which rules apply, check an operation before it performs it, and draft a new rule.
@yarlisaisolutions/rule-cascade
The Rule Cascade runtime for browsers and Node.js. It implements both conformance levels of the specification: it evaluates bundles and manifests (evaluator) and it loads source documents and produces bundles (compiler).