/doca-container-deployment

license: Apache-2.0
name: doca-container-deployment
description: >
  Running an in-bundle DOCA service as a container on a BlueField (Argus,
  DMS, Firefly, or UROM service): kubelet standalone watching a static-pod
  manifests directory, YAML pod-spec drop, kubelet status / ENTRYPOINT
  logs / per-service liveness. Trigger on "how do I run my built service
  on the BlueField?", "where do I drop the pod-spec YAML?", "pod stuck in
  Pending / ImagePullBackOff / CrashLoopBackOff", "container Running but
  service isn't ready", "pod restart-loops after edit", or "DMS and
  Firefly together", even without naming container deployment. A
  DOCA-linked binary launched directly on the host or Arm belongs to
  doca-bare-metal-deployment. Covers smoke-before-bulk and the layered
  error taxonomy (pod-spec, scheduling, image pull, runtime, mount,
  network, version, host). Refuse and route elsewhere for per-service
  config schemas, DOCA install, library-API questions, external NVIDIA
  services (BlueMan, HBN, SNAP, Virtio-net), or full Kubernetes-cluster
  ops.
metadata:
  author: NVIDIA <doca-feedback@nvidia.com>
  kind: library
  doca_version: "3.5"
  tags:
    - doca
    - container
    - deployment
compatibility: >
  No DOCA install required to read this skill (it is an overlay loaded
  against any DOCA artifact skill); the validation steps within DO
  require a live DOCA install at /opt/mellanox/doca.

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 outside this bundle's scope; 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-bu