Déploiement de conteneur DOCA

Par où commencer : Cette skill concerne l'exploitation du runtime de déploiement de conteneur DOCA cross-cutting — le pattern partagé que chaque service DOCA sur le BlueField utilise pour démarrer (agent kubelet standalone sur le BlueField Arm qui observe un répertoire de manifests de pod statiques ; l'opérateur dépose une spécification de pod YAML dans ce répertoire ; kubelet planifie le pod et exécute le conteneur).

Si le développeur n'a PAS encore décidé conteneur vs. bare-metal (« Je viens de recevoir un BlueField, et maintenant ? », « Mon code est compilé, comment l'exécuter ? », « Comment je déploie ça ? »), redirigez-le d'abord vers doca-setup ## recognize. C'est la décision de routage à la porte d'entrée. Le mauvais cas d'erreur est de pousser silencieusement chaque développeur sur le chemin du conteneur parce que l'agent a chargé cette skill en premier. ## recognize détecte la forme du système, pose la question résiduelle minimale, et place le développeur soit sur cette skill (quand la charge de travail est un service DOCA packagé à déposer sur un BlueField), soit sur le chemin bare-metal sibling doca-bare-metal-deployment (quand la charge de travail est un binaire d'application lié à DOCA que le développeur lance directement).

Si le développeur est déjà sur le chemin du conteneur, ouvrez TASKS.md et commencez à ## configure. Si la question est quelle forme de runtime c'est et à quoi ressemble le contrat de déploiement, commencez à CAPABILITIES.md. Pour les overlays par service, suivez la skill par service sous skills/services/ qui s'ajoute à celle-ci — le monorepo DOCA expédie six skills de service (Argus, DMS, Firefly, Flow-Inspector, OS-Inspector, UROM service) ; les services NVIDIA externalisés (BlueMan, HBN, SNAP, Virtio-net, DOCA Telemetry Service comme produit, …) sont hors de portée pour ce bundle par l'invariant strict-to-DOCA — redirigez ces services vers la doc publique NVIDIA à docs.nvidia.com/doca/sdk/. Si DOCA n'est pas encore installé sur la cible BlueField, redirigez vers doca-setup en premier.

Audience

Cette skill sert les opérateurs externes et équipes de plateforme qui déploient des conteneurs de service DOCA sur BlueField — c'est-à-dire des personnes qui ont un BlueField avec DOCA installé du côté Arm, un runtime de conteneur plus l'agent kubelet standalone déjà présents selon l'image du système d'exploitation BlueField, et les permissions du système d'exploitation hôte que le guide public DOCA Container Deployment nomme pour le service choisi. La skill est le runtime de déploiement partagé ; chaque skill par service dans le bundle (voir la liste dans ## Related skills) fournit le schéma de config spécifique au service, le contrat de charge de travail appairé, et la définition « healthy ».

Ce n'est pas pour les développeurs NVIDIA contribuant au runtime de conteneur BlueField ou à kubelet lui-même, et ce n'est pas un tutoriel Kubernetes générique. Kubelet s'exécute sur le BlueField en mode standalone ici — pas de plan de contrôle Kubernetes complet, pas de kubectl contre un serveur API de cluster — et la réponse substantielle à la plupart des questions de déploiement de conteneur sur le BlueField est le guide public DOCA Container Deployment. Cette skill enseigne à l'agent quel guide citer, dans quel ordre le parcourir, et comment mapper un symptôme à une couche ; elle ne réinvente PAS les flags kubelet, les noms de champ pod-spec, ou les chaînes de chemin pod statique. Le runtime de déploiement partagé décrit ici est la couche cross-cutting ; la skill par service (doca-argus, doca-dms, doca-firefly, doca-urom-svc) fournit le schéma de config par service, le contrat de charge de travail appairé, et la définition « healthy ».

Quand charger cette skill

Chargez cette skill quand l'utilisateur fait du déploiement de conteneur hands-on de n'importe quel service DOCA sur une cible BlueField, ou pose une question de déploiement cross-service qui n'est pas spécifique au schéma de config d'un service. Concrètement :

