Ray Liu's Blog

前言經過前五篇的學習，你已經掌握了 Kubernetes 的核心概念。本篇將綜合運用這些知識，完成一個完整微服務應用的部署： 設計應用架構 使用 Helm 簡化部署 多環境配置管理 日誌與監控整合 常見問題排除 讓我們開始真正的實戰！ 應用架構設計範例應用：電商平台我們將部署一個簡化版的電商微服務系統： graph TD USER[使用者] -->|HTTPS| ING[Ingress] ING --> GW[API Gateway] GW --> USVC[User Service] GW --> PSVC[Product Service] GW --> OSVC[Order Service] USVC --> REDIS[(Redis)] PSVC --> PDB[(PostgreSQL<br/>Products)] OSVC --> ODB[(PostgreSQL<br/>Orders)] OSVC --> M...

前言當應用程式部署到 K8s 後，如何確保它穩定運行且高效利用資源？本篇將探討： 資源管理：設定 CPU 和記憶體的請求與限制 自動擴展：根據負載自動調整 Pod 數量 調度策略：控制 Pod 在哪些節點上運行 健康檢查：確保只有健康的 Pod 接收流量 這些是生產環境部署的必備知識。 資源管理：Requests 與 Limits為什麼需要資源管理？沒有資源限制的情況下： 某個 Pod 可能消耗所有 CPU/記憶體 導致其他 Pod 無法正常運行 節點可能因 OOM（Out of Memory）崩潰 graph TD subgraph "沒有限制" A[Pod A] -->|佔用 80% CPU| N1[Node] B[Pod B] -->|飢餓| N1 C[Pod C] -->|飢餓| N1 end subgraph "有限制" D[Pod A: 限制 30%] --> N2[Node] ...

前言應用程式除了程式碼本身，還需要配置資訊（如資料庫連線設定）、敏感資訊（如密碼）以及資料持久化。Kubernetes 提供了完整的解決方案： ConfigMap：管理非敏感配置 Secret：管理敏感資訊 Volume：提供資料儲存 本篇將深入探討這些資源的使用方式和最佳實踐。 ConfigMap：配置管理為什麼需要 ConfigMap？在容器化之前，我們可能這樣管理配置： 配置寫在程式碼裡（❌ 難以修改） 使用環境變數（✅ 但不易管理） 使用配置檔案（✅ 但需要掛載） ConfigMap 統一解決這些問題，將配置與容器映像檔分離。 graph LR CM[ConfigMap] -->|環境變數| POD1[Pod] CM -->|掛載檔案| POD2[Pod] CM -->|命令列參數| POD3[Pod] 創建 ConfigMap方法一：從文字值創建1234kubectl create configmap app-config \ --from-literal=DATABASE_HOST=db.example.co...

前言上一篇介紹了 Pod、Deployment 與 Service 的基本角色，但「有一個 Service」和「封包真的走得通」是兩件不同的事。本篇不再把網路元件當成名詞表，而是從一個 Pod 內的 localhost 開始，逐層追蹤封包如何走到另一個 Pod。 你會看到 network namespace、veth pair、Node routing、CNI、EndpointSlice、Service VIP 與 CoreDNS 各自負責哪一段。不同叢集可能使用 overlay、雲端 VPC 原生路由、eBPF 或其他資料平面，但 Kubernetes 對使用者提供的抽象仍然可以用同一套問題來理解：誰在查名字？誰在選後端？誰在搬封包？誰在阻擋封包？ 本篇完成後，你應該能回答： 同一個 Pod 裡的兩個 container，為什麼可以用 localhost 互相呼叫？ Pod A 直接連 Pod B 的 Pod IP，和連 Service 的 ClusterIP 有什麼不同？ 同節點與跨節點的封包，通常會經過哪些網路介面與路由？ CoreDNS 為什麼只參與 DNS loo...

前言上一篇文章介紹了 Kubernetes 的控制平面與節點元件。本篇把焦點移到「應用程式到底要如何在叢集中運行」：你要部署的是可替換的 Web API、需要固定身份的資料服務、每台節點都要有一份的 agent，還是跑完就結束的批次工作？ Kubernetes 的 Workload 資源不是一堆互相獨立的 YAML 名詞，而是不同的生命週期模型。讀完本篇，你應該能先選對資源，再從 Pod、Controller、節點與容器四個層次判斷「誰會重啟、誰會補 Pod，以及為什麼」。 本篇會用幾個可以直接套用到測試叢集的實驗，觀察 Deployment 的滾動更新、StatefulSet 的固定身份、DaemonSet 隨節點變化的行為，以及 Job/CronJob 的完成與重試。為了讓主題保持集中，Service 只保留必要基礎；CoreDNS、EndpointSlice、CNI、L4/L7 與 Ingress 的封包路徑留到後續網路篇深入拆解。 實驗假設你已經有可使用的 Kubernetes 叢集與 kubectl。除非特別說明，以下資源都放在目前 conte...

