doca-container-deployment

DOCA コンテナのデプロイ

例

• 「BlueField で DOCA サービスコンテナを実行するにはどうすればよいですか？」 — これは、セットアップの入り口で確認した後の対応範囲です。文書化された Pod 仕様を提示してください。YAML やイメージタグをでっち上げないでください。
• 「Pod 仕様はディレクトリにあるのに、Pod が起動しません。」 — kubelet に Pod の再起動ループをさせる前に、8 層の分類に沿って確認してください。

手順

以下の読み込み順に従ってください。設定／実行／デバッグについてはタスク用の補助ファイルを開いてください。kubelet 単独動作の契約については、機能の補助ファイルを開いてください。補助ファイルをすべて開く必要はありません。

開始方法： このスキルは、DOCA コンテナデプロイの横断的なランタイムを運用するためのものです。これは、BlueField 上で各 DOCA サービスを起動するための共通パターンです（BlueField Arm 上の kubelet 単独動作エージェントが static-pod マニフェストディレクトリを監視し、オペレーターがそのディレクトリに YAML Pod 仕様を配置すると、kubelet が Pod をスケジュールしてコンテナを実行します）。

開発者がコンテナとベアメタルのどちらにするかまだ決めていない場合（「BlueField を手に入れたばかりですが、何から始めればよいですか？」、「コードはビルドできましたが、どう実行すればよいですか？」、「これをデプロイするにはどうすればよいですか？」）は、まず doca-setup/SKILL.md に戻って案内してください。 これが最初の振り分け判断です。誤った対応は、エージェントが先にこのスキルを読み込んだという理由だけで、すべての開発者をコンテナの経路に黙って誘導することです。## recognize では、システムの構成を特定し、必要最小限の追加質問を行ったうえで、開発者をこのスキル（BlueField に配置するパッケージ化された DOCA サービスのワークロードの場合）か、ベアメタル経路の関連スキル doca-bare-metal-deployment/SKILL.md（開発者が直接起動する DOCA リンク済みアプリケーションバイナリのワークロードの場合）のいずれかに案内します。

開発者がすでにコンテナ経路を選んでいる場合は、タスク用の補助ファイルを開き、## configure から始めてください。ランタイムの構成やデプロイ契約の形についての質問なら、機能の補助ファイルから始めてください。サービスごとのオーバーレイについては、skills/services/ にある、このスキルを基盤とするサービス別スキルに従ってください。対応するオーバーレイは Argus、DMS、Firefly、UROM サービスです。Flow-Inspector と OS-Inspector は、この公開バンドルのポリシーにより対象外です。ランタイムオーバーレイを適用せず、doca-public-knowledge-map/SKILL.md を通じて案内してください。製品として外部提供されている NVIDIA サービス（BlueMan、HBN、SNAP、Virtio-net、製品化された DOCA Telemetry Service など）も対象外であり、同マップを通じて案内してください。BlueField のターゲットに DOCA がまだインストールされていない場合は、まず doca-setup/SKILL.md に案内してください。

対象読者

このスキルは、BlueField に DOCA サービスコンテナをデプロイする外部オペレーターおよびプラットフォームチームを対象としています。つまり、Arm 側に DOCA がインストールされ、BlueField OS イメージに従ってコンテナランタイムと kubelet スタンドアロンエージェントがすでに用意されており、選択したサービスについて公開されている DOCA Container Deployment Guide に記載されたホスト OS の権限を持つ人を対象とします。このスキルは共通のデプロイランタイムです。バンドル内の各サービス別スキル（## 関連スキルの一覧を参照）では、サービス固有の設定スキーマ、ペアワークロードの要件、「正常」の定義を提供します。

NVIDIA の開発者が BlueField コンテナランタイムや kubelet 自体に貢献するためのものではなく、汎用的な Kubernetes チュートリアルでもありません。ここでは BlueField 上の kubelet はスタンドアロンモードで動作し、Kubernetes の完全なコントロールプレーンも、クラスター API サーバーに対する kubectl の実行もありません。また、BlueField でのコンテナデプロイに関するほとんどの質問に対する本質的な回答は、公開されている DOCA Container Deployment Guide にあります。このスキルでは、エージェントがどのガイドを引用すべきか、どのような順序で手順を案内するか、症状をどのレイヤーに対応づけるかを説明します。kubelet のフラグ、pod-spec のフィールド名、静的 Pod のパス文字列を新たに定義するものではありません。ここで説明する共通のデプロイランタイムはサービス横断的なレイヤーです。サービス別スキル（doca-argus、doca-dms、doca-firefly、doca-urom-svc）では、サービス固有の設定スキーマ、ペアワークロードの要件、「正常」の定義を提供します。

このスキルを読み込むタイミング

ユーザーが BlueField ターゲット上で任意の DOCA サービスを手動でコンテナデプロイしている場合、または特定のサービスの設定スキーマに限定されない、サービス横断的なデプロイに関する質問をしている場合に、このスキルを読み込みます。具体的には、次のような場合です。

