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 a Deferred task verbs block 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

1. Read this SKILL.md first to confirm the user's question is in scope (cross-cutting deployment runtime, NOT a per-service config-schema question).
2. 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.
3. For step-by-step workflows — configure, build, modify, run, test, debug — see TASKS.md.

Example questions this skill answers well

See references/details.md.

What this skill deliberately does not ship

See references/details.md.

Related skills

See references/details.md.