2.3 規劃集群規模

在本節中，你將部署一個多節點的OpenShift集群。有一些注意事項，其中最重要的是規劃集群的大小和容量。

2.3.1 實例大小的建議

OpenShift文檔中有一些關于如何擴展集群實例的指導意見。讓我們來看看，如果你的規模太小，你會遇到哪些潛在的問題。你可以有把握地認為，除了成本之外，擴展過大并不是一個問題。在下面的章節中，你也會發現有關這方面的評論。

實例大小與你的工作負載直接相關，master節點和node節點的行為在某種程度上是相似的。你計劃運行的工作負載越多，你的實例就必須變得越大。然而，它們的擴展方式在根本上是不同的。node節點直接與工作負載幾乎呈線性關系，而master節點則不然。這意味著，一個集群的容量可以擴展到一定程度，而不需要對控制面進行任何調整。

2.3.2 node節點大小的建議

為了更好地說明節點的擴展行為，讓我們看一個例子。

想一想一個由三個node節點組成的集群，暫時不考慮master節點。每個節點都是AWS的m5.xlarge，所以有4個vCPU和8GB的內存。這使你的集群總容量為12個vCPU和24GB內存。在這個虛擬場景中，你可以嘗試以完美的分布運行工作負載，并使用所有的資源，然后你將需要將節點擴展到更大的實例（水平擴展）或更多的實例（垂直擴展）。再增加一個實例，集群的容量就會線性增長。現在你有16個vCPU和32GB，用于我們的工作負載。

上述情況忽略了一個小而重要的細節：系統保留和kube保留的容量。從OpenShift 4.8版本開始，OpenShift可以自動處理這個問題。要啟用這個功能，請在KubeletConfig中添加以下內容：

可以在安裝后以及創建集群前調整KubeletConfig。強制OpenShift占用系統相關的資源是確保集群功能的一個推薦設置，除非有明確的原因，否則不應省略。

設想一下：10個運行在一個m5.xlarge node的pod，每個pod都有一組0.4個CPU的請求的資源，而且它們實際使用了這個資源。自然，你的系統進程會遇到麻煩，該節點變得不穩定。在最壞的情況下，該節點變得沒有反應并崩潰，其上的工作負載被重新分配到其他節點，使這些節點超載，你最終會發生連鎖反應：你的整個集群變得不穩定。從這個角度來看，犧牲一些寶貴的容量來確保集群的穩定性，是一個很小的代價。

因此，我們知道，節點的規模與工作負載呈線性關系，我們需要在此基礎上增加一些保留容量。那么，你的節點應該有多大？我們必須考慮三個問題：

?你的單一最大工作負載有多大？

?你能在多大程度上利用一個大節點？

?你能以多快的速度部署更多的節點？

單一最大的工作負載決定了一個節點的最小尺寸。解釋是，如果你不能在一個節點上運行工作負載，那么你就有問題了，因為你希望能夠將所有的工作負載部署到集群上。

這一點的反面是你想要實現的效率。讓一個節點一直在50%的使用率下閑置，實際上只是在燒錢。你想在能夠適應所有工作負載，同時又能充分利用你的節點之間找到一個平衡點。這兩點共同導致了我們希望使用盡可能小的節點，如果你需要更多的節點，就再部署一個，這樣即使在集群中增加一個額外的節點，每個節點的利用率仍然很高。

能使你選擇不同路徑的因素是時間：在你遇到容量問題時，部署另一個節點所需的時間。某些部署方式比其他方式要快。例如，設置自動化可以允許你在5分鐘內將另一個節點部署到集群中，這與在數據中心手動配置一個新的刀片并等待一天直到數據中心團隊安裝和連接它有很大區別。

這里的規則是，你配置新節點的速度越慢，單個節點需要越大，你就必須越早配置新節點。提供新節點的時間直接影響到你想達到的每個節點的最大利用率。

2.3.3 master節點大小的建議

node節點對于給你的工作負載提供一個運行環境很重要，但master是OpenShift的核心。

master，即控制面節點，是保持集群運行的原因，因為它們運行著：

?etcd

?API服務器（kube和OpenShift）

