DOCA container deployment
Where to start: This skill is for operating the cross-cutting DOCA container-deployment runtime — the shared pattern every DOCA service on the BlueField uses to come up (kubelet standalone agent on the BlueField Arm watching a static-pod manifests directory; the operator drops a YAML pod spec into that directory; kubelet schedules the pod and runs the container).
If the developer has NOT yet decided container vs. bare-metal
("I just got a BlueField, what now?", "my code is built, how do I
run it?", "how do I deploy this?"), route them BACK to
doca-setup ## recognize first.
That is the front-door routing decision. The wrong failure mode is
to silently push every developer onto the container path because the
agent loaded this skill first. ## recognize detects the system
shape, asks the minimum residual question, and lands the developer on
either this skill (when the workload is a packaged DOCA service to
drop on a BlueField) or the bare-metal-path sibling
doca-bare-metal-deployment
(when the workload is a DOCA-linked application binary the developer
launches directly).
If the developer is already on the container path, open
TASKS.md and start at
## configure. If the question is what shape
of runtime is this and what does the deployment contract look like,
start at CAPABILITIES.md. For per-service
overlays, follow the per-service skill under skills/services/ that
layers on top of this one — the supported overlays are Argus, DMS,
Firefly, and UROM service. Flow-Inspector and OS-Inspector are
policy-excluded from this public bundle; route them through
doca-public-knowledge-map
instead of applying this runtime overlay. Externally-productized
NVIDIA services (BlueMan, HBN, SNAP, Virtio-net, DOCA Telemetry
Service as productized, …) are also out of scope and route through
that map. If DOCA is
not installed on the BlueField target yet, route to
doca-setup first.
Audience
This skill serves external operators and platform teams who deploy
DOCA service containers on BlueField — i.e., people who have a
BlueField with DOCA installed on the Arm side, a container runtime
plus the kubelet standalone agent already present per the BlueField
OS image, and the host-OS permissions the public DOCA Container
Deployment Guide names for the chosen service. The skill is the
shared deployment runtime; each per-service skill in the bundle
(see the list in ## Related skills) supplies
the service-specific config schema, paired-workload contract, and
"healthy" definition.
It is not for NVIDIA developers contributing to the BlueField
container runtime or to kubelet itself, and it is not a generic
Kubernetes tutorial. Kubelet runs on the BlueField in standalone
mode here — no full Kubernetes control plane, no kubectl against
a cluster API server — and the substantive answer to most
container-deployment questions on the BlueField is the public DOCA
Container Deployment Guide. This skill teaches the agent which
guide to quote, in what order to walk it, and how to map a symptom
to a layer; it does NOT re-invent kubelet flags, pod-spec field
names, or static-pod path strings. The shared deployment runtime
described here is the cross-cutting layer; the per-service skill
(doca-argus, doca-dms, doca-firefly,
doca-urom-svc) supplies the per-service
config schema, paired-workload contract, and "healthy" definition.
When to load this skill
Load this skill when the user is doing hands-on container deployment of any DOCA service on a BlueField target, or asking a cross-service deployment question that is not specific to one service's config schema. Concretely:
- Dropping a YAML pod spec into the documented static-pod manifests directory on the BlueField Arm so kubelet standalone schedules the pod and runs the DOCA service container.
- Inspecting pod status, container logs, and the documented liveness signal for any supported in-bundle DOCA service container — Argus, DMS, Firefly, or UROM service — so the agent answers "did the container come up, and is the service inside actually ready" the same way for every service.
- Walking the smoke-before-bulk loop (pod reaches
Running; ENTRYPOINT logs are clean; service answers a trivial liveness probe) BEFORE the BlueField is put under workload. - Diagnosing a deployment that is misbehaving — pod-spec YAML is in the directory but the pod never schedules; pod schedules but image-pull fails; image pulls but container ENTRYPOINT immediately exits; container runs but the service inside never answers; container is in a restart loop after a config edit; a volume mount the pod spec names is missing on the host; a network policy or host-firewall rule is blocking the service.
- Cross-service questions: "can I have DMS and Firefly on the same BlueField", "how do I list every DOCA service pod that is currently running", "what is the documented stop / restart semantics if I edit a pod-spec file in place".
Do not load this skill for per-service config schema questions
(those belong to the matching per-service skill); for installing
DOCA itself or preparing the BlueField env (use
doca-setup); for library-API
questions (use the matching libs/<library> skill); or for general
Kubernetes-cluster operations (this skill covers kubelet standalone
mode on the BlueField, not a full Kubernetes control plane).
What this skill provides
This is a thin loader. Substantive material lives in two companion files:
CAPABILITIES.md— the cross-cutting DOCA container-deployment runtime contract on the BlueField (kubelet standalone agent on BlueField Arm watching a documented static-pod manifests directory; YAML pod-spec drop is the unit of operator input; the same pattern applies across every DOCA service), the BlueField preconditions (DOCA install, container runtime, BFB version, per-service firmware slot when the service emulates a device, image-pull reachability to NGC, host-OS permissions), the observability surface (kubelet status, container logs, service- side liveness signal — three layers, each with its own owner), the cross-cutting error taxonomy (pod-spec syntax → pod scheduling → image pull → runtime → volume mount → network policy → version → cross-cutting host) covering exactly eight layers, and the safety policy (smoke before bulk; failed pod is high-stakes — clear the root cause before letting kubelet restart-loop the pod; do NOT invent pod-spec field names / kubelet flags / image tags from memory).TASKS.md— step-by-step workflows for the in-scope deployment verbs:configure,build,modify,run,test,debug, plus aDeferred task verbsblock routing per-service config questions, host-firmware-slot work, paired-workload work, and full-Kubernetes-cluster work out to their owning skills.
The skill assumes a BlueField target where DOCA is already installed
on the Arm side, the BlueField OS image ships kubelet standalone +
the container runtime per the public DOCA Container Deployment
Guide, and the operator has the host-OS permissions that guide
names. It does not cover installing DOCA — that path goes through
doca-setup — and it does not
re-document the per-service config schema, which is the canonical
concern of each DOCA service's public guide reached through
doca-public-knowledge-map.
Loading order
- Read this
SKILL.mdfirst to confirm the user's question is in scope (cross-cutting deployment runtime, NOT a per-service config-schema question). - For the kubelet-standalone-mode runtime shape, the static-pod manifests directory rule, the host-OS / BFB / firmware-slot / image-pull preconditions, the eight-layer error taxonomy, the observability surface, and the safety / smoke-before-bulk policy, see CAPABILITIES.md.
- For step-by-step workflows — configure, build, modify, run, test, debug — see TASKS.md.