【容器云 UK8S】產(chǎn)品簡介：漏洞修復(fù)記錄、集群節(jié)點配置推薦和kube-proxy模式選擇

Tecode 發(fā)布于2022-06-28 18:59 / 2115人閱讀

摘要：模式選擇是中的關(guān)鍵組件其主要功能是在和其后端之間進行負載均衡。詳見后續(xù)測試數(shù)據(jù)對于集群規(guī)模中等，數(shù)量不多的，推薦選擇。模式下，使用負載均衡代替了。

漏洞修復(fù)記錄

HTTP/2漏洞升級說明
Runc容器逃逸漏洞修復(fù)說明
cloudprovider更新20.10.1

集群節(jié)點配置推薦

1、Master配置推薦

Master規(guī)格跟集群規(guī)模有關(guān)，集群規(guī)模越大，所需要的Master規(guī)格也越高，不同集群規(guī)模的，Master節(jié)點配置推薦如下：

節(jié)點規(guī)模	Master規(guī)格
1-10個節(jié)點	>=2核4G
10-100個節(jié)點	>=4核8G
100-250個節(jié)點	>=8核16G
250-500個節(jié)點	>=16核32G
500-1000個節(jié)點	>=32核64G
1000個以上節(jié)點	聯(lián)系我們

2、如何選擇Node配置大小

關(guān)于Node節(jié)點的資源預(yù)留策略

在確定UK8S的Node節(jié)點配置之前，您需要知道，UK8S Node默認(rèn)預(yù)留1G內(nèi)存，0.2核CPU以保障系統(tǒng)穩(wěn)定運行。這些預(yù)留的資源是給系統(tǒng)及kubernetes相關(guān)服務(wù)進程使用的。

且當(dāng)可用內(nèi)存小于5%時會根據(jù)pod資源優(yōu)先級開始驅(qū)逐，pod實際可使用的內(nèi)存約為{memeroy of Node}-1G-5% (例如：4G內(nèi)存，可用約為2.8G)，同時，單個節(jié)點可創(chuàng)建Pod和Node CPU核數(shù)有關(guān)。pods數(shù)量=CPU核數(shù) x 8 (例如：2核=16 pods， 4核=32 pods)。

因此，我們建議Node的配置>=2C4G，這是保證集群正常運行的基礎(chǔ)配置。

至于生產(chǎn)環(huán)境的Node配置選項，可根據(jù)整個集群的日常使用的總核數(shù)以及故障容忍度、業(yè)務(wù)類型綜合考量，具體如下：

假設(shè)集群總核數(shù)設(shè)定為240核（基于過往運營數(shù)據(jù)而定），可以容忍10%的錯誤。那么可以選擇10臺24核UHost，并且高峰運行的負荷不要超過240*90%=216核。如果容忍度小于5%，那么可以選擇15臺16核的UHost，這樣就算有一臺節(jié)點出現(xiàn)故障，剩余節(jié)點仍可以支持現(xiàn)有業(yè)務(wù)正常運行（工作負載自動遷移）。

從提供錯誤容忍度的角度看，節(jié)點配置越低，節(jié)點會更多，那可用性也會相應(yīng)地提高。但也存在另外兩個弊端，一是需要預(yù)留給K8S的資源過多，造成浪費；二是不便于容器調(diào)度，甚至?xí)?dǎo)致部分容器無法被注冊。一個極端的例子，3臺8核的節(jié)點，可創(chuàng)建6個需要預(yù)留4核的Pod，但12臺2C的節(jié)點，卻無法響應(yīng)一個需要預(yù)留4核資源的Pod請求。

綜合資源有效利用率、錯誤容忍度兩個因素，在不考慮業(yè)務(wù)混合部署、業(yè)務(wù)總體規(guī)模大小的情況下，我們建議生產(chǎn)環(huán)境的Node節(jié)點CPU應(yīng)該介于4核至32核之間。

至于CPU：Memory比例，建議根據(jù)自身的應(yīng)用類型申請合適的機型，例如CPU密集型的業(yè)務(wù)可以申請1：2的機型，Java類的應(yīng)用可以申請1:4或1:8的機型，如果是不同業(yè)務(wù)混合部署，最好給Node打好標(biāo)簽，配合nodeAffinity合理調(diào)度Pod。

最后是系統(tǒng)盤，UK8S的Node節(jié)點默認(rèn)40G系統(tǒng)盤，節(jié)點創(chuàng)建時可選擇數(shù)據(jù)盤掛載，這個盤是專門提供給docker存放本地鏡像的。節(jié)點創(chuàng)建完成后依然可以在主機側(cè)掛載數(shù)據(jù)盤（請保證磁盤空間充足，當(dāng)磁盤空間不足時，將會隨機刪除docker鏡像與pod）。

