Kubernetes

Kubernetes Staging 環境省錢術：從踩坑到正確實作

起因：老闆想省錢「Staging 環境平常沒人用，每個月還要燒 $45-60 美金，能不能想辦法省一點？」 Staging 環境的成本來自兩個地方：RDS 資料庫（約 $15-20/月）和 EKS 節點（約 $30-40/月）。既然平常沒在用，我想到了一個方案：不用的時候關掉，需要的時候再打開。於是我寫了兩個腳本： staging-start.sh：啟動 RDS、擴充節點、部署應用 staging-stop.sh：刪除部署、縮減節點、停止 RDS # staging-stop.sh 核心邏輯 kubectl delete deployment app-strapi-stg app-web-stg aws eks update-nodegroup-config \ --cluster-name my-cluster \ --nodegroup-name my-nodegroup \ --scaling-config minSize=0,maxSize=2,desiredSize=1 # 從 2 縮到 1 aws rds stop-db-instance --db-instance-identifier my-stg-rds 看起來很合理，但這裡有個問題：Production 和 Staging 共用同一個 nodegroup。踩坑：AWS 隨機選擇刪除節點執行 staging-stop.sh 縮減節點時，AWS 會隨機選擇要終止哪個節點。當時的配置：節點 A：運行 Production pods 節點 B：運行 Staging pods 我期望刪除節點 B，但 AWS 選了節點 A。Production pods 被強制遷移，觸發了重新調度。 ...

在 Kubernetes 上部署 OV SSL 證書：完整實戰指南

為什麼選擇 TWCA OV 證書在生產環境中，使用自簽憑證會導致瀏覽器顯示不安全警告，影響使用者信任。雖然 Let’s Encrypt 提供免費的自動化證書，但某些企業或政府專案需要台灣在地的認證機構簽發證書以符合法規要求。 SSL 證書的三個等級 SSL 證書依據驗證強度分為三個等級：證書類型驗證內容適用場景信任標記價格 DV (Domain Validation) 僅驗證網域所有權個人網站、部落格 🔒 基本鎖頭免費～低 OV (Organization Validation) 驗證組織身份企業網站、SaaS 服務 🔒 組織名稱中 EV (Extended Validation) 嚴格驗證企業金融、電商、政府 🟢 綠色網址列高本文使用的是 TWCA OV SSL 證書，它提供： ✅ 組織身份驗證（瀏覽器可顯示公司名稱） ✅ 完整的證書鏈（受所有主流瀏覽器信任） ✅ 12 個月有效期 ✅ 台灣在地技術支援 HTTPS 與 SSL/TLS 運作原理在深入部署之前，先理解 HTTPS 如何保護資料傳輸：關鍵機制說明：非對稱加密（RSA/ECDSA）：只用於金鑰交換，確保 session key 安全傳輸對稱加密（AES）：實際資料傳輸使用，效能更好證書鏈驗證（完全離線）：瀏覽器使用內建的 TWCA 根憑證驗證整個證書鏈，不需要連線到 TWCA 中間人攻擊防護：因為攻擊者沒有伺服器的私鑰，無法解密通訊 💡 重要觀念： TWCA 只在簽發證書時參與，TLS 握手過程中完全不涉及。瀏覽器使用內建的根憑證庫（包含 TWCA 根憑證）進行離線驗證。 ...

Vue.js SPA 社交分享完整指南：解決 Facebook/LINE OpenGraph 爬蟲問題

