Chapter 11. Jobs
Jobs 的用途
Job 物件用於管理和執行短期、一時性的任務，通常是需要確保完成後終止的工作。它負責創建和管理根據作業規範定義的 Pod，並協調並行執行多個 Pod。Job 可以自動處理 Pod 失敗的情況，確保任務成功完成。
四種工作模式
- One Shot (一次性作業)：
- 執行單一 Pod 直至成功終止。
- Job 會監控 Pod 是否成功終止；若失敗，會重啟 Pod 直到成功。
- 避免崩潰循環，Pod 重啟前會等待一段時間。
- Parallelism (平行作業)：
- 複雜任務可被拆分成多個較小的子任務並平行處理，例如生成密鑰。
- Work Queues (工作佇列)：
- 任務可能會生成多個工作項目並推送到佇列，然後通過多個 Pod 來處理這些項目，直到佇列為空。
- Cron-Job (排程作業)：
- 這是一種定期執行的 Job，會按照指定的時間間隔進行觸發。
本章總結
Job 是一個 Kubernetes 物件，專為短期的一次性任務設計。它有多種執行模式，支持平行運行和工作佇列等功能，並能夠處理 Pod 失敗的情況。Cron-Job 則提供了定期執行的能力，適用於需要在特定時間間隔執行的任務。
Chapter 12. Integrating Storage Solutions and Kubernetes
儘管無狀態的微服務架構通常更可靠且易於管理，但大多數複雜系統仍需要儲存狀態，例如資料庫、索引分片等。將這些儲存解決方案與容器化環境和 Kubernetes 整合，是構建分散式系統中最具挑戰性的部分之一。這涉及到將儲存解決方案與容器化架構解耦，並確保儲存的可靠性和可擴展性。
導入外部服務 (Importing External Services)
Kubernetes 可將外部服務（如傳統資料庫）作為 Kubernetes 服務來管理。這允許應用程序在不同環境中（如測試和生產）使用相同的配置，實現高保真度的測試和部署。然而，使用外部服務的缺點是無法直接進行健康檢查（Health Checking），這會影響監控和可靠性。
運行可靠的單例 (Running Reliable Singletons)
儘管 Kubernetes 的 ReplicaSet 旨在管理多個可替換的 Pod，但對於大多數儲存解決方案，通常需要保持單一實例。解決這一挑戰的一種方式是運行只有一個 Pod 的儲存解決方案。這樣可以避免管理複製儲存的問題，並在正確設計系統的情況下，提供與單一虛擬或實體機器類似的可靠性。
StatefulSets
與無狀態應用不同，StatefulSet 用於管理有狀態的應用。其主要特點包括：
- 每個副本都有唯一的持久主機名稱（例如，database-0、database-1）。
- Pod 會按順序創建，且創建過程會等待前一個 Pod 健康運行。
- 刪除 StatefulSet 時，Pod 也會按逆序刪除。
這使得 StatefulSet 特別適用於有狀態應用的管理，例如資料庫。
初始化容器 (Initialization Container)
初始化容器在 Pod 啟動時運行，並且在主容器啟動前完成初始化任務。它們通常用於在主應用容器之前執行一些配置工作。所有初始化容器都會按順序執行，且主應用容器會等待所有初始化容器完成後才會啟動。
在 Pod 定義中，有一個單獨的 initContainerslist，可以在其中定義初始化容器。
本章總結
透過結合 StatefulSets、持久卷請求 (persistent volume claims) 和存活探針 (liveness probing)，我們可以在 Kubernetes 上運行穩定且可擴展的雲端原生儲存解決方案，確保有狀態應用的高可用性和可靠性。
Chapter 13. Accessing Kubernetes from Common Programming Languages
Kubernetes API
Kubernetes API 伺服器其實是個 HTTP(S) 伺服器，提供了一些 Kubernetes 特定功能。它的主要任務是協調各種操作，例如從「kubeconfig」檔案或 Pod 環境中載入授權資訊。Kubernetes API 提供了大量的資源和操作，分為不同的 API 群組，每個群組下都有不同的資源類型和操作方法。
雖然大部分功能都是伺服器端實現，但客戶端仍保有關鍵功能。如果你在客戶端庫中找不到所需功能，可以使用 kubectl 命令並加上 --v=10 標誌，這樣可以顯示詳細的 HTTP 請求和回應日誌，幫助你理解 Kubernetes 的運作。
與 Kubernetes API 伺服器互動
要與 Kubernetes API 互動，首先需要下載適合的語言庫（例如 Python、Java、C# 等），可以幫助你更輕鬆地與 Kubernetes 伺服器進行通信。
- 身分驗證：你可以從「kubeconfig」檔案或者 Kubernetes 叢集中的 Pod 環境來取得必要的認證資訊。
- 取得 Kubernetes API：透過 Kubernetes API，你可以執行各種操作，如建立、列出和刪除資源。
- 監視 Kubernetes API：監視是 Kubernetes 中的一個重要功能，讓你能夠即時了解資源的變更。使用「監視」調用時，你可以註冊對特定資源的興趣，並且 Kubernetes API 伺服器會在資源變動時推送通知，避免不必要的輪詢。這些通知會通過開放的 TCP 連接發送，直到監視結束。
Chapter 14. Securing Pods
深度防禦（Defense in Depth）
深度防禦是一種多層安全策略，在 Kubernetes 等運算系統中，這意味著需要實現多層次的安全防護，以確保系統的整體安全性。這樣的多層安全控制可以幫助減少單一防線失效時所造成的風險。
最小權限原則（The Principle of Least Privilege）
最小權限原則強調只允許工作負載存取其運作所必須的資源。這樣可以減少工作負載在遭遇安全漏洞時的危害範圍。
Pod 安全設定
以下介紹在 YAML 檔案中可以設定的關鍵安全選項：
- SecurityContext：
- SecurityContext 是確保 Pod 安全的核心設定，可以設置使用者權限和存取控制。例如，您可以設定 Pod 的使用者 ID 和群組 ID，將檔案系統設置為唯讀，或限制是否允許權限升級等。這樣有助於減少攻擊者提升權限的風險。
- Pod Security Admission：
- 這項功能可以確保 Pod 的安全設置得以正確匯入。它允許您聲明不同的安全設定檔，稱為「Pod 安全標準」，並在命名空間層級套用。這些標準有三種不同的設定，詳細內容可以參考官方文檔：Pod Security Standards。
- Service Account Management：
- Service Account 提供了身份識別機制，並預設允許直接存取 Kubernetes API。為了確保安全，應該遵循最小權限原則，停用不必要的存取權限。若未正確管理這些權限，攻擊者可能藉此存取 Kubernetes 叢集，造成安全風險。
- RuntimeClass：
- RuntimeClass 是用來增強工作負載安全性的一項功能。它允許用戶選擇不同的容器執行時間（如 gVisor 或 Kata Containers），這些容器執行時間可能具有不同的安全隔離級別。這可以幫助提高工作負載的整體安全性，尤其在需要強隔離的環境中。
- Network Policy：
- 利用 Network Policy，可以為工作負載創建入出口的網路策略。這些策略可以根據 Pod 標籤來選擇特定的 Pod 並定義它們如何與其他 Pod 或服務端點進行通信。這樣有助於限制工作負載之間的通信範圍，提高網絡層級的安全性。
- Service Mesh：
- Service Mesh 是一種將安全性提升到工作負載層級的技術。它可以利用雙向 TLS（傳輸層安全）來加密流量，保護工作負載之間的通信。透過加密通訊，Service Mesh 增強了工作負載之間的安全性。
此章總結
在 Kubernetes 環境中實現安全性是多層次的，從設置適當的權限、網路策略，到選擇安全的執行環境，都能加強工作負載的安全性。透過使用這些工具和最佳實踐，可以確保 Kubernetes 叢集中的應用程式不僅能高效運行，還能有效地防範潛在的安全威脅。
Chapter 15. Policy and Governance for Kubernetes Clusters
在 Kubernetes 中，有些常見的容器策略是為了確保安全性、資源配置和一致性，例如：
- 所有容器必須僅來自特定的容器註冊表。
- 所有 Pod 必須標註部門名稱和聯絡資訊。
- 所有 Pod 必須設定 CPU 和記憶體資源限制。
- 所有 Ingress 主機名稱必須在叢集中唯一。
- 某些服務不得在網路上提供。
- 容器不得偵聽特權連接埠。
這些策略確保了 Kubernetes 叢集的安全性、可管理性和符合規範的運行。
Admission Flow
當 API 請求流經 Kubernetes API 伺服器時，准入控制器會在資源被保存至儲存體之前對其進行變異或驗證。根據需求，准入控制器可以修改資源或僅進行驗證。
- Mutating Admission Controller：可以改變請求中的資源配置（如調整容器的資源限制或修改容器鏡像）。
- Validating Admission Controller：僅用來驗證資源配置是否符合預設的策略。
此外，Kubernetes 也支持動態配置的 Admission Webhooks，允許叢集管理員為 API 伺服器設定端點來傳送評估請求。Webhook 會根據策略回應「admit」或「deny」，決定是否儲存資源。
Policy and Governance with Gatekeeper
Gatekeeper 是 Kubernetes 原生的策略控制器，基於開放策略代理（Open Policy Agent，OPA）構建，旨在根據策略評估資源並決定是否允許建立或修改 Kubernetes 資源。Gatekeeper 允許您在伺服器端實現策略評估，這意味著無需修改開發工具、工作流程或持續交付管道，您就可以在現有 Kubernetes 叢集上安裝並使用 Gatekeeper。
Gatekeeper 的主要功能是利用 OPA 引擎進行策略評估。這些策略可以是基於多種規範的（例如資源限制、安全性標準、標籤規範等），並且可進行跨應用程式移植。此外，Gatekeeper 也支持策略測試和在持續整合（CI）管道中實施策略測試，這樣可以確保部署前的合規性。
開放策略代理（OPA） 是一個高度擴展且雲原生的開源策略引擎，它可以協助評估和執行策略，並回應是否同意或拒絕某個操作。它使您能夠編寫自定義策略並應用於 Kubernetes 資源的管理中。
此章總結
這一章介紹了如何使用 Gatekeeper，這個基於開放策略代理（OPA）構建的 Kubernetes 原生策略控制器，來滿足 Kubernetes 叢集中的策略和治理需求。Gatekeeper 通過在伺服器端進行策略評估，使得管理員可以對所有進入 Kubernetes 的 API 請求進行控制，確保叢集符合安全性、資源配置和運維標準。
Chapter 16. Multi-cluster Application Deployments
實際需求
多集群部署常見需求包括：
- 冗餘和彈性：部署在單一資料中心的應用程式容易受限於單一故障域，可能因故障或部署問題導致應用程式完全停擺。因此，多集群部署有助於提高冗餘性和彈性。
- 區域親和力：一些應用程式（如遊戲伺服器）需要靠近用戶，減少延遲，或受到法律和監管要求的限制，要求資料存儲在特定區域。
- 隔離：多集群可以實現團隊和產品間的隔離，有助於減少不同團隊間互相影響的風險。即使這增加了管理上的複雜性，某些情況下還是值得選擇。
開始前的準備
確保在多集群部署中，基礎設施的一致性和自動化至關重要。這包括：
- 部署應用程式的自動化
- 集群管理的自動化
- 叢集間的一致性（如監控、日誌和安全工具的自動部署）
- 網域及負載平衡
此外，還要確保所有集群具有一致的存取控制，例如與全域身份提供者（如 Azure Active Directory）進行整合。
挑戰：狀態複製
在理想情況下，應用程式是無狀態的，或者所有狀態都是只讀的。在這樣的情況下，多集群部署簡單且容易。然而，大多數應用程式都有狀態，需要跨集群一致管理這些狀態。例如：
- 客戶訂單：如果將客戶訂單存儲在不同集群，則客戶可能會在不同區域之間移動時無法看到自己的訂單，造成不好的使用者體驗。
- 一致性模型：
- 強一致性：寫入在複製前不會成功。
- 最終一致性：寫入成功後，資料會在稍後的某個時間點複製一致。這種模型在效率上較為高效，但可能會導致資料延遲更新。
選擇一致性模型對於多集群架構至關重要，因為它直接影響資料的複製方式和用戶體驗。強一致性提供了簡單可靠的資料處理，但需要更多資源以保證資料的一致性；而最終一致性提供更高效的處理，但可能會引發過時資料的問題，並使開發者需要處理更多複雜的邊緣情況。
複製孤島策略
最簡單的跨區域多集群部署方法是將應用程式副本部署到每個區域。每個集群的副本是精確的克隆，所有區域的應用程式看起來完全相同。這樣設計使得資料在每個區域本地存儲，避免了複雜的跨區域資料同步問題，並確保了區域的冗餘性。
然而，這樣的策略存在資源浪費的風險。假設應用程式的每個副本都需要為最大負載配置資源，那麼在人口較少的地區可能會造成資源過度配置。因此，需要仔細調整應用程式大小，以避免低效的資源利用。
切片策略（Sharding）
當應用程式擴展並且需要處理大量資料時，複製所有資料到每個區域會變得非常昂貴且低效。這時，資料分片（Sharding）成為更具成本效益的選擇。資料分片是將資料分割並在不同的區域存儲，每個區域的集群只負責一部分資料。
這樣做可以減少跨區域複製的成本，但需要額外的資料路由層來確保請求能夠正確地到達資料所在的區域。建議將資料路由實作為單獨的微服務來處理，這樣可以簡化應用程式中的其他服務，避免將資料路由邏輯散布於多個服務中。
微服務路由
隨著應用程式規模的增長，微服務架構在多集群部署中顯得尤為重要。對於大型應用程式，將每個微服務視為獨立的服務，並使用全域負載平衡器和資料複製服務來進行管理，可以顯著提高彈性與擴展性。
這樣的設計能夠讓不同團隊在不干擾其他團隊的情況下，獨立部署和擴展其服務。微服務架構在多集群環境中提供了靈活性，並能更好地應對各種地理區域和業務需求。
此章總結
多集群應用程式部署的挑戰包括資料一致性、負載平衡、區域隔離等問題。根據應用程式的需求，您可以選擇不同的架構和策略，如複製孤島、資料分片等，來實現多集群部署的冗餘、彈性和可擴展性。在這過程中，微服務架構和自動化部署工具將有助於簡化管理，並提供更高的靈活性。
選擇合適的一致性模型和架構設計是成功實施多集群部署的關鍵，應根據應用程式的特性和業務需求進行調整。