kube-proxy模式選擇

kube-proxy是kubernetes中的關(guān)鍵組件其主要功能是在Service和其后端Pod之間（Endpoint）進行負載均衡。kube-proxy 有三種運行模式，每種都有不同的實現(xiàn)技術(shù)：userspace、iptables或者IPVS。

userspace模式由于性能問題已經(jīng)不推薦使用。這里主要介紹iptables和IPVS兩種模式的比較及選擇。

如何選擇

對于集群規(guī)模較大，特別是Service數(shù)量可能超過1000的，推薦選擇IPVS。（詳見后續(xù)測試數(shù)據(jù)）
對于集群規(guī)模中等，Service數(shù)量不多的，推薦選擇iptables。
如果客戶端會出現(xiàn)大量并發(fā)短鏈接，目前建議選擇iptables，原因見下方備注。

備注：在使用IPVS模式的kubernetes集群中進行滾動更新，期間如果有一個客戶端在短時間內(nèi)（兩分鐘）內(nèi)發(fā)送大量短鏈接，客戶端端口會被復(fù)用，導(dǎo)致node收到的來自于該客戶端的請求報文網(wǎng)絡(luò)五元組相同，觸發(fā)IPVS復(fù)用Connection，有可能導(dǎo)致報文被轉(zhuǎn)發(fā)到了一個已經(jīng)銷毀的Pod上，導(dǎo)致業(yè)務(wù)異常。

官方issue：https://github.com/kubernetes/kubernetes/issues/81775

如何切換

請參考kube-proxy模式切換

iptables模式

iptables是一個Linux內(nèi)核功能，是一個高效的防火墻，并提供了數(shù)據(jù)包處理和過濾方面的能力。它可以在核心數(shù)據(jù)包處理管線上用Hook掛接一系列的規(guī)則。iptables模式中kube-proxy在NAT pre-routing Hook中實現(xiàn)它的NAT和負載均衡功能。這種方法簡單有效，依賴于成熟的內(nèi)核功能，并且能夠和其它跟 iptables 協(xié)作的應(yīng)用融洽相處。

IPVS模式

IPVS是一個用于負載均衡的Linux內(nèi)核功能。IPVS模式下，kube-proxy使用IPVS負載均衡代替了iptables。IPVS的設(shè)計思路就是用來為大量服務(wù)進行負載均衡的，它有一套優(yōu)化過的API，使用優(yōu)化的查找算法，而不是從列表中查找規(guī)則，在大規(guī)模場景下相對IPVS性能更好。

模式對比

無論是iptables模式還是IPVS模式，轉(zhuǎn)發(fā)性能都與Service及對應(yīng)的Endpoint數(shù)量有關(guān)，原因是Node上iptables或IPVS轉(zhuǎn)發(fā)規(guī)則的數(shù)量與svc和ep的數(shù)目成正比。

IPVS和iptables轉(zhuǎn)發(fā)性能主要差異體現(xiàn)在TCP三次握手連接建立的過程，因此在大量短連接請求的場景下，兩種模式的性能差異尤為突出。

在Service和Endpoint的數(shù)量較少的情況下(Service數(shù)十到數(shù)百，Endpoint數(shù)百到數(shù)千)，iptables模式轉(zhuǎn)發(fā)性能要略優(yōu)于IPVS。

隨著Service和Endpoint的數(shù)量逐漸提升，iptables模式轉(zhuǎn)發(fā)性能明顯下降，IPVS模式轉(zhuǎn)發(fā)性能則相對穩(wěn)定。

Service數(shù)量1000左右，Endpoint數(shù)量到20000左右時，iptables模式轉(zhuǎn)發(fā)性能開始低于IPVS，隨著Service和Endpoint的數(shù)量繼續(xù)增大（Service數(shù)千，Endpoint數(shù)萬），IPVS模式性能略微下降，iptables模式性能則大幅下降。

測試用例

我們使用了2臺Node作為測試節(jié)點，一臺節(jié)點KubeProxy使用iptables模式，記為N1；另一臺KubeProxy使用IPVS模式，記為N2。

在N1和N2上準(zhǔn)備好壓測客戶端ab，并發(fā)連接數(shù)1000，一共需要完成10000次短連接請求。

在N1和N2上分別但不同時執(zhí)行測試命令，觀察ab返回的結(jié)果：

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數(shù)量100，500，1000，2000，3000，4000，觀察結(jié)果采集數(shù)據(jù)。

以下為UK8S團隊針對IPVS和iptables進行的性能測試數(shù)據(jù)。