AWS認證帳號開戶 AWSKubernetes集群搭建與EKS生產環境配置

第一章：為什麼是 EKS，以及生產環境要先想什麼

在雲端上跑 Kubernetes，常見路徑有自建、使用託管服務、或用半託管方案。自建意味著你要維護控制平面、版本升級、可用性與安全邊界；託管服務則把「底層麻煩」交給雲商，但你仍要對「上層架構」負責——網路、身份、工作負載治理、可觀測性、交付流程與災備。EKS 的價值就在於：它把控制平面託管了，但仍能讓你保留 Kubernetes 的一致性與可擴展性。

不過，生產環境要先想的不是怎麼「跑起來」，而是怎麼在失效、升級、擴容、資安稽核、成本壓縮和人員交接時保持穩定。你需要提前把決策寫進架構：

• 集群網路的隔離與地址計畫（VPC、子網、路由、NAT、入口方式）。
• AWS認證帳號開戶 節點與工作負載的安全邊界（安全組、最小權限 IAM、祕密管理、Pod 身份）。
• 可用性與容錯（多可用區、節點類型、滾動更新策略、中斷處理）。
• 治理能力（命名空間、配額、資源限制、限制出網、審計）。
• 可觀測性（指標、日誌、告警、追蹤），以及「定位問題」的流程。
• 交付與版本策略（叢集版本、控制平面與節點版本匹配、鏡像與部署策略）。
• 成本與用量管理（節點擴縮策略、Spot/On-Demand 比例、日常診斷）。

這些問題不先回答，部署完成後你通常會在最痛的地方補救：例如把網路改成不相容、在沒有可觀測性時追查事故、或在升級控制平面時遇到版本差異。

第二章：AWS 上搭建 EKS 的整體規劃

要把 EKS 做成「可交付、可維護、可擴展」的生產平台，建議從一開始就用清晰的分層設計。你可以把整體分成三層：底層網路與安全、集群與節點、以及工作負載與運維能力。

2.1 環境分層與命名規範

至少準備三個維度：環境（dev/stage/prod）、功能域（平台/業務）、以及資源類型（VPC、子網、節點池、安全組等）。命名要可讀且可搜尋。例如：

• 環境域：prod、stage、dev。
• 業務域：core、billing、web、batch。
• 資源類型：vpc、subnet-priv-az1、nodepool-system、sg-eks-worker。

AWS認證帳號開戶 很多事故的根源是「找不到資源」或「不知道資源歸誰管」。清晰命名能讓排查效率提高一個級別。

2.2 區域與可用區選擇

EKS 在多可用區部署能降低單點故障。通常至少使用兩個 AZ；生產建議使用三個 AZ，以便控制平面與節點分散。注意：你後續會用到子網與節點池的映射，如果只用兩個 AZ 但又要求擴容到三個 AZ，改造成本高。

2.3 叢集模式與版本策略

EKS 通常分為標準叢集部署與託管 add-ons。建議採用託管 add-ons 來降低維護負擔。同時要設定「升級節奏」：控制平面與節點版本的兼容策略要清楚。生產環境一般採取「先測試再推進」，並保留回滾能力（至少可回到之前的節點映像與部署鏡像版本）。

第三章：VPC、子網與網路通道設計

網路是 Kubernetes 在雲端上最容易出現隱性問題的地方。你會在這裡遇到： Pod 網段是否與 VPC 重疊、路由是否正確、是否能出網、入口是否符合合規、以及 NAT 成本與可用性。

3.1 VPC CIDR 與 Pod/Service CIDR

先定義 VPC 的主要 CIDR，接著規劃子網（公網/私網）。然後為 EKS 的 Pod CIDR（或 IPv4 Pod 方案/或藉由 VPC CNI 的模式）與 Service CIDR 做排除。關鍵原則是：Pod 網段與 VPC 主網段不得重疊；同時要與公司內部 VPN/Direct Connect 的路由計畫協調。

實務上，我會建議預留一段地址空間給未來擴充，例如是否要接入更多 VPC、是否有跨環境互通需求。地址規劃做得保守，後續才不會被迫改造。

