系列總結與後續學習方向

經過前面 29 天的學習，我們從 Kubernetes 的基本概念開始，逐步認識 Kubernetes 的架構、各種資源的用途，以及如何透過 YAML 部署與管理應用程式。

在最後三篇中，也透過一個簡單的 Web API 專案，將 Deployment、Service、ConfigMap、Secret、PVC、Ingress 和 Probe 等資源整合起來，實際觀察 Kubernetes 如何管理應用程式。

這篇作為整個系列的最後一篇，將回顧前面學過的內容，並整理未來可以繼續深入學習的方向。

回顧 Kubernetes 基礎架構

在系列最初，我們先認識 Kubernetes 的基本架構。

Kubernetes 主要由 Control Plane 和 Worker Node 組成。

Control Plane 負責管理整個 Cluster，例如接收 API 請求、安排 Pod 的執行位置，以及維護叢集的預期狀態。

Worker Node 則負責執行實際的應用程式容器。

在這個架構中，我們認識了幾個重要組件：

• kube-apiserver：提供 Kubernetes API，作為操作叢集的主要入口。
• etcd：保存 Kubernetes 的叢集狀態資料。
• kube-scheduler：負責替尚未排程的 Pod 選擇適合的 Node。
• kube-controller-manager：執行各種控制器，持續協調資源狀態。
• kubelet：在 Node 上管理 Pod 與容器的執行。
• kube-proxy：在使用 kube-proxy 的網路架構中，協助實現 Service 的網路轉送。

這些組件互相配合，讓 Kubernetes 能夠持續管理 Cluster 中的應用程式。

工作負載管理

接著，我們認識 Kubernetes 如何管理不同類型的工作負載。

其中最常使用的是 Deployment。

Deployment 可以管理 Pod 的副本數量，並提供滾動更新及回滾等功能。

除此之外，還介紹了其他 Workload：

透過這些資源，可以依照不同應用程式的需求，選擇適合的部署方式。

設定管理與資料持久化

在設定管理方面，我們學習了 ConfigMap 和 Secret。

ConfigMap 適合保存一般應用程式設定，例如環境變數或設定檔。

Secret 則用來保存密碼、Token 等敏感設定。不過，Secret 並不代表資料預設就受到完整的加密保護，實際使用時仍需要考慮存取權限與靜態資料加密。

在資料儲存方面，我們認識了：

• Volume：提供 Pod 中容器使用的儲存空間。
• PersistentVolume（PV）：代表 Kubernetes 中的持久化儲存資源。
• PersistentVolumeClaim（PVC）：讓應用程式提出儲存空間需求。

在 DAY28 的綜合實作中，也透過 PVC 保存 Web API 的資料，避免資料只存在容器的可寫入層中。

網路與服務存取

Kubernetes 中的 Pod 可能因為重新建立而改變 IP 位址，因此通常不會直接依賴特定 Pod IP 提供服務。

為了解決這個問題，我們介紹了 Service。

Service 可以提供穩定的存取入口，並將流量導向符合條件的後端 Pod。

接著也認識了 Ingress，透過 HTTP 路由規則將外部請求導向指定的 Service。

除此之外，NetworkPolicy 可以用來限制 Pod 之間允許的網路流量，但需要使用支援 NetworkPolicy 的網路插件，規則才會實際生效。

透過這些資源，可以逐步建立 Kubernetes 應用程式的網路架構。

資源管理與安全性

在資源管理方面，我們介紹了 requests 和 limits。

requests 用來表示容器所需要的資源，並作為 Kubernetes 排程時的重要依據。

limits 則用來限制容器可以使用的資源上限。

另外也介紹了：

• HPA：根據資源使用量或其他指標，自動調整工作負載的副本數。
• ResourceQuota：限制 Namespace 的資源使用總量。
• LimitRange：管理 Namespace 中個別資源的限制與預設值。
• SecurityContext：設定 Pod 或容器的安全相關參數。
• Taints 與 Tolerations：影響 Pod 能否排程到特定 Node。

這些功能可以協助管理叢集資源，並降低不適當設定所造成的影響。

Kubernetes 維運與故障排查

除了建立 Kubernetes 資源，如何確認應用程式是否正常運作也是重要的一部分。

