Skip to content

Advanced Operations

Jump to bottom
m4xx3d0ut edited this page May 13, 2026 · 2 revisions

Advanced Operations

This page covers WorkerBee features that are useful once the basic local loop is working.

Runtime Selection

WorkerBee supports:

  • auto: select an available runtime.
  • podman: use Podman.
  • docker: use Docker.
  • containerd: advanced direct-containerd mode.

Examples:

workerbee --runtime podman mcp restart
workerbee --runtime docker mcp restart
workerbee --runtime containerd profile list

Persist defaults for the local user:

workerbee config set --runtime podman
workerbee config show
workerbee config clear

MCP Remote Bind Guardrail

WorkerBee MCP binds to loopback by default. Non-loopback MCP binds are refused unless explicitly allowed:

workerbee mcp serve --host 0.0.0.0 --allow-remote-mcp

Use this only for controlled local-network transport testing. WorkerBee does not yet implement standards-compliant remote MCP authorization.

LAN ingress is separate from remote MCP. You can expose app ingress to the LAN while keeping MCP on loopback:

workerbee mcp restart --ingress-exposure lan

Containerd Privilege

Direct containerd workflows may need elevated access to the containerd socket and CNI resources. Inspect current state:

workerbee --runtime containerd containerd-privilege status

Start commands with an explicit strategy:

workerbee --runtime containerd --containerd-privilege sudo-helper profile list
workerbee --runtime containerd --containerd-privilege unprivileged profile list

Stop the helper when it is no longer needed:

workerbee --runtime containerd containerd-privilege stop-helper

Revoke deprecated ACL leases:

workerbee --runtime containerd containerd-privilege revoke-acl-leases

Host NVIDIA GPU Workloads

WorkerBee can run a general NVIDIA GPU workload through the direct-containerd backend when the host is already prepared for NVIDIA containers. This is a WorkerBee app workload pattern, not nested k1s profile GPU validation.

Preflight the host path first:

nvidia-smi -L
nvidia-container-cli --version
nvidia-container-runtime --version
workerbee --runtime containerd containerd-privilege status

Use Kubernetes resources that make the GPU contract explicit. The direct containerd runtime requires runtimeClassName: nvidia and matching request and limit values for exactly one GPU:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: vllm-smoke
spec:
  replicas: 1
  selector:
    matchLabels:
      app: vllm-smoke
  template:
    metadata:
      labels:
        app: vllm-smoke
    spec:
      runtimeClassName: nvidia
      containers:
        - name: vllm
          image: vllm/vllm-openai:latest
          args:
            - --host
            - 0.0.0.0
            - --port
            - "8000"
            - --model
            - TinyLlama/TinyLlama-1.1B-Chat-v1.0
          ports:
            - name: http
              containerPort: 8000
          resources:
            requests:
              memory: 8Gi
              nvidia.com/gpu: 1
            limits:
              memory: 16Gi
              nvidia.com/gpu: 1
---
apiVersion: v1
kind: Service
metadata:
  name: vllm-smoke
spec:
  selector:
    app: vllm-smoke
  ports:
    - name: http
      port: 8000
      targetPort: 8000

Stage and deploy the manifest as a normal WorkerBee workload:

workerbee --runtime containerd manifest prepare \
  --name vllm-smoke \
  --source ./vllm-smoke.yaml
workerbee --runtime containerd manifest validate --stage vllm-smoke
workerbee --runtime containerd manifest deploy-local --stage vllm-smoke
workerbee --runtime containerd logs vllm-smoke --tail 100

Operational limits:

  • Use this pattern only with workerbee --runtime containerd.
  • WorkerBee does not install NVIDIA drivers, the container toolkit, or model files.
  • The current direct-containerd GPU contract is a single NVIDIA GPU: nvidia.com/gpu: 1.
  • Requests and limits for nvidia.com/gpu must match.
  • This validates a host GPU app workload. It does not validate nested k1s GPU scheduling, GPU capacity discovery, or multi-node GPU placement.
  • Pin images and model artifacts for repeatable CI or release validation; model downloads may require network access or registry/model credentials.

Remote k1s Deploy

WorkerBee can deploy staged manifests to a remote k1s server:

workerbee manifest deploy-k1s \
  --stage app \
  --server https://k1s.example.internal:6443 \
  --token "$K1S_TOKEN" \
  --namespace demo

Remote deploy fails closed for native k1s secretRef values by default because the referenced secret paths resolve on the remote controller. Opt in only when the remote environment is prepared:

workerbee manifest deploy-k1s \
  --stage app \
  --server https://k1s.example.internal:6443 \
  --token "$K1S_TOKEN" \
  --allow-remote-secretrefs

Bundle Handoff

Export native k1s:

workerbee bundle export --stage app --format k1s

Export practical Kubernetes YAML:

workerbee bundle export --stage app --format k8s

Export a Helm skeleton:

workerbee bundle export --stage app --format helm

Exports preserve Secret references but not Secret values. Create environment-specific Secret objects before applying exported Kubernetes or Helm artifacts.

Security Assessment

Assess staged manifests, generated exports, and optional runtime ingress:

workerbee security assess --stage app

Review a deployed project:

workerbee security review-project --stage app

Security checks are advisory and should feed code review, not replace it.

Advanced Diagnostics

Capture status:

workerbee mcp status --json
workerbee ingress status --json
workerbee projects --json

Probe ingress through WorkerBee MCP when possible. Agents should use workerbee_v1_ingress_probe because it knows the WorkerBee CA, host routing, and project scope.

Use workerbee_v1_ingress_status to discover active CA commands, DNS details, base domain, and readiness before asking a user to configure another device.

Clone this wiki locally