3.2 子網：公網與私網的角色

典型做法是：EKS 節點放在私有子網（private subnets），入口使用 Load Balancer（通常會落在公網子網）。因此：

• 公網子網：供 ALB/NLB 等提供入口地址。
• 私網子網：節點、工作負載與內部資源。

私網子網的出網通常依賴 NAT Gateway。你需要評估成本與可用性：NAT Gateway 會收費，且其可用性依賴 AZ；因此通常為每個 AZ 配置一個 NAT Gateway，避免把所有出網流量集中在單一 AZ。

3.3 路由表與安全組的核心原則

AWS認證帳號開戶 路由表要對應你的「出入口」。如果你打算限制出網，可以在網路層做到部分控制，或在應用層/網路策略層做到更細粒度。安全組則要遵循最小暴露：worker 節點安全組只允許必要入站（例如從控制平面/入口到特定端口）、並允許必要出站（例如到鏡像倉庫、到監控端點）。

注意：安全組與 Kubernetes NetworkPolicy 是兩個層面的概念。安全組屬於 AWS 層，NetworkPolicy 屬於 Kubernetes 層。生產環境通常兩者都需要，但不要期待其中一個能完全取代另一個。

第四章：EKS 集群建立與節點池設計

建立 EKS 你要關注的不只是「創建成功」，還包含節點池的可用性、升級行為、擴縮規則、以及對不同工作負載的隔離。

4.1 節點池分離：System 與 Application

建議把節點池分為至少兩類：system 節點與 application 節點。

• system 節點：承載核心 add-ons、Ingress Controller、CSI、DNS、metrics-server 等。
• application 節點：承載業務工作負載。

這樣的好處是：你可以對 system 池設置更穩定的策略（較高 On-Demand 比例、較保守的擴縮），對 application 池則按成本目標與中斷容忍度調整（例如 Spot）。同時在故障時更容易定位：是核心組件失效還是業務節點容量不足。

4.2 節點類型：On-Demand、Spot 與混合策略

生產環境中大多數組件不能容忍頻繁中斷，所以 system 池通常使用 On-Demand。業務池可以採用混合策略：高可用服務用 On-Demand，非關鍵或可重試批處理用 Spot。

如果你使用 Spot，務必搭配中斷處理：為節點維持足夠的 Pod 分散度、為重要服務設置合理的 PodDisruptionBudget，並確保你的應用能處理終止信號與重啟。

4.3 自動擴縮：Cluster Autoscaler 與 Karpenter 的取捨

自動擴縮的目標是「成本與可用性兼顧」。Cluster Autoscaler（基於 ASG）與 Karpenter（基於更細粒度的調度）是兩條常見路線。

AWS認證帳號開戶 一般而言：

• 若團隊熟悉 ASG 和傳統擴縮，Cluster Autoscaler 上手快，配置相對直觀。
• 若你希望更精細的容量選擇、更快的擴縮和更優的成本效率，Karpenter 可能更適合。

無論選哪個，生產要考慮的不是「能不能擴」，而是「擴多久能滿足需求」、「擴縮是否造成資源抖動」、「節點類型是否與工作負載需求一致（CPU/Memory/架構/加速器等）」。

第五章：IAM、身份與密鑰管理——把權限做到剛剛好

在雲端運維裡，權限既是安全邊界也是故障源頭。權限太大是風險，權限太小則會導致服務啟不來、擴不出去或讀不到資料。

5.1 控制平面與工作負載的 IAM 職責分離

創建 EKS 需要角色授權其管理資源；同時你會讓工作負載透過特定身份訪問 AWS 服務（S3、SQS、RDS、ECR、KMS 等）。建議使用 IRSA（IAM Roles for Service Accounts），把權限綁定到 Kubernetes ServiceAccount，避免使用節點角色承載全部能力。

5.2 IRSA 與最小權限設計

以 EBS CSI 或 ALB Ingress Controller 為例，你可以分別建立對應的 IAM Role。對業務應用也要做到「按功能授權」，而不是一個 role 什麼都能做。