在前面的文章中，我們使用過許多 kubectl 指令，例如：

kubectl get pods
kubectl describe pod <pod-name>
kubectl logs <pod-name>
kubectl get events
kubectl top pods

這些指令可以協助我們觀察 Pod 狀態、資源使用量及應用程式日誌。

在 DAY29 中，也透過 Liveness Probe 和 Readiness Probe，讓 Kubernetes 能夠判斷容器是否需要重新啟動，以及 Pod 是否準備好接收流量。

透過這些工具，可以逐步找出應用程式無法正常運作的原因。

綜合實作回顧

在 DAY27～DAY29 中，我們建立了一個簡單的 Web API，並逐步加入 Kubernetes 的各項功能。

整個實作大致分成三個階段：

DAY27：應用程式部署

使用 Deployment 管理 Web API，透過 Service 提供存取入口，並使用 ConfigMap 和 Secret 管理設定。

DAY28：資料持久化與外部存取

加入 PVC 保存資料，並透過 Ingress 提供 HTTP 存取入口。

DAY29：健康檢查與故障排查

加入 Probe 和資源限制，並透過模擬故障觀察 Kubernetes 的處理方式。

這個專案雖然簡單，但已經包含 Kubernetes 應用程式部署時常見的多種資源。

也讓我們能夠從實際操作中，理解不同資源之間的關係。

後續學習方向

完成這 30 天的基礎學習後，還有許多技術可以繼續深入研究。

Prometheus 與 Grafana

在前面的文章中，我們使用 Metrics Server 和 kubectl top 觀察資源使用量。

不過，這些工具主要提供基本的即時資源指標，並不適合用來進行完整的歷史資料分析。

未來可以進一步學習 Prometheus 和 Grafana。

Prometheus 可以收集與保存監控指標，Grafana 則可以將資料呈現成圖表及儀表板，方便觀察應用程式的運作狀況。

CI/CD 與 GitOps

目前的實作主要透過手動執行 kubectl 或 Helm 指令部署應用程式。

但在實際開發環境中，可能需要頻繁更新程式碼與部署新版本。

因此可以繼續研究 CI/CD，將程式碼測試、建置映像檔及部署流程自動化。

另外，也可以研究 GitOps，例如使用 Argo CD，透過 Git Repository 管理 Kubernetes 的預期部署狀態。

RBAC 與 Kubernetes 安全性

在實際的 Kubernetes Cluster 中，不一定所有使用者都應該擁有相同的操作權限。

RBAC（Role-Based Access Control）可以依照使用者或服務帳號的需求，限制其能夠操作的 Kubernetes 資源。

未來也可以繼續研究：

• ServiceAccount 與權限管理。
• Secret 的安全管理。
• 容器映像檔安全性。
• Pod Security Standards。
• Kubernetes API 的存取控制。

多節點與高可用性

本系列主要透過 Minikube 建立學習環境。

未來可以進一步研究多節點 Cluster 的管理，例如：

• Node 發生故障時的處理方式。
• Pod 在不同 Node 之間的排程。
• 多副本應用程式的可用性。
• Control Plane 的高可用性架構。
• Kubernetes Cluster 的備份與還原。

這些都是從本地測試環境進一步走向正式環境時，值得研究的主題。

結語

從第一天認識 Kubernetes，到最後透過綜合實作部署一個 Web API，這 30 天介紹了 Kubernetes 的基本架構、常見資源及實際操作方式。

在學習過程中，也遇到了許多設定與部署上的問題，例如 Pod 無法啟動、Service 無法連線，或 YAML 設定錯誤等。

但透過這些問題，也能夠更加理解 Kubernetes 的運作方式。

Kubernetes 涵蓋的技術非常廣泛，30 天的內容不可能介紹所有功能，也無法僅靠這些實作就掌握正式環境中的所有問題。

不過，透過這次的介紹與實作，已經能夠對 Kubernetes 建立基本認識，並了解如何使用常見資源部署及管理容器化應用程式。

未來無論是繼續研究監控、自動化部署、資訊安全，或是更複雜的 Cluster 架構，都可以從這些基礎觀念繼續延伸。

到這裡就終於結束了。