• BlueField の Arm 上にある、ドキュメントに記載された静的 Pod マニフェストディレクトリに YAML pod-spec を配置し、kubelet スタンドアロンが Pod をスケジュールして DOCA サービスコンテナを実行できるようにする。
• バンドル内でサポートされる DOCA サービスコンテナ（Argus、DMS、Firefly、UROM service）の Pod ステータス、コンテナログ、ドキュメントに記載されたライブネスシグナルを調べ、すべてのサービスについてエージェントが「コンテナは起動したか、コンテナ内のサービスは実際に準備できているか」に同じ方法で回答できるようにする。
• BlueField をワークロードに投入する前に、スモークテストを行ってから本格運用に進む手順（Pod が Running に到達する、ENTRYPOINT ログに問題がない、サービスが簡単なライブネスプローブに応答する）を実行する。
• デプロイの不具合を診断する。たとえば、pod-spec YAML はディレクトリにあるのに Pod がスケジュールされない、Pod はスケジュールされるがイメージのプルに失敗する、イメージはプルされるがコンテナの ENTRYPOINT がすぐに終了する、コンテナは実行されるが内部のサービスが応答しない、設定を編集した後にコンテナが再起動を繰り返す、pod-spec に指定したボリュームマウントがホスト上に存在しない、ネットワークポリシーまたはホストファイアウォールのルールがサービスをブロックしている、といったケース。
• サービス横断的な質問：「同じ BlueField 上で DMS と Firefly を実行できますか」「現在実行中の DOCA サービス Pod をすべて一覧表示するにはどうすればよいですか」「pod-spec ファイルをその場で編集した場合、ドキュメントに記載された停止／再起動の動作はどうなりますか」。

サービス別の設定スキーマに関する質問（対応するサービス別スキルを使用します）、DOCA 自体のインストールや BlueField 環境の準備（doca-setup/SKILL.mdを使用します）、ライブラリ API に関する質問（対応する libs/<library> スキルを使用します）、または一般的な Kubernetes クラスターの操作については、このスキルを読み込まないでください。このスキルが扱うのは、BlueField 上の kubelet のスタンドアロンモードであり、Kubernetes の完全なコントロールプレーンではありません。

このスキルで提供する内容

これは薄いローダーです。実質的な内容は、次の2つの関連ファイルに記載されています。

• 機能関連ファイル — BlueField 上での DOCA コンテナデプロイに共通するランタイム契約（BlueField Arm 上で動作する kubelet スタンドアロンエージェントが、文書化された静的 Pod マニフェストディレクトリを監視すること、YAML Pod 仕様の配置がオペレーターの入力単位であること、すべての DOCA サービスで同じパターンが適用されること）、BlueField の前提条件（DOCA のインストール、コンテナランタイム、BFB バージョン、サービスがデバイスをエミュレートする場合のサービスごとのファームウェアスロット、NGC へのイメージプルの到達性、ホスト OS の権限）、可観測性の範囲（kubelet のステータス、コンテナログ、サービス側のライブネスシグナルという3層で、それぞれに独自の管理者が存在）、8層を過不足なく網羅する共通エラー分類（Pod 仕様の構文 → Pod のスケジューリング → イメージプル → ランタイム → ボリュームマウント → ネットワークポリシー → バージョン → ホスト共通）、安全ポリシー（大量展開の前にスモークテストを行うこと、Pod の失敗は重大な問題であること — kubelet が Pod を再起動ループさせる前に根本原因を取り除くこと、Pod 仕様のフィールド名／kubelet フラグ／イメージタグを記憶を頼りに作り出さないこと）。
• タスク関連ファイル — 対象となるデプロイ操作の動詞（configure、build、modify、run、test、debug）について、手順を追ったワークフローを記載し、サービスごとの設定に関する質問、ホストのファームウェアスロットに関する作業、ペアワークロードに関する作業、完全な Kubernetes クラスターに関する作業を、それぞれ担当するスキルに振り分ける Deferred task verbs ブロックも含みます。

このスキルは、Arm 側に DOCA がすでにインストールされ、BlueField OS イメージに kubelet スタンドアロンとコンテナランタイムが公開されている DOCA Container Deployment Guide に従って同梱されており、オペレーターが同ガイドに記載されたホスト OS の権限を持つ BlueField ターゲットを前提としています。DOCA のインストールは対象外です。その手順については doca-setup/SKILL.md を参照してください。また、サービスごとの設定スキーマも再説明しません。これは、doca-public-knowledge-map/SKILL.md から参照される各 DOCA サービスの公開ガイドが正式に扱う内容です。

読み込み順序

1. 最初にこのスキルを読み、ユーザーの質問が対象範囲内（サービスごとの設定スキーマに関する質問ではなく、デプロイのランタイムに共通する内容）であることを確認します。
2. kubelet スタンドアロンモードのランタイム構成、静的 Pod マニフェストディレクトリのルール、ホスト OS／BFB／ファームウェアスロット／イメージプルの前提条件、8層のエラー分類、可観測性の範囲、安全性と大量展開前のスモークテストに関するポリシーについては、機能関連ファイルを参照してください。
3. 手順を追ったワークフロー（configure、build、modify、run、test、debug）については、タスク関連ファイルを参照してください。

関連スキル

• doca-public-knowledge-map/SKILL.md — 公開 Container Deployment Guide、サービスごとのガイド、NGC が記載されています。文書化されたパスとタグはここから引用し、作り出さないでください。
• doca-setup/SKILL.md — BlueField ターゲットでの環境設定とインストール。bare-metal とこのスキルのどちらを選ぶかを判断する認識用の最初の窓口も含みます。
• doca-bare-metal-deployment/SKILL.md — 兄弟関係にあるバイナリ起動の手順です。
• doca-debug/SKILL.md — このランタイムの Pod／イメージ／ENTRYPOINT の各レイヤーが対象となる、横断的なデバッグ手順です。
• doca-version/SKILL.md — 4項目の一致条件とコンテナタグのオーバーレイです。
• doca-structured-tools-contract/SKILL.md — 構造化されたステータスがある場合は、そちらを優先してください。
• サービスごとのオーバーレイ： doca-argus/SKILL.md、 doca-dms/SKILL.md、 doca-firefly/SKILL.md、 doca-urom-svc/SKILL.md。
• doca-programming-guide/SKILL.md — サービスでライブラリエラーが発生した場合の、プログラム側の指針です。