最小權限的做法通常包括：

• 限定資源範圍（ARN 到特定 bucket、特定 queue、特定 key）。
• 限定動作（只允許必要 API，例如 s3:PutObject、s3:GetObject，而不是通配）。
• 必要時加上條件（例如限制來源 VPC、限制請求使用的標記）。

此外，KMS 加密的使用要把「資料路徑」和「授權路徑」對齊：應用要能解密、但同時要避免把 KMS key 的權限過度擴張給不相關的服務。

5.3 憑證與祕密：Secrets、外部祕密與輪轉

Kubernetes Secret 能解決大部分場景，但你需要關注：

• Secret 的加密存儲（EKS 可配合密碼學或外部加密）。
• 誰能讀（RBAC）。
• 是否支援自動輪轉與審計。

生產環境一般會把敏感資訊放在更完善的祕密管理工具或採用自動輪轉方案，例如集成雲端祕密服務。若團隊採用外部祕密控制器，也要確保更新後工作負載能重新載入。

第六章：核心 Add-ons 與叢集功能補齊

一個可運營的 EKS，除了集群本體，還需要完整的 add-ons。你要思考的是：哪些是必需的，哪些能延後，哪些要強制上線到生產流程中。

6.1 存儲：EBS CSI 或 EFS CSI

對有持久化需求的工作負載，你通常會用 EBS（塊存儲）或 EFS（檔案存儲）。EBS 適合需要低延遲的卷，EFS 適合多節點共享檔案。使用 CSI Driver 使得存儲供給由 Kubernetes 來管理。

生產要留意：卷類型（gp3 等）、快照與備份策略、以及「卷的生命週期」與「刪除保護」的關係。很多事故不是存儲失效，而是誤刪導致不可恢復。

6.2 Ingress 與入口治理：ALB Ingress Controller

入口通常由 Ingress Controller 來統一管理。你可以選擇 ALB 方案，讓流量透過 AWS 的負載平衡。生產常見要求包括：

• TLS 終止與憑證管理。
• 路徑或主機名分流。
• WAF 與安全策略整合（視你的合規要求）。
• 日誌與追蹤：能追查請求的來源、狀態與延遲。

要特別注意 Ingress 對應的安全組與節點安全組/子網策略是否一致，避免出現「負載平衡器可達但 Pod 不可達」這種看似玄學的故障。

6.3 計算與節點層：CNI、CoreDNS、Metrics

VPC CNI 與 CoreDNS 是基礎底座。若配置不當，問題會表現在 Pod 解析失敗、跨網段不可達、或網路不穩定。metrics-server 或更完整的監控栈則要支撐 HPA/資源治理。

生產要確認：Kubernetes 事件與 metrics 是否正常產出；HPA 的行為是否符合你的負載模式；以及在節點擴縮時，是否會因 metrics 延遲導致擴縮節奏不穩。

第七章：工作負載部署策略與 Kubernetes 生產治理

集群搭好後，真正拉開差距的是工作負載治理。Kubernetes 對「運維自由度」很高，但沒有規則就會變成混亂：資源沒限制、版本不一致、命名空間不可控、權限不收斂。

7.1 命名空間與隔離邏輯

至少做到：環境隔離、系統隔離與業務隔離。命名空間不只是分類，也是一套 RBAC、配額與策略的落點。對生產而言，你需要確保：

• system 命名空間不可隨意修改。
• 業務命名空間有資源配額（requests/limits 的門檻或範圍）。
• 對敏感命名空間強化審計與限制出網。

7.2 資源 requests/limits：不要讓調度「猜」

調度依賴 requests，實際運行受 limits 約束。若 requests 設太小，調度會把太多 Pod 放進節點導致 OOM 或延遲升高；若 limits 設太大，可能造成成本膨脹或應用互相干擾。

生產推薦做法是：先用基線數據（測試/預發）設定合理的 requests，limits 用於保護與上限控制。並且配合 HPA/自動伸縮的指標選擇（CPU、記憶體或自定義指標）避免「擴了但沒有用」的擴縮。

