doca-container-deployment

Files (8)

• BENCHMARK.md
• CAPABILITIES.md
• SKILL.md
• TASKS.md
• evals.json · evals/
• details.md · references/
• skill-card.md
• skill.oms.sig

SKILL.md (first lines)

# DOCA container deployment

## Examples

- **"How do I run a DOCA service container on BlueField?"** —
  this is in scope after the setup recognize front door. Drop
  a documented pod spec; do not invent YAML or image tags.
- **"The pod spec is in the directory but the pod never
  starts."** — walk the eight-layer taxonomy before letting
  kubelet restart-loop the pod.

## Instructions

Follow Loading order below. Open the tasks companion for
configure / run / debug. Open the capabilities companion for
the kubelet-standalone contract. Do not open every companion
file.

**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/SKILL.md` 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/SKILL.md`
(when the workload is a DOCA-linked application binary the developer
launches directly).

**If the developer is already on the container path**, open
the tasks companion and start at
`## configure`. If the question is *what shape
of runtime is this and what does the deployment contract look like*,
start at the capabilities companion. 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/SKILL.md`
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/SKILL.md` 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`](#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/SKILL.md`); for library-API
questions (use the matching `libs/<library>` skill); or for general

From NVIDIA/skills, Apache-2.0.

More from NVIDIA/skills