摘要：完全兼容原生的，以私有網(wǎng)絡(luò)為基礎(chǔ)，并整合了等云產(chǎn)品。綜合資源有效利用率錯(cuò)誤容忍度兩個(gè)因素，在不考慮業(yè)務(wù)混合部署業(yè)務(wù)總體規(guī)模大小的情況下，我們建議生產(chǎn)環(huán)境的節(jié)點(diǎn)應(yīng)該介于核至核之間。模式是一個(gè)用于負(fù)載均衡的內(nèi)核功能。

產(chǎn)品概念

UCloud Container Service for Kubernetes （UK8S）是一項(xiàng)基于Kubernetes的容器管理服務(wù)，你可以在UK8S上部署、管理、擴(kuò)展你的容器化應(yīng)用，而無(wú)需關(guān)心Kubernetes集群自身的搭建及維護(hù)等運(yùn)維類工作。

UK8S完全兼容原生的Kubernetes API，以UCloud私有網(wǎng)絡(luò)為基礎(chǔ)，并整合了ULB、UDisk、EIP、VPC等云產(chǎn)品。

使用須知

集群

1. 使用UK8S服務(wù)，必須通過(guò)UCloud實(shí)名認(rèn)證服務(wù)；
2. 集群中master節(jié)點(diǎn)為管理節(jié)點(diǎn)，不建議服務(wù)調(diào)度到管理集群運(yùn)行；
3. 單個(gè)UK8S集群最多添加5000個(gè)Node節(jié)點(diǎn)，生產(chǎn)集群建議不超過(guò)1000個(gè)；
4. 支持的Kubernetes版本會(huì)落后社區(qū)2個(gè)版本，具體以產(chǎn)品頁(yè)面為準(zhǔn)；
5. 如果的云賬戶開(kāi)啟了API白名單則需要在白名單中配置10.10.10.10/32網(wǎng)段，詳見(jiàn)API白名單配置

節(jié)點(diǎn)

1. Node節(jié)點(diǎn)使用的云主機(jī)鏡像默認(rèn)為 Centos7.6，如果重裝系統(tǒng)或擅自修改系統(tǒng)配置，可能導(dǎo)致集群不可用；
2. Node節(jié)點(diǎn)使用的云主機(jī)系統(tǒng)盤默認(rèn)為SSD，支持添加數(shù)據(jù)盤，添加數(shù)據(jù)盤后，容器啟動(dòng)后默認(rèn)運(yùn)行在數(shù)據(jù)盤；
3. 云主機(jī)默認(rèn)使用N機(jī)型，您也可以選擇其他機(jī)型（如O型、C型)；
4. 節(jié)點(diǎn)標(biāo)簽UhostID=xxx為主機(jī)管理使用標(biāo)簽，請(qǐng)勿刪除修改，以免導(dǎo)致集群數(shù)據(jù)不正常；

存儲(chǔ)卷

1. 當(dāng)前支持SATA、SSD UDisk以及UFS；

   在UK8S中使用UDisk

   在UK8S中使用UFS

   在UK8S中使用UFile

2. 當(dāng)前支持共享存儲(chǔ)的地域：

其他

當(dāng)你創(chuàng)建UK8S集群后，UK8S會(huì)以你的名義在當(dāng)前項(xiàng)目下創(chuàng)建UHost、ULB、UDisk、EIP等資源，更改配置或刪除可能導(dǎo)致集群不可用，請(qǐng)謹(jǐn)慎操作。主要如下：

1、由UK8S管理服務(wù)創(chuàng)建的資源，其命名規(guī)范如下：

1.1、 uk8s-trd3u-master-3或uk8s-trd3u-m-xsdaf為UHost名稱，作為集群的Master節(jié)點(diǎn)；

1.2、 uk8s-trd3u-node-3或uk8s-trd3u-n-xsa2f為UHost名稱，作為集群的Node節(jié)點(diǎn)；

1.3、 uk8s-trd3u-master-ulb為ULB名稱，作為ApiServer的內(nèi)網(wǎng)入口；

1.4、 uk8s-trd3u-master-ulb-external為ULB名稱，作為ApiServer的外網(wǎng)入口；

1.5、 數(shù)據(jù)盤_uk8s-sr0xsohz-node-6或數(shù)據(jù)盤_uk8s-sr0xsohz-n-xsa2f為UDisk名稱，作為集群的Node節(jié)點(diǎn)數(shù)據(jù)盤；

