資訊專欄INFORMATION COLUMN
摘要：模式選擇是中的關鍵組件其主要功能是在和其后端之間進行負載均衡。詳見后續測試數據對于集群規模中等，數量不多的，推薦選擇。模式下，使用負載均衡代替了。
Master規格跟集群規模有關，集群規模越大，所需要的Master規格也越高，不同集群規模的，Master節點配置推薦如下：
| 節點規模 | Master規格 |
|---|---|
| 1-10個節點 | >=2核4G |
| 10-100個節點 | >=4核8G |
| 100-250個節點 | >=8核16G |
| 250-500個節點 | >=16核32G |
| 500-1000個節點 | >=32核64G |
| 1000個以上節點 | 聯系我們 |
關于Node節點的資源預留策略
在確定UK8S的Node節點配置之前，您需要知道，UK8S Node默認預留1G內存，0.2核CPU以保障系統穩定運行。這些預留的資源是給系統及kubernetes相關服務進程使用的。
且當可用內存小于5%時會根據pod資源優先級開始驅逐，pod實際可使用的內存約為{memeroy of Node}-1G-5% (例如：4G內存，可用約為2.8G)，同時，單個節點可創建Pod和Node CPU核數有關。pods數量=CPU核數 x 8 (例如：2核=16 pods， 4核=32 pods)。
因此，我們建議Node的配置>=2C4G，這是保證集群正常運行的基礎配置。
至于生產環境的Node配置選項，可根據整個集群的日常使用的總核數以及故障容忍度、業務類型綜合考量，具體如下：
假設集群總核數設定為240核（基于過往運營數據而定），可以容忍10%的錯誤。那么可以選擇10臺24核UHost，并且高峰運行的負荷不要超過240*90%=216核。如果容忍度小于5%，那么可以選擇15臺16核的UHost，這樣就算有一臺節點出現故障，剩余節點仍可以支持現有業務正常運行（工作負載自動遷移）。
從提供錯誤容忍度的角度看，節點配置越低，節點會更多，那可用性也會相應地提高。但也存在另外兩個弊端，一是需要預留給K8S的資源過多，造成浪費；二是不便于容器調度，甚至會導致部分容器無法被注冊。一個極端的例子，3臺8核的節點，可創建6個需要預留4核的Pod，但12臺2C的節點，卻無法響應一個需要預留4核資源的Pod請求。
綜合資源有效利用率、錯誤容忍度兩個因素，在不考慮業務混合部署、業務總體規模大小的情況下，我們建議生產環境的Node節點CPU應該介于4核至32核之間。
至于CPU：Memory比例，建議根據自身的應用類型申請合適的機型，例如CPU密集型的業務可以申請1：2的機型，Java類的應用可以申請1:4或1:8的機型，如果是不同業務混合部署，最好給Node打好標簽，配合nodeAffinity合理調度Pod。
最后是系統盤，UK8S的Node節點默認40G系統盤，節點創建時可選擇數據盤掛載，這個盤是專門提供給docker存放本地鏡像的。節點創建完成后依然可以在主機側掛載數據盤（請保證磁盤空間充足，當磁盤空間不足時，將會隨機刪除docker鏡像與pod）。
kube-proxy是kubernetes中的關鍵組件其主要功能是在Service和其后端Pod之間（Endpoint）進行負載均衡。kube-proxy 有三種運行模式，每種都有不同的實現技術：userspace、iptables或者IPVS。
userspace模式由于性能問題已經不推薦使用。這里主要介紹iptables和IPVS兩種模式的比較及選擇。
備注：在使用IPVS模式的kubernetes集群中進行滾動更新，期間如果有一個客戶端在短時間內（兩分鐘）內發送大量短鏈接，客戶端端口會被復用，導致node收到的來自于該客戶端的請求報文網絡五元組相同，觸發IPVS復用Connection，有可能導致報文被轉發到了一個已經銷毀的Pod上，導致業務異常。
官方issue：https://github.com/kubernetes/kubernetes/issues/81775
iptables是一個Linux內核功能，是一個高效的防火墻，并提供了數據包處理和過濾方面的能力。它可以在核心數據包處理管線上用Hook掛接一系列的規則。iptables模式中kube-proxy在NAT pre-routing Hook中實現它的NAT和負載均衡功能。這種方法簡單有效，依賴于成熟的內核功能，并且能夠和其它跟 iptables 協作的應用融洽相處。
IPVS是一個用于負載均衡的Linux內核功能。IPVS模式下，kube-proxy使用IPVS負載均衡代替了iptables。IPVS的設計思路就是用來為大量服務進行負載均衡的，它有一套優化過的API，使用優化的查找算法，而不是從列表中查找規則，在大規模場景下相對IPVS性能更好。
無論是iptables模式還是IPVS模式，轉發性能都與Service及對應的Endpoint數量有關，原因是Node上iptables或IPVS轉發規則的數量與svc和ep的數目成正比。
IPVS和iptables轉發性能主要差異體現在TCP三次握手連接建立的過程，因此在大量短連接請求的場景下，兩種模式的性能差異尤為突出。
在Service和Endpoint的數量較少的情況下(Service數十到數百，Endpoint數百到數千)，iptables模式轉發性能要略優于IPVS。
隨著Service和Endpoint的數量逐漸提升，iptables模式轉發性能明顯下降，IPVS模式轉發性能則相對穩定。
Service數量1000左右，Endpoint數量到20000左右時，iptables模式轉發性能開始低于IPVS，隨著Service和Endpoint的數量繼續增大（Service數千，Endpoint數萬），IPVS模式性能略微下降，iptables模式性能則大幅下降。
我們使用了2臺Node作為測試節點，一臺節點KubeProxy使用iptables模式，記為N1；另一臺KubeProxy使用IPVS模式，記為N2。
在N1和N2上準備好壓測客戶端ab，并發連接數1000，一共需要完成10000次短連接請求。
在N1和N2上分別但不同時執行測試命令，觀察ab返回的結果：
Connection Times (ms)
min mean[+/-sd] median max
Connect: 1 38 8.4 38 59
Processing: 10 41 9.7 40 67
Waiting: 1 28 9.0 28 56
Total: 51 79 7.5 78 101不斷變化Service數量100，500，1000，2000，3000，4000，觀察結果采集數據。
以下為UK8S團隊針對IPVS和iptables進行的性能測試數據。
可以看出，在Service數量為100和500時，iptables轉發性能要優于IPVS；Service數量達到1000時，兩者大體持平；Service數量繼續增大，IPVS的性能優勢則越發明顯。
實時文檔歡迎訪問https://docs.ucloud.cn/uk8s/introduction/vulnerability/cve2019-9512-9514
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/126121.html
摘要：完全兼容原生的，以私有網絡為基礎，并整合了等云產品。綜合資源有效利用率錯誤容忍度兩個因素，在不考慮業務混合部署業務總體規模大小的情況下，我們建議生產環境的節點應該介于核至核之間。模式是一個用于負載均衡的內核功能。產品概念UCloud Container Service for Kubernetes （UK8S）是一項基于Kubernetes的容器管理服務，你可以在UK8S上部署、管理、擴展你...
摘要：詳細請見產品價格產品概念使用須知名詞解釋漏洞修復記錄集群節點配置推薦模式選擇產品價格操作指南集群創建需要注意的幾點分別是使用必讀講解使用需要賦予的權限模式切換的切換等。UK8S概覽UK8S是一項基于Kubernetes的容器管理服務，你可以在UK8S上部署、管理、擴展你的容器化應用，而無需關心Kubernetes集群自身的搭建及維護等運維類工作。了解使用UK8S為了讓您更快上手使用，享受UK...
摘要：創建集群如果你是初次接觸，我們建議你預先創建好一個新的和子網，與生產環境隔離。節點的可用區選擇會根據的可用區選擇變化，現已支持針對節點的平臺硬件隔離組最大數標簽等設置。創建集群如果你是初次接觸Kubernetes，我們建議你預先創建好一個新的VPC和子網，與生產環境隔離。創建集群之前，你需要先了解下Kubernetes中的Node CIDR、Pod CIDR、Service CIDR等基本概...
摘要：已如下集群為例，集群模式默認是。我們在此修改為模式。切換集群節點的模式我們采用新增新節點，新節點后刪除一個老節點的循環操作進行集群全部節點的模式切換。節點不在調度范圍內，不用進行切換。kube-proxy模式切換在UK8S集群創建時我們會對集群創建生成默認的kube-proxy模式，在集群中新增的Node節點都會依賴這個集群默認kube-proxy模式進行新增，您可以參考以下操作進行集群ku...
閱讀 3514·2023-04-25 20:09
閱讀 3720·2022-06-28 19:00
閱讀 3035·2022-06-28 19:00
閱讀 3058·2022-06-28 19:00
閱讀 3131·2022-06-28 19:00
閱讀 2859·2022-06-28 19:00
閱讀 3014·2022-06-28 19:00
閱讀 2610·2022-06-28 19:00