引言：當精美的網站變成分享時的「無名氏」在現代 Web 開發中，社交媒體分享功能是不可或缺的一部分。當用戶在 Facebook、LINE 或其他社交平台分享你的網站連結時，你希望顯示的是精美的預覽卡片，而不是空白或錯誤的資訊。然而，對於使用 Vue.js、React、Angular 等前端框架開發的單頁應用程式（SPA），這個看似簡單的需求卻隱藏著技術挑戰。本文將完整記錄從問題發現、原因分析、到解決方案實作的全過程。問題發現：為什麼分享連結總是顯示預設值？場景描述我的平台 www.abc.com 是一個基於 Vue.js 3 + Strapi CMS 的網站。某天，我發現一個嚴重問題：當用戶分享服務頁面（如 https://www.abc.com/service-us/6）到 Facebook 或 LINE 時，顯示的預覽資訊總是預設值，而非該服務的實際標題和描述。實際情況對比：情境期望結果實際結果分享服務頁面顯示「專業網站開發服務」顯示「ABCDEFG（預設標題）」分享部落格文章顯示文章標題與摘要顯示網站預設描述分享產品頁面顯示產品圖片與名稱顯示網站 Logo 診斷工具測試使用 Facebook Open Graph Debugger 測試後發現：爬蟲抓取到的 HTML： <!DOCTYPE html> <html lang="zh-TW"> <head> <meta charset="UTF-8"> <title>ABCDEFG</title> <meta property="og:title" content="ABCDEFG"> <meta property="og:description" content="預設網站描述">  </head> <body> <div id="app"></div> <script src="/assets/index.js"></script> </body> </html> ⚠️ 關鍵發現：爬蟲只看到靜態的 HTML 模板，完全沒有 JavaScript 執行後動態生成的 meta 標籤。 ...

深入理解 Kubernetes Pod：從基礎概念到實戰應用

前言：為什麼需要 Pod？在 Kubernetes 的世界裡，Pod 是一切的基礎。如果把 Kubernetes 比喻成一座城市，那麼 Pod 就是城市中的「最小住宅單位」。但為什麼 Kubernetes 不直接管理容器（Container），而要多一層 Pod 的抽象？簡單回答：因為容器太小，Pod 剛剛好。想像你要管理一座城市的住宅：如果直接管理每個「房間」（容器）→ 太細碎，管理成本太高如果直接管理整棟「大樓」（Node）→ 太粗糙，缺乏彈性所以我們需要「住宅單位」（Pod）→ 大小適中，便於管理本文將深入探討： Pod 的核心概念與設計哲學 Pod 的內部架構與運作機制 Pod 網路模型與通訊方式 Pod 生命週期與狀態管理 Pod 設計模式與最佳實踐實戰範例與 YAML 配置 Pod 核心概念：容器的邏輯主機什麼是 Pod？官方定義： Pod 是 Kubernetes 中最小的可部署計算單元，可以包含一個或多個容器，這些容器共享網路、儲存和其他資源。生活化比喻： Pod 就像一個「邏輯主機」：在傳統架構中，多個應用程式運行在同一台虛擬機上在 Kubernetes 中，多個容器運行在同一個 Pod 上 Pod 提供了容器之間的「緊密耦合」環境 Pod 的三大核心特性 1. 共享網路命名空間同一個 Pod 內的容器： ✅ 共享同一個 IP 位址 ✅ 可以透過 localhost 互相通訊 ✅ 但 Port 不能衝突（每個容器用不同 Port） 2. 共享儲存卷（Volume） ...

從 GitLab CI 到 Kubernetes 自動化部署：完整 CI/CD Pipeline 實戰指南

引言：打破手動部署的迷思「為什麼我的 CI 已經產出 prod-0.54，卻還得手動去跑 kubectl apply -f deployment.yaml？那不是多此一舉嗎？」如果你也曾陷入這樣的疑問，本文將從根本理清 CI/CD 與 Kubernetes 之間的分工，並學會如何「一鍵從程式碼到雲端服務」完全自動化。 CI/CD vs. Kubernetes：各司其職的完美搭檔在軟體開發的世界裡，GitLab CI/CD 和 Kubernetes 常常被搭在一起討論，卻扮演著截然不同的角色。 CI/CD 的職責：生產線 GitLab CI/CD 的工作內容：建置（Build）：將程式碼打包成 Docker 映像標記（Tag）：為映像貼上版本號標籤（例如 0.54、v1.0.0）推送（Push）：把 Docker 映像推到映像庫（AWS ECR、Docker Hub） Kubernetes 的職責：配送中心 Kubernetes 的工作內容：部署（Deploy）：在叢集裡建立 Pod 並執行容器監控（Monitor）：監控運行狀況，Pod 死掉自動重啟更新（Update）：滾動更新（Rolling Update）時保證服務不中斷維運（Operate）：調整副本數量、健康檢查、網路規則分工比喻如果把軟體交付比喻成流水線：角色比喻職責 CI/CD 工廠組裝工人把原料（程式碼）生產成成品（Docker 映像），打上編號（Tag） Kubernetes 物流配送中心拿到成品後送到倉庫（叢集），確保正確分配、穩定運行 ⚠️ 關鍵問題：若只把「生產出映像」交給 CI/CD，卻沒有「派送到叢集裡面運行」的步驟，流程就會中斷——就好比你生產一箱箱可口可樂，卻一直放在廠區裡沒人去配送到超商。完整自動化流程架構讓我們先看看完整的自動化部署流程：流程說明： ...

