/doca-container-deployment

license: Apache-2.0
name: doca-container-deployment
description: >
  Use this skill when the user is hands-on deploying an in-bundle DOCA
  service container (Argus, DMS, Firefly, or UROM service) on a
  BlueField — kubelet standalone watching a
  static-pod manifests directory, YAML pod-spec drop, kubelet status /
  ENTRYPOINT logs / per-service liveness, smoke-before-bulk, and the
  layered error taxonomy (pod-spec, scheduling, image pull, runtime,
  mount, network, version, host). Trigger even when the user does not
  say "container deployment" — typical implicit phrasings include "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". 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 — those belong to other
  skills.
metadata:
  kind: library
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

**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`](../doca-setup/TASKS.md#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`](../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 [`TASKS.md`](TASKS.md) and start at [`## configure`](TASKS.md#configure). If the question is *what shape of runtime is this and what does the deployment contract look like*, start at [`CAPABILITIES.md`](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`](../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`](../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 sch