前言如果你已經熟悉 Docker，應該很習慣用 docker run 啟動容器、用映像檔部署應用程式。但 Kubernetes 的難點不在於「如何再寫一份更長的 YAML」，而在於它把一個應用程式拆成多個控制迴圈、API 物件、節點元件與網路層，讓整個叢集持續朝你宣告的狀態靠近。 這篇文章的目標，是先建立一張可以用來排錯的地圖：當你執行 kubectl apply 後，誰儲存設定、誰建立 Pod、誰選擇 Node、誰啟動容器，以及 Pod 為什麼可能一直停在 Pending 或 Ready=False。讀完後，你應該能解釋 Kubernetes 的控制平面、節點元件與資料平面各自負責什麼，而不是只背一張元件名稱表。 本文刻意不把 StatefulSet、DaemonSet、Job 等 Workload 類型逐一展開，也不在這裡完整拆解 Pod-to-Pod 的封包路徑。前者會在下一篇 Workload 實戰篇處理，後者會在網路篇從 Network Namespace、CNI、Service 與 CoreDNS 開始拆開。本篇先回答更基礎、也更常影響排錯方向的問題：Kubern...

前言歡迎來到「AWS 服務系列」的最終章。在前面的七篇文章中，我們從基礎的運算、儲存、網路，一路探討到訊息佇列、DevOps 以及監控系統。掌握單一服務的使用是基礎，但作為一名資深的後端工程師或架構師，真正的挑戰在於如何將這些服務組合成一個高可用 (High Availability)、高容錯 (Fault Tolerance)、安全且成本效益最佳化的系統。 本篇文章將整合前面所學，深入探討 AWS 上的進階架構設計模式，包括災難復原 (DR) 策略、成本優化技巧，以及 AWS Well-Architected Framework 的核心精神。 高可用性 (High Availability) 與容錯設計高可用性是指系統在長時間內保持正常運作的能力。在 AWS 上，實現 HA 的核心原則是消除單點故障 (Single Point of Failure, SPOF)。 1. Multi-AZ 架構 (多可用區)這是最基礎的 HA 策略。永遠不要將所有的資源部署在同一個 Availability Zone (AZ)。 運算層：使用 Auto Scaling Group (AS...

前言在分散式系統中，「系統是否正常運作？」已經不再是一個簡單的是非題。我們需要知道「為什麼回應變慢了？」、「哪個服務出現瓶頸？」、「是誰修改了這個設定？」。這就是**可觀測性（Observability）**的核心價值。 AWS 提供了強大的監控三劍客：CloudWatch（監控與日誌）、X-Ray（分散式追蹤）與 CloudTrail（稽核紀錄）。本篇將教你如何整合這三個工具，構建全方位的監控體系。 本篇重點： 可觀測性三大支柱：Metrics、Logs、Traces CloudWatch Metrics 與 Alarm 警報策略 CloudWatch Logs Insights 進階查詢技巧 X-Ray 分散式追蹤實戰 CloudTrail 安全稽核與故障排查 可觀測性三大支柱graph TD subgraph "Observability" A[Metrics 指標] -->|CloudWatch Metrics| D[趨勢分析、警報] B[Logs 日誌] -->|CloudWatch Lo...

前言在現代軟體開發中，手動部署已經成為過去式。自動化部署不僅能減少人為錯誤，還能加快交付速度，讓開發團隊專注於功能開發而非維運瑣事。 AWS 提供了一套完整的 DevOps 工具鏈，從程式碼託管、建置、測試到部署，以及基礎設施即程式碼（IaC）服務。本篇將深入探討： AWS Code 系列服務：CodeCommit, CodeBuild, CodeDeploy, CodePipeline CloudFormation：AWS 的 IaC 基石 AWS CDK：用程式語言定義基礎設施 實戰：構建一個完整的 CI/CD 流水線 AWS Code 系列服務全景graph LR subgraph "Source" A[CodeCommit] -->|Git Push| B[CodePipeline] G[GitHub] -->|Webhook| B end subgraph "Build" B -->|Source Artifac...

前言在微服務架構中，「解耦（Decoupling）」是至關重要的設計原則。透過非同步通訊，我們可以讓服務之間不再緊密相依，提高系統的可擴展性與容錯能力。 AWS 提供了完整的應用程式整合服務，幫助我們構建事件驅動架構（Event-Driven Architecture）。本篇將深入探討： SQS：可靠的訊息佇列服務 SNS：高吞吐量的發布/訂閱服務 EventBridge：無伺服器事件匯流排 Kinesis：即時資料串流處理 實戰：如何選擇正確的整合模式 應用程式整合服務全景graph TB subgraph "Point-to-Point" A[SQS] -->|佇列| B[消費者] end subgraph "Pub/Sub" C[SNS] -->|Fan-out| D[SQS 1] C -->|Fan-out| E[SQS 2] C -->|Fan-out| F[Lambda] end ...