?控制管理器（kube和OpenShift）

?OpenShift Oauth API服務器

?OpenShift Oauth服務器

?HA代理

master不直接運行工作負載，因此，當涉及可擴展性時，它們的行為是不同的。相對于node節點的線性可擴展性需求（取決于工作負載），master的容量必須與節點的數量一起擴展。

與node節點可擴展性相比，另一個區別是你需要關注垂直擴展而不是水平擴展。你不能簡單地橫向擴展master節點，因為一些在master節點上運行的組件需要一個法定人數以及復制。最突出的例子是etcd。狀態、密鑰等的中心存儲只是其中一個組件。理論上，只要能形成一個法定人數，OpenShift集群中幾乎可以有任意數量的master。這意味著需要進行領導選舉，并獲得多數票。這可能會變得相當棘手，比如說像4或2的偶數節點。在這些情況下，不能保證任何給定的節點會有多數票，領導選舉可能會被卡住，或者更糟的是，可能會選出多個領導，這可能會破壞集群的穩定性。問題是：“為什么不是只有1個？”這個問題的答案是集群的彈性。你不能因為只有一個故障點而使你的整個集群面臨風險，因為沒有master節點，集群基本上是無法使用的。想象一下這樣的情景：你有一個master實例，而它因為底層基礎設施的故障而崩潰。這時，整個集群完全沒有用處，從這種故障中恢復是很難的。接下來最小的選項是3，這也是我們的建議。事實上，官方文件指出，所有的生產部署必須使用正好三個master節點（https://oreil.ly/Izxdc）。

設置好master節點的數量后，我們就可以選擇垂直擴展了。然而，由于master節點是集群的核心，當你調整已經運行的master節點的大小時，你必須考慮到集群的脆弱狀態，因為它需要被關閉以調整大小。

請確保為增長做計劃。如果你計劃在一開始就有20個節點，以便為你的工作負載提供空間，那就選擇下一個更大尺寸的master節點實例。這樣做的代價不大，但會因為避免了主實例的擴展操作而為你節省大量的工作和風險。

2.3.4 infra節點

infra節點是帶有額外標簽的工作節點。除此以外，它們只是普通的OpenShift節點。那么，如果它們只是節點，為什么它們會有額外的標簽？有兩個原因：成本和集群的彈性。

第一個且最簡單的原因是成本。某些基礎設施的工作負載不會觸發紅帽的訂閱費用。這意味著，如果你有一個專門運行基礎設施工作負載的節點，你不必為該節點支付訂閱費用。這似乎是一個省錢的簡單方法。為了完整起見，不需要節點訂閱的組件的完整列表可以在最新的文檔（https://oreil.ly/ef1Ea）中找到。有些組件在master上運行，也需要在那里，比如OCP控制面。其他的則可以隨意移動。因此，你創建了一組新的節點，帶有infra標簽。

第二個原因是集群的彈性。當常規工作負載和infra工作負載在同一個節點上時，對OpenShift來說并沒有什么區別。想象一下，一個只有master和worker節點的常規集群。你把所有的應用程序以及開箱即用的infra工作負載部署到節點上。現在，當不幸的情況發生時，你的資源用完了，infra工作負載可能會像常規應用程序工作負載一樣被殺死。當然，這不是最好的情況。另外，當所有與基礎設施相關的工作負載被安全地放在自己的一組節點上時，常規應用程序根本不會影響它們，從而創造出更好的彈性和更好的性能。適合移動到infra節點的有：

?集群內監控（configmap）

?路由器（IngressController）

?默認鏡像注冊表（Config）

通過向括號內標注的相應元素添加標簽來移動它們。下面的示例展示了如何在集群內監控解決方案中執行此操作。

將它添加到已經存在的configmap中，或者用它創建一個新的configmap。對于后一個選項，我們將創建前面的文件，并按如下方式應用它：

接下來執行下面的命令：

關于infra節點的擴展的最后一個注意事項：它們的擴展方式幾乎與master節點相同。首先，它們需要垂直擴展的原因是Prometheus作為集群內監控解決方案的一部分，需要更多的內存和存儲更多的指標。