Chapter 6. Service Discovery
服務發現解決了如何查找哪些程序正在監聽哪些服務地址的問題。
一個好的服務發現系統應具備以下三個特點：
- 快速可靠的解析：能夠迅速地解析服務資訊。
- 低延遲：當服務資訊變更時，客戶端應能立即更新。
- 豐富的服務定義：能夠儲存關於服務的詳細資訊，例如多個連接埠與服務的關聯。
由於 Kubernetes 叢集的 IP 地址是虛擬的，因此需要在命名空間內使用服務名稱來穩定地連接到服務所指向的 Pod。
NodePorts
NodePort 是一種進一步增強服務的功能。除了叢集 IP 外，系統還會選擇一個連接埠（或由使用者指定），並將該端口的流量轉發到服務。在叢集中的每個節點都會將流量轉發到這個端口，從而使您能夠通過任何叢集節點來訪問服務。
使用 NodePort 時，您不需要知道服務的 Pod 具體運行在哪個節點上，這使得服務發現更加簡單。NodePort 可以與硬體或軟體負載平衡器集成，進一步公開服務。
負載平衡器
若叢集與外部負載平衡器集成，則可以使用 LoadBalancer 類型。這會建立在 NodePort 類型的基礎上，並通過額外的雲端配置來創建新的負載平衡器，然後將流量導向叢集中的節點。
大多數基於雲端的 Kubernetes 叢集都提供負載平衡器集成，並且有一些專案為常見的物理負載平衡器提供集成解決方案，不過這些可能需要更多手動配置。
若要使用內部負載平衡器，則需要參考相關雲端服務的文檔，根據雲端提供商的不同設置來配置負載平衡器。
Chapter 7. HTTP Load Balancing with Ingress
如何管理應用程式進出的網路流量？
在非 Kubernetes 環境中，通常會使用「虛擬託管」，這是一種在單一 IP 位址上託管多個 HTTP 網站的機制，通常會透過負載平衡器或反向代理來接受來自 HTTP（80）和 HTTPS（443）端口的連接。
在 Kubernetes 中，負載平衡系統稱為 Ingress，它是 Kubernetes 原生的解決方案，用於實現類似「虛擬託管」的功能。
Ingress 的複雜性之一在於需要用戶管理負載平衡器的配置。透過 (a) 標準化此配置，(b) 將其作為 Kubernetes 對象來管理，以及 (c) 將多個 Ingress 物件整合到單一負載平衡器配置中，可以簡化這一過程。
用戶可以像管理其他 Kubernetes 物件一樣創建和修改 Ingress 物件。然而，預設情況下，並不會自動運行與這些物件相關的程式碼；用戶需要安裝和管理外部的 Ingress 控制器，使其具有可插拔性。
Contour(開源的 Ingress 控制器)
出於安全考量，Ingress 物件只能引用同一命名空間中的上游服務。這意味著無法使用 Ingress 將某個子路徑指向其他命名空間的服務。
然而，來自不同命名空間的多個 Ingress 物件可以為同一主機指定不同的子路徑，並將它們合併為一個最終的 Ingress 控制器配置。
這種跨命名空間的協作要求 Ingress 必須在整個集群中進行全局協調。如果協調不當，一個命名空間中的 Ingress 物件可能會影響其他命名空間的運行。
此章總結
Ingress 是 Kubernetes 中的獨特系統，作為一種模式，必須安裝和管理對應的控制器來實現其功能。儘管如此，Ingress 仍是一個非常實用且高效的解決方案，能夠以經濟的方式提供服務。
隨著 Kubernetes 的發展，Ingress 的重要性將愈發突顯。
Chapter 8. ReplicaSets
同時運行多個副本的原因包括：容忍故障、提高請求處理能力和分片並行處理。
您可以使用 kubectl apply -f kuard-rs.yaml 指令來創建 ReplicaSet。ReplicaSet 是一個叢集範圍的 Pod 管理器，確保始終維持正確類型和數量的 Pod 執行。
協調循環 (Reconciliation Loop)
- Desired state(期望狀態)：所需的副本數量以及要複製的 Pod 定義。
- Current state(當前狀態)：系統當前觀察到的狀態。
協調循環方法本質上是一個目標驅動、自我修復的系統，通常可以通過幾行程式碼來實現。
ReplicaSets 與解耦
解耦是 Kubernetes 的關鍵特性，而Kubernetes 的所有核心概念都是模組化的，因此 ReplicaSet 和 Pod 之間是鬆耦合的關係：ReplicaSet 並不擁有其創建的 Pod，而是通過標籤查詢來識別應該管理的 Pod 集。
鬆耦合的優點：
- 可以擴展現有 Pod，並增加其他副本來應對需求變化。
- 容器隔離：可以修改生病 Pod 的標籤，解除其與 ReplicaSet 的關聯，進行偵錯。雖然 ReplicaSet 會注意到 Pod 遺失並創建新的副本，但開發者仍可與運行中的 Pod 進行互動式偵錯，這比僅依賴日誌更為有效。
此章總結
ReplicaSet 使得 Pod 的組合運行成為可能，並為構建具有自動故障轉移功能的應用程式奠定了基礎。它不僅能夠支持可擴展的部署模式，還能讓應用程式的部署變得更加簡便。
Chapter 9. Deployments
Deployment 物件用於管理應用程式的新版本發布，讓使用者可以輕鬆地從一個版本遷移到下一個版本。這個過程是明確且謹慎的，並且使用運行狀況檢查來確保新版本運行正常。如果新版本有過多故障，部署會停止。
部署的具體機制由部署控制器控制，這使得部署過程可以無人值守地運行，並且依然保持正確和安全。
ReplicaSet 管理 Pod，而 Deployments 管理 ReplicaSet。這種關係通過標籤和標籤選擇器來定義。使用 kubectl rollout 指令，可以查看歷史紀錄並進行回溯等操作。
部屬策略一：Recreate Strategy
這是較簡單的策略，會更新所管理的副本集以使用新映像，並終止與 Deployment 關聯的所有 Pod。ReplicaSet 會檢測到副本數為零，並使用新映像重新建立 Pod。雖然此策略快速且簡單，但會導致工作負載停機。
部屬策略二：Rolling Update Strategy
RollingUpdate 是更常見且推薦的策略，雖然較慢，但更為複雜且強大。它允許在服務持續接收用戶流量的同時，逐步更新 Pod，直到所有 Pod 運行新版本的應用程式，從而避免停機。
maxUnavailable：設定在滾動更新期間不可用的 Pod 的最大數量，也就是滾動更新進行的速度。可以是絕對數量或百分比，通常推薦使用百分比。例如，將maxUnavailable設定為 25%，每次更新 25% 的 Pod，確保服務在更新過程中有至少 75% 的可用性。maxSurge：設定可以創建的額外副本數量。以 10 個副本為例，將maxUnavailable設為 0，maxSurge設為 20%，意味著初期會將新副本集擴展至 12 個副本，並逐步縮減舊副本集。minReadySeconds：設定新 Pod 在進入服務前的等待時間，以確保其運行正常後才繼續更新下一個 Pod。progressDeadlineSeconds：設定進度截止時間，若某一階段超過此時間未達預期進度，則標記為失敗並停止部署。
此章總結
歸根結底，Kubernetes 的目標是讓應用程式的建置和部署變得更加簡單，尤其是針對定期更新服務版本的管理，提供了一種可靠且無縫的方式來處理不同版本的部署。
Chapter 10. DaemonSets
DaemonSets 的用途
DaemonSet 用於確保在 Kubernetes 叢集中的每個節點上執行一組 Pod。它通常用於部署需要在每個節點上運行的系統守護進程，例如日誌收集器和監控代理。
DaemonSet 與 ReplicaSet
- 相似之處：兩者都管理長期運行的 Pod 並確保集群狀態與期望狀態匹配。
- 區別：ReplicaSet 適用於將應用程式的多個副本分配到集群的不同節點，沒有特別的節點限制；而 DaemonSet 確保應用程式的單一副本在所有或部分節點上運行。
DaemonSet Scheduler
預設情況下，DaemonSet 會在每個節點上建立 Pod 副本。
DaemonSet 使用 nodeName 欄位指定 Pod 所在的節點，並由 DaemonSet 控制器進行管理。控制器會自動在缺少 Pod 的節點上創建 Pod。
當新增節點時，DaemonSet 控制器會在新節點上創建缺失的 Pod。
限制 DaemonSet 到特定節點
若需要僅在特定節點上運行 DaemonSet，則可以使用節點標籤和節點選擇器來指定符合要求的節點。例如，若某些節點擁有 GPU 或特殊存儲設備，則可以透過 kubectl label 為節點添加標籤，然後使用節點選擇器限制 DaemonSet 的部署。
Rolling Update Strategy
DaemonSet 支持滾動更新，並具有兩個關鍵參數：
spec.minReadySeconds：確保 Pod 在滾動更新時在繼續更新其他 Pod 前，先準備好指定的時間。spec.updateStrategy.rollingUpdate.maxUnavailable：指定滾動更新時可以同時更新的 Pod 數量。
此章總結
DaemonSet 是一個強大的抽象層，允許在 Kubernetes 叢集中的每個節點上運行一組 Pod，或根據標籤選擇特定節點來運行。它提供了專門的控制器來管理和調度這些 Pod，確保如監控代理等關鍵服務能夠在集群的正確節點上運行。
DaemonSet 的自動化管理特別適用於動態縮放的叢集環境中，當新節點加入集群時，DaemonSet 會自動在新節點上啟動必要的 Pod。
