https://yennj12.js.org/yennj12_blog_V4/tags/deployment/Recent content in Deployment on YennJ12 Engineering BlogHugo -- gohugo.ioen-usSat, 04 Jul 2026 12:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/kubernetes-complete-guide-part2-resources-zh/Sat, 11 Oct 2025 12:30:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/kubernetes-complete-guide-part2-resources-zh/🎯 前言 在上一篇文章中，我們了解了 Kubernetes 的基礎概念與架構。本文將深入探討核心資源對象的實務操作，透過大量範例與表格說明，幫助你全面掌握 K8s 的日常操作。 本文重點： kubectl 指令完全指南 Pod 深度解析與操作 Workload 資源管理 Service 與網路配置 Ingress 路由管理 儲存資源操作 配置管理實戰 🔧 kubectl 指令完全指南 kubectl 指令結構 1kubectl [command] [TYPE] [NAME] [flags] 範例： 1kubectl get pods nginx-pod -o yaml 2# ↑ ↑ ↑ ↑ 3# 指令 類型 名稱 選項 基本指令分類 graph TB A[kubectl 指令] --> B[基礎操作] A --> C[部署管理] A --> D[除錯診斷] A --> E[叢集管理] A --> F[設定管理] B --> B1[get, describe<br/>logs, exec] C --> C1[create, apply<br/>delete, scale] D --> D1[logs, exec<br/>port-forward, top] E --> E1[cluster-info<br/>api-resources<br/>api-versions] F --> F1[config<br/>auth] style A fill:#326ce5 style B fill:#4ecdc4 style C fill:#feca57 style D fill:#ff6b6b style E fill:#a8e6cf style F fill:#ffb3ba kubectl 常用指令速查表 基礎操作指令 指令 用途 範例 get 列出資源 kubectl get pods describe 查看詳細資訊 kubectl describe pod nginx create 創建資源 kubectl create deployment nginx --image=nginx apply 應用配置 kubectl apply -f deployment.https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part38-prototype-to-production-zh/Fri, 05 Jun 2026 16:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part38-prototype-to-production-zh/同一個 Agent，Demo 時跑得很好。 上了生產後成本是預估的 8 倍、偶爾 15 秒、有時候對話記憶消失。 「能 Demo」和「可以讓 1,000 個用戶每天用」之間的距離， 就是生產化工程的價值。 面試情境 面試官：「你幫客戶做了一個 3 週的 RAG + Agent POC，Demo 很成功。客戶的 CTO 說：太好了，下個月上線。你說：先等一下，我們需要做幾件事。你會說什麼？」 一、POC 和 Production 的假設差距 POC 的隱性假設： 假設 1：只有你在用（實際：100 個並發） 假設 2：測試資料乾淨（實際：用戶會貼整份合約進來） 假設 3：成本不計較（實際：月底看帳單） 假設 4：出錯了就 debug（實際：1 小時內要給客戶答覆） 假設 5：你挑了最好的 Demo 例子（實際：Murphy's Law） 五個 POC 到 Production 的差距： 差距 1：Token Budget → 成本是預估的 8 倍 差距 2：延遲 SLA → Cold Start 讓 P95 超過 SLA 差距 3：Session State → 重啟後對話記憶消失 差距 4：錯誤處理 → 外部 API Timeout 讓 Agent crash 差距 5：Rollback → Prompt 改錯了沒辦法快速回頭 以下逐一拆解每個差距的成因和設計。 二、差距 1：Token Budget 失控 失控路徑： POC 測試：平均 2,000 input tokens，成本可接受。 ↓ Production 現實： 情況 A：用戶貼了整份合約 input_tokens = 20,000（是預估的 10 倍） 情況 B：Multi-turn 對話 history 累積 第 1 輪：2,000 tokens 第 5 輪：2,000 + (4輪 × 800) = 5,200 tokens 第 15 輪：2,000 + (14輪 × 800) = 13,200 tokens 情況 C：ReAct loop 多跑幾輪 正常：2 輪 Tool Call = 2,000 × 2 = 4,000 tokens 異常：6 輪 Tool Call（遇到困難問題）= 2,000 × 6 = 12,000 tokens Token Budget 設計： ┌─────────────────────────────────────────────────────────────┐ │ 總 Budget：8,000 tokens（可配置） │ │ │ │ ├── System Prompt（固定）：-1,200 tokens │ │ │ （如果 > 1,000 tokens，考慮 Context Caching） │ │ │ │ │ ├── User Query：-actual tokens（優先保留） │ │ │ │ │ ├── Conversation History（最多 30% 剩餘 budget） │ │ │ 超過部分：從最舊的輪次開始截斷 │ │ │ 如果整體 > 10 輪：先壓縮成 Summary │ │ │ │ │ └── Retrieved Context（剩餘 budget） │ │ 按相關性排序，直到 budget 用完 │ └─────────────────────────────────────────────────────────────┘ 成本效益： 無 Budget 管理：預估 $0.https://yennj12.js.org/yennj12_blog_V4/posts/auto-agent-system-part4-production-zh/Sat, 04 Jul 2026 12:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/auto-agent-system-part4-production-zh/「在我電腦上跑得起來」和「能給一群人用」之間,隔著四道牆: 你看得到它在做什麼嗎(可觀測性)?它打包起來多大、部署多快(image)? 它能自動擴縮、掛了會自己重啟嗎(部署)?誰能用、能用什麼由誰決定(權限)? 這一篇,就是 agent_auto_system 翻過這四道牆的過程。 前三篇我們把系統的「能力」講完了:架構(Part 1)、可靠性引擎(Part 2)、實戰任務(Part 3)。這一篇談的是另一個維度——生產化(productionization):讓這套系統能被真實地、多人地、可維運地跑起來。四個主題,對應四個 merged PR。 一、Langfuse 可觀測性:在唯一的漏斗上掛 trace 對應 PR #19:feat(harness): add Langfuse LLM-observability integration Part 2 我們反覆強調:LLM 的「錯」不是當機,而是品質退化——HTTP 200,但答案是編的。你需要一種能看見「品質」的監控,這就是 LLM 可觀測性,而 Langfuse 是這個領域的代表工具。 這個 PR 最漂亮的地方,是它的 PR 描述本身就是一堂架構課: 「CrewAI 1.x 直接呼叫各家原生 provider SDK(不走 litellm),所以要把 Langfuse 掛在 executor——這個已經知道 model、tokens、cost、eval score、status 的唯一漏斗。」 拆解這句話為什麼重要: 很多人以為的 Langfuse 接法: 在「LLM 呼叫的那一行」自動攔截(靠 litellm 之類的中介層) 但 CrewAI 1.x 直接打原生 SDK,沒有那個中介層可攔 │ ▼ 聰明的做法:不在「呼叫點」攔,而在「執行點」記 │ ▼ executor 是所有任務的必經之路,而且它手上早就有: model + tokens + cost + eval score + status → 在這裡發一條 trace,一次到位、還帶品質分數 ┌─────────────────────────────────────────────────┐ │ executor.