ai_cording_with_k8s_knowledge.pdf

2026/10/06 Kubernetes Novice Tokyo #42
AIコーディングで活きたKubernetesの知識

セッション動画
https://k8s-novice-jp.connpass.com/event/405343/
https://www.youtube.com/live/mneDZUdBPhY?si=WhUcUF77wSxA7xWm&t=5102

Transcript

1. AIコーディングで活きたKubernetesの知識 Kubernetes Novice Tokyo #42 2026/10/06 @mochizuki875
2. whoami 🌕 Keita Mochizuki ❤ Kubernetes 🚨 A fox, not a raccoon dog. @mochizuki875
3. whoami 🌕 Keita Mochizuki 偉い👏 🏢 NTT DATA Corporation ernetes 🚨 A fox, not a raccoon dog. @mochizuki875
4. PR: llm-d hands-on llm-dのハンズオンコンテンツを公開しました🎉 GPUがなくても手元のkindで試せる親切(kind)設計です👨💻
5. 導入 ローカルLLMしたい！！ ということで、自宅サーバー上でvLLMを使ってオープンモデルをホスト。 vLLMはOpenAI APIと"ほぼ同等"のAPIを提供するため、 OpenAI SDK等でクライアントを実装し、LLMのAPIを利用できるようになった。 POST /v1/responses POST /v1/chat/completions GPUサーバー Client/SDK 偶然家にあったDGX Spark→ https://docs.vllm.ai/en/stable/serving/online̲serving/
6. 導入 しかしLLMへのリクエストにファイルを直接渡すことができない。 マルチモーダル対応モデルにファイル情報を渡すには、ファイル形式に応じた変換を行う必要がある。 ✔ PDF, O ceファイル: ファイルを画像化&Base64エンコードしたものをimage̲urlとして送信 ✔ TEXT, HTMLファイルなど: ファイルからテキストを抽出して送信 POST /v1/responses POST /v1/chat/completions TEXT { "type": "image̲url", "image̲url": { "url": "data:image/png;base64,iVBORw0KGgoAAA..." } } GPUサーバー Client/SDK 偶然家にあったDGX Spark→ ffi https://docs.vllm.ai/en/stable/serving/online̲serving/
7. OpenAI公式ではFiles APIというAPIが提供されており、 直接アップロードしたファイルを推論に利用できる。 POST /v1/ les Files API le̲id le̲id POST /v1/responses + Client/SDK request le̲id request Responses API le̲idに紐づくファイル情報 を取得して推論を実行 fi https://developers.openai.com/api/reference/resources/ les fi fi fi fi fi 導入
8. 導入 ということで作った ClientとvLLMの間に配置しOpenAIのFiles API互換のAPIを提供するGateway fi https://github.com/mochizuki875/llm- le-gateway
9. ✅ Files APIでファイルがアップロードされたら le̲idを発行しアーティファクト(画像変換&テキスト抽出)に変換 ✅ Responses APIに付加された le̲idからアーティファクトを解決 ✅ リクエストとアーティファクトからリクエストを再構築しvLLMに転送 POST /v1/ les 変換処理 Files API le̲id le̲id TEXT POST /v1/responses + Client/SDK リクエストに統合 request le̲id POST /v1/responses + request request fi fi Responses API fi fi fi fi 導入 request
10. 導入 🤖 はじめてAIでちゃんとしたプロダクトを作った 🧑💻 ある程度アーキテクチャは自分で握っておきたい 💡 Kubernetesの知見が役立った
11. アーキテクチャ検討における課題 課題1: ファイル変換の非同期処理 課題2: 様々なファイル形式の変換処理
12. ✅ LFGのFiles APIではファイルの変換処理を非同期で行う ✅ ファイルアップロード時は即座に le̲idを返却しファイルの変換処理を順次実行 ファイルアップロード アップロードされた ファイルを順次変換 POST /v1/ les Files API Client/SDK TEXT アーティファクトに変換 le̲id fi アップロード完了時点で le̲id返却 fi fi fi 課題1: ファイル変換の非同期処理
13. 課題1のヒント: Controllerで採用されているReconcile Loop Kubernetesでは各種Controllerが所定のリソースを監視し、 そこで定義されたあるべき姿に実態を近づけるように動作する。 e.g. replica=3のReplicaSetを作成するとPodが3台実行された状態が維持される ReplicaSet Controller (kube-controller-manager) ④状態を反映 ③管理対象リソースの状態を取得 Reconcile replicas=3 ①あるべき状態を取得 ②あるべき状態との差分があれば更新 https://kubernetes.io/docs/concepts/architecture/controller/
14. 課題1のヒント: Controllerで採用されているReconcile Loop Controllerの実装をもう少し細かく見ると以下のようになっている。 ✅ Controllerが起動すると内部でWorkerと呼ばれる無限ループが動きQueueを監視する ✅ リソースの更新が発生するとQueueに該当リソースの情報がenqueueされる ✅ Workerはアイテムをdequeueし処理を行う ReplicaSet Controller (kube-controller-manager) Worker Get Reconcile (syncHandler) Re ector Informer EventHandler replicas=3 List&Watch WorkQueue Forget enqueue dequeue fl Done
15. 課題1のヒント: Controllerで採用されているReconcile Loop Controllerの実装をもう少し細かく見ると以下のようになっている。 ✅ Controllerが起動すると内部でWorkerと呼ばれる無限ループが動きQueueを監視する ✅ リソースの更新が発生するとQueueに該当リソースの情報がenqueueされる ✅ Workerはアイテムをdequeueし処理を行う 参考にした部分 ReplicaSet Controller (kube-controller-manager) Worker Get Reconcile (syncHandler) Re ector Informer EventHandler replicas=3 List&Watch WorkQueue Forget enqueue dequeue fl Done
16. LFGでもControllerの非同期処理を参考に以下のように実装 ✅ Queueを監視するWorkerを起動 ✅ Files APIでファイルがアップロードされたらファイル情報をQueueにenqueue ✅ WorkerがQueueからファイル情報をdequeueして変換処理を実行 Worker Get POST /v1/ les Convert (convertHandler) WorkQueue Files API enqueue dequeue TEXT アーティファクトに変換 le̲id endConversion fi fi 課題1: LFGでの対応
17. 課題1: LFGでの対応 KubernetesのReplicaSet Controllerの実装 LFGの実装 func (rsc *ReplicaSetController) worker(ctx context.Context) { for rsc.processNextWorkItem(ctx) { } } func (service *Service) worker(ctx context.Context, id int) { for service.processNextJob(ctx) { } } func (rsc *ReplicaSetController) processNextWorkItem(ctx context.Context) bool { key, quit := rsc.queue.Get() // Queueからアイテムを取り出す if quit { return false } defer rsc.queue.Done(key) func (service *Service) processNextJob(ctx context.Context) bool { job, quit := service.queue.Get(ctx) // Queueからアイテムを取り出す if quit { return false } err := rsc.syncHandler(ctx, key) // Reconcile処理を実行 if err == nil { rsc.queue.Forget(key) return true } utilruntime.HandleError(fmt.Errorf("sync %q failed with %v", key, err)) rsc.queue.AddRateLimited(key) return true } err := service.processJob(ctx, job) // Convert処理を実行 service.handleErr(ctx, err, job) return true }
18. 課題2: 様々なファイル形式の変換処理 ✅ Files APIにアップロードされるファイル形式は様々 ✅ ファイル形式によってアーティファクトへの変換ロジックが異なる ✅ 既存変換ロジックの見直しや新しい拡張子を追加する毎にLFG本体を変更する必要がある switch format { case "pdf": // PDFファイル用の変換処理 case "docx": // Wordファイル用の変換処理 case "xlsx": // Excel用の変換処理 ... TEXT Files API アーティファクトに変換 Convert ファイル形式に応じた変換処理を実行
19. 課題2のヒント: SchedulerにおけるScheduling Framework KubernetesにPodをデプロイする際、FilterとScoreをはじめとしたフェーズを経由して スケジュール先Nodeを決定する。 各フェーズは拡張ポイントになっており、プラグインとして様々な処理を登録可能。 https://kubernetes.io/docs/concepts/scheduling-eviction/scheduling-framework/
20. 課題2のヒント: SchedulerにおけるScheduling Framework Filterフェーズの例 ✅ スケジュール対象Podに対しKubernetesクラスタのNodeからスケジュール先となり得るNodeを選択 ✅ 様々なFilterロジックがプラグインとして登録されており固有のFiltering処理を担う ✅ SchedulerとPluginの間に共通の規則(Interface)を設けることで処理を呼び出す側と処理を実装する側の責務を分離 Filter NodeName Plugin 処理を呼び出す NodeUnschedulable Plugin 共通規則 Node Filterという (FilterPlugin Interface) スケジュール対象Pod TaintToleration Plugin スケジュール先 Nodeの候補 NodeA nity Plugin ・ ・ ・ Filterという 処理を実装 ffi 登録されたプラグインを 順番に実行
21. 課題2のヒント: SchedulerにおけるScheduling Framework Filterフェーズの例 ✅ スケジュール対象Podに対しKubernetesクラスタのNodeからスケジュール先となり得るNodeを選択 ✅ 様々なFilterロジックがプラグインとして登録されており固有のFiltering処理を担う ✅ SchedulerとPluginの間に共通の規則(Interface)を設けることで処理を呼び出す側と処理を実装する側の責務を分離 参考にした部分 Filter NodeName Plugin 処理を呼び出す NodeUnschedulable Plugin 共通規則 Node Filterという (FilterPlugin Interface) スケジュール対象Pod TaintToleration Plugin スケジュール先 Nodeの候補 NodeA nity Plugin ・ ・ ・ Filterという 処理を実装 ffi 登録されたプラグインを 順番に実行
22. 課題2: LFGでの対応 LFGでもScheduling Frameworkを参考に以下のように実装 ✅ 共通の規則であるDocumentConverter Interfaceを定義 ✅ 拡張子に応じた変換処理を実装したConverterをプラグイン形式で登録 ✅ ファイル拡張子に応じたConverterを選択して変換処理を実行 Converter Convertという 処理を呼び出す PdfConverter or DocxConverter 共通規則 変換対象ファイル (DocumentConverter Interface) ファイル形式に適した Converterを選択 or XlsxConverter or PptxConverter ・ ・ ・ Convertという 処理を実装 TEXT アーティファクトに変換
23. 課題2: LFGでの対応 KubernetesのReplicaSet Controllerの実装 LFGの実装 SchedulerにおけるFilter処理の呼び出し LFGにおけるConvert処理の呼び出し func (f *frameworkImpl) runFilterPlugin(...) *fwk.Status { ... status := pl.Filter(ctx, state, pod, nodeInfo) // Filter処理の呼び出し ... } func (service *Service) convert(ctx context.Context, job conversionJob) error { ... ̲, err = documentConverter.Convert(ctx, source, lepath.Join( lepath.Dir(source), "derived"), converter.Options{...}) // Convert処理の呼び出し ... FilterPlugin Interfaceの定義 DocumentConverter Interfaceの定義 type FilterPlugin interface { ... type DocumentConverter interface { ... // Filterの共通規則 Filter(ctx context.Context, state CycleState, pod *v1.Pod, nodeInfo NodeInfo) *Status // Convertの共通規則 Convert(ctx context.Context, source, outputDir string, options Options) (Result, error) Filter処理の実装 Convert処理の実装 NodeName Plugin PdfConverter func (pl *NodeName) Filter(ctx context.Context, ̲ fwk.CycleState, pod *v1.Pod, nodeInfo fwk.NodeInfo) *fwk.Status { // NodeNameを満たすNodeを選択する処理 } func (documentConverter pdfConverter) Convert(ctx context.Context, source, outputDir string, options Options) (Result, error) { // PDF形式のファイルを変換する処理 } NodeUnschedulable Plugin DocumentConverter func (pl *NodeUnschedulable) Filter(ctx context.Context, ̲ fwk.CycleState, pod *v1.Pod, nodeInfo fwk.NodeInfo) *fwk.Status { // スケジュール不可(e.g. cordon)なNodeを除外する処理 } func (documentConverter docxConverter) Convert(ctx context.Context, source, outputDir string, options Options) (Result, error) { // DOCX形式のファイルを変換する処理 } fi } fi }
24. まとめ ✅ AIにコードを書くのを任せる時代でも実装アーキテクチャの知識が役に立つ (KubernetesというよりGoの実装知識かもしれないが、自身はそれをKubernetesで学んだ) ✅ 自分のコンテキストをベースに実装されているとコードを読むとなった場合に理解しやすい
25. Thank You!!