1.6、 系統(tǒng)盤_uk8s-sr0xsohz-node-6或系統(tǒng)盤_uk8s-sr0xsohz-n-xsa2f為UDisk名稱，作為集群的Node節(jié)點(diǎn)系統(tǒng)盤；

2、由UK8S插件創(chuàng)建的資源，其命名規(guī)范如下：

2.1、 ULB名稱為ingress-nginx.ingress.svc.uk8s-xy7udsa的，由UK8S的ULB插件創(chuàng)建，用于LoadBalancer類型的Service，且其備注為UID-xx-xxx，實(shí)為Service在UK8S中的uuid。其命名規(guī)范為svc-name.namespace.svc.uk8s-id。

2.2、 Vserver名稱為TCP_443_xxx-xxxxx的，由UK8S的ULB插件創(chuàng)建，對(duì)應(yīng)LoadBalancer類型的Service中不同的端口。其命名規(guī)范為service-protocol_service-port_service_uuid。

2.3、 UDisk名稱為pvc-9393f66f-c0b5-11e9-bd6d-5254001935f2的，由UK8S的存儲(chǔ)插件創(chuàng)建，對(duì)應(yīng)UK8S中的PVC。其命名規(guī)范為pvc-pvc_uuid。

名詞解釋

為了幫助你更好地使用UK8S，你需要對(duì)Kubernetes的相關(guān)組件有一個(gè)大致的了解，本文會(huì)對(duì)基礎(chǔ)組件及概念做一個(gè)簡(jiǎn)要的介紹，如果你希望了解更多內(nèi)容，請(qǐng)移步Kubernetes官方文檔

Kubernetes基礎(chǔ)架構(gòu)

上圖是一個(gè)概要性的Kubernetes架構(gòu)，包含了ApiServer，Master、Node、Hub（鏡像倉(cāng)庫(kù)）等概念，下面我們依次做個(gè)簡(jiǎn)要介紹。

ApiServer： ApiServer是操作集群的唯一入口，并提供認(rèn)證、授權(quán)、訪問(wèn)控制、API注冊(cè)和發(fā)現(xiàn)等機(jī)制，ApiServer作為一個(gè)組件運(yùn)行在Master上。

Node：Node是Kubernetes的工作節(jié)點(diǎn)，其上包含運(yùn)行Pod所需要的服務(wù)。Node可以是虛擬機(jī)也可以是物理機(jī)，在UK8S，目前只支持虛擬機(jī)即UHost。

Master： Master也是Kubernetes的工作節(jié)點(diǎn)，與Node不同的是，Master通常不運(yùn)行業(yè)務(wù)Pod，而是安裝了用于控制和管理集群的如ApiServer、Scheduler、Controller Manager、Cloud Controller Manager、ETCD等組件。

Hub鏡像倉(cāng)庫(kù) Hub提供Docker鏡像的管理、存儲(chǔ)、分發(fā)能力。

漏洞修復(fù)記錄

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

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

1、Master配置推薦

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

2、如何選擇Node配置大小

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

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

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

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

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

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

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

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

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

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

kube-proxy模式選擇

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

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

如何選擇

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

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

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

如何切換

請(qǐng)參考kube-proxy模式切換

iptables模式

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

IPVS模式

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

模式對(duì)比

無(wú)論是iptables模式還是IPVS模式，轉(zhuǎn)發(fā)性能都與Service及對(duì)應(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三次握手連接建立的過(guò)程，因此在大量短連接請(qǐng)求的場(chǎng)景下，兩種模式的性能差異尤為突出。

在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ā)性能則相對(duì)穩(wěn)定。

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

測(cè)試用例

我們使用了2臺(tái)Node作為測(cè)試節(jié)點(diǎn)，一臺(tái)節(jié)點(diǎn)KubeProxy使用iptables模式，記為N1；另一臺(tái)KubeProxy使用IPVS模式，記為N2。

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

在N1和N2上分別但不同時(shí)執(zhí)行測(cè)試命令，觀察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團(tuán)隊(duì)針對(duì)IPVS和iptables進(jìn)行的性能測(cè)試數(shù)據(jù)。

可以看出，在Service數(shù)量為100和500時(shí)，iptables轉(zhuǎn)發(fā)性能要優(yōu)于IPVS；Service數(shù)量達(dá)到1000時(shí)，兩者大體持平；Service數(shù)量繼續(xù)增大，IPVS的性能優(yōu)勢(shì)則越發(fā)明顯。