7.3 探針、優雅終止與 PodDisruptionBudget

探針（readiness/liveness/startup）是避免流量打到尚未就緒服務的核心。優雅終止（terminationGracePeriodSeconds、preStop、SIG 处理）則關乎更新時是否會出現瞬斷。

當你做滾動更新、節點縮容或 Spot 中斷時，PodDisruptionBudget（PDB）能限制同時被中斷的副本數。生產通常會針對核心服務設定 PDB，並對非核心服務允許更高的中斷比例。

7.4 版本交付：滾動更新、回滾與鏡像策略

交付策略不要只看「能不能發佈」，還要確保「出了問題能回滾」。建議在 CI/CD 中做到：

• 鏡像使用不可變標籤（以 digest 或版本號）。
• 部署用於 staging 驗證，再推進 production。
• 設置合理的最大超時和健康檢查，以便自動回滾。

如果採用金絲雀（Canary）或藍綠（Blue/Green），也要考慮入口與回路策略，避免過度複雜導致排查困難。

第八章：可觀測性與運維閉環（監控、日誌、告警）

很多團隊在部署前不會把監控當成「必需品」，結果是事故發生時只有人猜。生產環境要建立運維閉環：能看見、能定位、能告警、能復盤。

8.1 指標監控：集群層與應用層

集群層指標包括：節點 CPU/記憶體使用率、Pod 重啟次數、節點狀態、HPA 行為、Ingress 請求延遲、錯誤率等。應用層指標則依賴你在應用中暴露的 metrics（例如延遲、吞吐、錯誤碼比例、隊列積壓、業務指標）。

告警策略要避免噪音。噪音會讓團隊的值班注意力下降。建議遵循：告警要能指向具體行動；同一類故障用相同維度聚合；必要時做告警抑制或合併。

8.2 日誌與追蹤：從「發生」到「找到原因」

AWS認證帳號開戶 日誌要能支撐：請求路徑、錯誤堆棧、外部依賴（資料庫、第三方服務）的錯誤回傳。對分散式架構，建議接入追蹤（分散式追蹤）以還原請求鏈路。

生產排查最怕的是：你看到告警，但日誌不完整或沒有關聯 ID。設計時要把 trace/span 或 request id 一致地傳遞到下游服務。

8.3 事件與審計：Kubernetes 事件不可忽視

Kubernetes 事件（events）能反映調度失敗、鏡像拉取失敗、探針失敗等。將 events 與告警和日誌一起納入監控，你會更快定位根因。

此外，資安合規通常需要審計（誰在什麼時間做了什麼）。保留操作日誌與配置變更紀錄是對未來排查極其重要的投入。

第九章：高可用、備援與災備：不是只有「多 AZ」

多 AZ 是基礎，但生產災備通常還要處理：資料備份、控制面可靠性、入口層容錯與手動恢復流程。

9.1 存儲備份策略

資料備份要做到兩件事：定期備份與可測試恢復。備份不是存了就算，至少要定期做還原演練。對有依賴外部資料庫的系統，災備計畫要涵蓋資料層，而不是只停留在 EKS。

9.2 應用容錯與狀態治理

若應用是無狀態的，重啟與擴縮相對容易；若應用持有狀態，則需要明確策略：狀態是否在外部系統、是否支持多副本一致性、是否需要特定部署順序。

對消息隊列/流處理類服務，還要考慮：在節點故障或中斷後，如何重放、如何避免重複處理造成業務問題。

9.3 叢集層的恢復：IaC 與配置可重建

生產災備真正的核心是「能否重建」。因此建議使用基礎設施即程式碼（IaC）管理 VPC、節點池、IAM、網路與核心 add-ons 的配置。這樣在災難恢復時，你可以用版本化的配置快速拉起環境，而不是靠人工記憶。

第十章：成本控制與日常治理

成本通常不是一次爆發，而是長期累積。EKS 的成本由多因素構成：節點與存儲、負載均衡器、資料傳輸、NAT Gateway、以及監控與日誌保留策略。

10.1 節點與擴縮的成本觀