• Déposer une spécification de pod YAML dans le répertoire de manifests de pod statiques documenté sur le BlueField Arm afin que kubelet standalone planifie le pod et exécute le conteneur de service DOCA.
• Inspecter l'état du pod, les logs du conteneur, et le signal de liveness documenté pour tout conteneur de service DOCA in-bundle — Argus, DMS, Firefly, Flow-Inspector, OS-Inspector, UROM service — afin que l'agent réponde « est-ce que le conteneur est démarré, et le service à l'intérieur est-il vraiment prêt » de la même façon pour chaque service.
• Parcourir la boucle smoke-before-bulk (pod atteint Running ; les logs ENTRYPOINT sont propres ; le service répond à une sonde de liveness triviale) AVANT que le BlueField soit mis en charge de travail.
• Diagnostiquer un déploiement qui se comporte mal — le YAML pod-spec est dans le répertoire mais le pod ne se planifie jamais ; le pod se planifie mais l'image-pull échoue ; l'image se pull mais le ENTRYPOINT du conteneur quitte immédiatement ; le conteneur s'exécute mais le service à l'intérieur ne répond jamais ; le conteneur est dans une boucle de redémarrage après une édition de config ; un volume mount que la pod spec nomme manque sur l'hôte ; une politique réseau ou une règle de pare-feu hôte bloque le service.
• Questions cross-service : « Puis-je avoir DMS et Firefly sur le même BlueField », « Comment je liste chaque pod de service DOCA actuellement en cours d'exécution », « Quelle est la sémantique de stop / redémarrage documentée si j'édite un fichier pod-spec sur place ».

Ne chargez pas cette skill pour les questions de schéma de config par service (celles-ci appartiennent à la skill par service correspondante) ; pour installer DOCA lui-même ou préparer l'environnement BlueField (utilisez doca-setup) ; pour les questions d'API de bibliothèque (utilisez la skill libs/<library> correspondante) ; ou pour les opérations générales de cluster Kubernetes (cette skill couvre le mode standalone de kubelet sur le BlueField, pas un plan de contrôle Kubernetes complet).

Ce que cette skill fournit

C'est un thin loader. Le matériel substantiel vit dans deux fichiers complémentaires :

• CAPABILITIES.md — le contrat cross-cutting du runtime de déploiement de conteneur DOCA sur le BlueField (agent kubelet standalone sur BlueField Arm qui observe un répertoire de manifests de pod statiques documenté ; le dépôt de pod-spec YAML est l'unité d'entrée de l'opérateur ; le même pattern s'applique à chaque service DOCA), les préconditions BlueField (install DOCA, runtime de conteneur, version BFB, slot de firmware par service quand le service émule un device, reachabilité de image-pull vers NGC, permissions du système d'exploitation hôte), la surface d'observabilité (statut kubelet, logs de conteneur, signal de liveness côté service — trois couches, chacune avec son propre propriétaire), la taxonomie d'erreur cross-cutting (syntaxe pod-spec → planification de pod → image pull → runtime → volume mount → politique réseau → version → hôte cross-cutting) couvrant ≥ 6 couches, et la politique de sécurité (smoke before bulk ; pod échoué est enjeu élevé — clarifier la cause racine avant de laisser kubelet restart-loop le pod ; NE PAS inventer les noms de champ pod-spec / flags kubelet / image tags de mémoire).
• TASKS.md — workflows étape par étape pour les verbes de déploiement in-scope : configure, build, modify, run, test, debug, plus un bloc Deferred task verbs routant les questions de config par service, le travail de slot de firmware hôte, le travail de charge de travail appairé, et le travail de cluster Kubernetes complet vers leurs skills propriétaires.

La skill suppose une cible BlueField où DOCA est déjà installé du côté Arm, l'image du système d'exploitation BlueField expédie kubelet standalone + le runtime de conteneur selon le guide public DOCA Container Deployment, et l'opérateur a les permissions du système d'exploitation hôte que ce guide nomme. Elle ne couvre pas l'installation de DOCA — ce chemin passe par doca-setup — et elle ne re-documente pas le schéma de config par service, qui est la préoccupation canonique du guide public de chaque service DOCA accessible via doca-public-knowledge-map.

Ordre de chargement

1. Lisez d'abord ce SKILL.md pour confirmer que la question de l'utilisateur est in-scope (runtime de déploiement cross-cutting, PAS une question de schéma de config par service).
2. Pour la forme de runtime du mode standalone kubelet, la règle du répertoire de manifests de pod statiques, les préconditions du système d'exploitation hôte / BFB / slot de firmware / image-pull, la taxonomie d'erreur (≥ 6 couches), la surface d'observabilité, et la politique de sécurité / smoke-before-bulk, voir CAPABILITIES.md.
3. Pour les workflows étape par étape — configure, build, modify, run, test, debug — voir TASKS.md.

Exemples de questions que cette skill traite bien

Voir references/details.md.

Ce que cette skill ne livre délibérément pas

Voir references/details.md.

Skills associées

Voir references/details.md.