如何使用 psql 連線 AWS RDS PostgreSQL 並在容器與 Pod 中操作

前言在現代雲端架構中，資料庫通常部署在受保護的私有網路環境（Private Subnet）中，以提升安全性。AWS RDS（Relational Database Service）作為主流的托管資料庫服務，提供了多種連線方式，但對於初學者來說，如何在不同環境（本機、Docker、Kubernetes）中正確連線到 RDS 往往充滿挑戰。這篇文章將深入探討： AWS RDS 網路架構：公有子網 vs 私有子網的差異直接連線方式：當 RDS 設為 Publicly Accessible 時 SSH 隧道（SSH Tunneling）：透過 Bastion Host 連線私有 RDS 容器環境連線：在 Docker 和 Kubernetes Pod 中使用 psql psql 完整命令參考：從基礎查詢到進階操作安全最佳實踐：如何保護資料庫連線與憑證常見問題排查：連線失敗的系統化診斷方法無論你是在本機開發、容器化部署、或是 Kubernetes 叢集中操作，這篇文章都能幫助你建立安全可靠的資料庫連線。 AWS RDS 網路架構概覽在開始連線之前，我們需要理解 AWS RDS 的網路架構。RDS 實例可以部署在不同的網路環境中，每種配置都有不同的連線方式和安全考量。公有子網 vs 私有子網兩種部署方式的比較特性公有子網 (Publicly Accessible) 私有子網 (Private) 直接連線 ✅ 可以從網際網路直接連線 ❌ 無法直接連線安全性 ⚠️ 較低，暴露在公網 ✅ 高，完全隔離連線方式 psql 直連需要 Bastion Host / VPN 適用場景開發測試環境生產環境（推薦）成本 RDS 費用 RDS + Bastion Host 費用維護複雜度低中等（需管理 Bastion）最佳實踐： ...

整合 Google 登入至 Strapi：在 Kubernetes 上解決「Secure Cookie over Unencrypted Connection」的實戰紀錄

前言在現代 Web 應用開發中，提供第三方登入（Social Login）已經成為標準配備。相比傳統的帳號密碼註冊流程，使用 Google、Facebook、GitHub 等服務登入不僅能降低使用者註冊門檻，還能提升安全性（由大廠處理密碼儲存與驗證）。當我們決定為 Strapi CMS 後台加入 Google OAuth 登入時，原本以為只是個簡單的設定任務：在 Google Cloud Console 建立 OAuth 2.0 憑證在 Strapi 填入 Client ID 和 Client Secret 點擊「Login with Google」按鈕，完成！但現實總是更複雜。當應用部署到 Kubernetes 叢集後，我們遇到了一個令人困惑的錯誤訊息： Error: Cannot send secure cookie over unencrypted connection 這個錯誤訊息背後，牽涉到 HTTP/HTTPS 協定、Proxy Trust 機制、Kubernetes Ingress 架構、以及瀏覽器 Cookie 安全策略等多層知識。這篇文章將完整記錄我如何一步步拆解問題、理解根本原因、並最終在生產環境中實現安全可靠的 Google 登入功能。 OAuth 2.0 授權碼流程基礎在深入問題之前，我們先理解 Google OAuth 登入的完整流程。OAuth 2.0 提供了多種授權模式（Grant Types），而 Web 應用最常使用的是「授權碼模式（Authorization Code Flow）」。這個流程中有幾個關鍵點： ...

解決 Strapi CMS 正式環境空白頁的踩坑經驗分享