避免「一直大而全」是第一要務。合理設置 requests/limits、HPA 指標與最低副本數，能在不影響 SLA 的前提下降低浪費。

若有批處理或可伸縮的服務，可以把 Spot 作為主要容量來源之一，但要確保重試與中斷處理到位。

10.2 入口與網路成本：NAT、LB 與出網策略

NAT Gateway 會帶來穩定費用與流量費，出網控制有助於降低不必要的流量。例如讓鏡像拉取走私有加速或在允許情況下使用 VPC 端點降低出網成本。

另外，負載均衡器的配置要避免不必要的高階功能或過寬的冗餘。監控 LB 的請求量與錯誤率，有助於調整擴縮與路由規則。

10.3 日誌與指標留存：別讓「全量存」成為習慣

日誌與追蹤的留存策略要以「能解決問題」為導向，而不是「先全存」。你可以根據故障頻率、合規要求與排查需要設定不同的留存期限。對於高噪音服務，應做抽樣或降低 verbosity。

第十一章：常見坑與處理思路

生產環境最怕的是「看似正常，實則埋雷」。下面列一些常見坑，並給出處理思路。

11.1 網段重疊導致跨網不可用

AWS認證帳號開戶 Pod CIDR 與 VPC CIDR 或內部網段重疊時，路由會產生衝突。處理方式不是補救，而是從地址規劃階段直接避免。若已部署導致重疊，改造成本很高，因此一定要在設計階段做排除檢查。

AWS認證帳號開戶 11.2 IAM 權限過寬或過窄

過寬會帶來資安風險；過窄則讓服務偶發失敗。建議做兩步：一是先以功能清單列出需要的 API；二是用最小化的資源 ARN 范圍授權，必要時逐步擴充並記錄原因。

11.3 缺乏 probes 與 PDB 導致更新時抖動

沒有 readiness/liveness 會造成流量進入未就緒 Pod；沒有 PDB 或不合理的 PDB 會在節點維護、縮容或更新時把副本全擠在同一時間中斷。這類問題通常在壓力測試或首次滾動更新時暴露，所以要提前用預發環境演練。

11.4 監控不足導致事故定位時間過長

沒有關聯 ID、沒有錯誤碼統計、沒有延遲分位數，很難快速定位瓶頸。建議至少具備：應用錯誤率、延遲 P95/P99、依賴服務錯誤統計、以及 Pod 重啟與資源耗盡的關聯。

第十二章：把流程做成可複製的交付模板

最後，EKS 的價值在於可複製。生產環境如果只靠一次性手工操作，後續擴環境或新增團隊時會非常痛苦。你應把以下內容沉澱成模板或標準：

• VPC 與子網、路由表、NAT 配置的可重用模組。
• 節點池的標準：system/on-demand、application/spot 或混合，並帶上擴縮與中斷策略。
• IRSA 與 IAM role 的授權模板：按常見服務（S3、SQS、RDS、KMS）建立基礎權限集合。
• AWS認證帳號開戶 核心 add-ons 的版本與啟用清單。
• Ingress 與 TLS 的標準：證書來源、憑證更新策略、WAF 接入方式。
• 可觀測性標準：指標、日誌、告警與儀表盤命名規範。
• 交付標準：滾動更新策略、探針與 PDB、回滾流程。

AWS認證帳號開戶 當你把這套標準做成可重建的配置，你的團隊才真正擁有「平台能力」。人員變動不再是風險，環境擴張不再是地獄，升級也能更從容。

結語：從搭建到運營，EKS 真正考驗的是工程化能力

AWS 上搭建 EKS 相對容易，困難在於把它變成生產可用的系統：網路要穩、權限要準、擴縮要合理、可觀測性要能回答「為什麼」而不只是「發生了什麼」。當你在設計階段把安全、治理、可用性與成本一起納入考量，後續的交付、故障排查與升級都會順很多。

如果你只記住一句話：把集群當作平台，而不是一次性部署。平台化的核心，就是讓每次改動都可預期、每次事故都能定位、每次擴張都可複製。