前言：一個簡單的環境變數引發的災難在部署 Strapi CMS 到 Kubernetes 正式環境時，只是加了一行看似無害的環境變數設定： env: - name: NODE_ENV value: production # 就是這一行！結果卻導致整個管理後台變成一片空白，連登入頁面都看不到。更詭異的是： ✅ API 完全正常，GraphQL 和 REST 都能回應 ✅ Pod 狀態正常，沒有任何錯誤訊息 ✅ 日誌顯示 Strapi 成功啟動 ❌ 瀏覽器打開 /admin 卻是一片空白這種「Schrodinger 的服務」（同時正常又不正常）讓人抓狂。經過一番排查，終於發現罪魁禍首是 CSP (Content Security Policy) 在作怪。本文將深入探討：為什麼正式環境會出現空白頁 CSP 的工作原理與安全機制完整的問題排查步驟如何正確配置 Strapi 的安全策略生產環境的安全最佳實踐問題背景：開發正常，正式環境空白環境差異對比問題現象詳細描述 Kubernetes Deployment 設定： apiVersion: apps/v1 kind: Deployment metadata: name: strapi-prod namespace: default spec: replicas: 1 selector: matchLabels: app: strapi template: metadata: labels: app: strapi spec: containers: - name: strapi image: myregistry.com/strapi:v5.0.0 env: - name: NODE_ENV value: production # 問題的起點 - name: DATABASE_HOST valueFrom: secretKeyRef: name: strapi-db-secret key: host - name: ADMIN_JWT_SECRET valueFrom: secretKeyRef: name: strapi-admin-secret key: jwt-secret ports: - containerPort: 1337 部署後的症狀： ...

解決 Kubernetes 多餘 Pod 問題與 CrashLoopBackOff 的實戰心得

前言：一次神秘的 Pod 複製事件在一次例行的 Strapi CMS 更新部署到 AWS EKS 時，遇到了一個詭異的現象：明明 Deployment 設定檔中清楚寫著 replicas: 1，但實際運行的 Pod 卻有兩個！更奇怪的是，其中一個 Pod 持續處於 CrashLoopBackOff 狀態，而另一個則正常運行。無論怎麼刪除多餘的 Pod，它總是會像打不死的蟑螂一樣再次出現。這種「靈異事件」讓我開始懷疑 Kubernetes 是不是有自己的想法… 本文將深入探討：為什麼會出現多餘的 Pod CrashLoopBackOff 背後的機制 Kubernetes Deployment 和 ReplicaSet 的運作原理實戰排查步驟與解決方案 Secret 編碼陷阱與預防措施問題背景：Deployment 說一個，實際卻有兩個問題現象預期行為： # my-strapi-prod-deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: name: my-strapi-prod spec: replicas: 1 # 只要 1 個 Pod selector: matchLabels: app: my-strapi-prod 實際情況： $ kubectl get pods -n default | grep my-strapi-prod NAME READY STATUS RESTARTS AGE my-strapi-prod-7d4b5c8f9d-x2k4p 1/1 Running 0 10m my-strapi-prod-8c9a6d7e5f-w8n2q 0/1 CrashLoopBackOff 5 5m 兩個 Pod 同時存在，卻只有一個正常運行！ ...

EKS Pod 卡在 Pending？從 Too Many Pods 到 ENI / CNI 限制全面解析

前言：一個讓人懷疑人生的 Pending 狀態最近部署 Strapi CMS 到 AWS EKS 時，遇到一個詭異的情況： $ kubectl get pods -n default NAME READY STATUS RESTARTS AGE mycompany-strapi-prod-695854fbd4-dzw66 0/1 Pending 0 3h42m 一個 Pod 卡在 Pending 狀態超過三小時，CPU 和 Memory 明明還很充足，但就是起不來。如果你曾經盯著 kubectl get pods 看著那個永遠不會變成 Running 的 Pending 狀態，同時懷疑是不是 Kubernetes 在跟你開玩笑——恭喜你，你不孤單。在嘗試了 Google 前五個搜尋結果、檢查了三次 YAML 設定、並認真考慮是否該轉行當咖啡師之後，我終於找到了問題的根源… ⚠️ 劇透警告：問題的根源不是 CPU、不是 Memory，而是一個你可能從沒注意過的限制——網卡（ENI）和 IP 數量。問題診斷：一步步找出真兇 Step 1：查看 Pod 事件遇到 Pending 狀態，第一步當然是看看 Kubernetes 到底在抱怨什麼： $ kubectl describe pod mycompany-strapi-prod-695854fbd4-dzw66 -n default 輸出內容很長，但最重要的是 Events 區塊： ...