容器云平臺(tái)的性能設(shè)計(jì)

1、容器云平臺(tái)的性能設(shè)計(jì)（下載原文可改文字顏色）II目錄目錄4.1 計(jì)算節(jié)點(diǎn)架構(gòu)和容量154.2 計(jì)算節(jié)點(diǎn)監(jiān)控和性能調(diào)優(yōu)174.3 應(yīng)用規(guī)劃18亨1Kubernetes整體容量規(guī)劃通常個(gè)完整的高可用Kubernetes群集田3奀節(jié)點(diǎn)組成：Master節(jié)點(diǎn)用千運(yùn)行APIServer和ETCD等控制服務(wù)。Infra節(jié)點(diǎn)：涉及容器基礎(chǔ)設(shè)施相關(guān)，包括負(fù)責(zé)日志查詢的EFK集群、負(fù)責(zé)容器監(jiān)控的Prometheus和AlertManager集群和負(fù)責(zé)外部流量導(dǎo)入的Ingress集群等。App節(jié)點(diǎn)負(fù)責(zé)運(yùn)行普通業(yè)務(wù)應(yīng)用的節(jié)點(diǎn)。每個(gè)計(jì)算節(jié)點(diǎn)都具有些可分配的資源(CPU,內(nèi)存，GPU等）。因此如何更合理地分配這些計(jì)算資

2、源在確保平臺(tái)本身穩(wěn)定性的同時(shí)滿足業(yè)務(wù)需求并提升資掠利用率，這就需要對(duì)集群的容量進(jìn)行規(guī)劃。針對(duì)集群計(jì)算資掠，首先需要定義節(jié)點(diǎn)數(shù)量和總資源容量。假設(shè)要在群集上運(yùn)行的個(gè)應(yīng)用需要總?cè)萘繛?Core32G的計(jì)算資源，這里主要有2種部署思路：21個(gè)思路是使用2臺(tái)4Core16GB服務(wù)器實(shí)例作為Kubernetes工作節(jié)點(diǎn)即較少的節(jié)點(diǎn)較高配的服務(wù)器（類似集群直接使用物理機(jī)）。另個(gè)思路是使用4臺(tái)2Core8GB服務(wù)器實(shí)例作為Kubernetes工作節(jié)點(diǎn)（類似集群使用虛擬機(jī)）。這么，哪種思路更有優(yōu)勢(shì)？下文我們做下對(duì)比：高配置方案低配置方案管理便利性節(jié)點(diǎn)少，管理成本低節(jié)點(diǎn)多，管理成本高應(yīng)用可用資源單節(jié)點(diǎn)資源多、應(yīng)

3、用適配靈活單節(jié)點(diǎn)資源較少、應(yīng)用單實(shí)例資源依賴不可過(guò)大應(yīng)用穩(wěn)定性單節(jié)點(diǎn)應(yīng)用較多，爆炸半徑大單節(jié)點(diǎn)應(yīng)用較少，爆炸半徑小資源利用率單節(jié)點(diǎn)資源顆粒度大，可充分利用單節(jié)點(diǎn)資源顆粒度小，可能無(wú)法滿足應(yīng)用而閑置由上圖可以發(fā)現(xiàn)，如果使用高配置方案，針對(duì)集群的管理便利性由千節(jié)點(diǎn)數(shù)量較少而變得較為簡(jiǎn)單，同時(shí)針對(duì)應(yīng)用的資源利用率會(huì)有所提升。但是同樣也需要注意到由千節(jié)點(diǎn)密度較高，單個(gè)節(jié)點(diǎn)出現(xiàn)故障后的導(dǎo)致應(yīng)用影響的爆炸半徑會(huì)比較大，對(duì)節(jié)點(diǎn)容量規(guī)劃和監(jiān)控自愈響應(yīng)有定要求。因?yàn)樯鲜鎏攸c(diǎn)在Kubernetes集群節(jié)點(diǎn)容量規(guī)劃上，應(yīng)保持節(jié)點(diǎn)配置和節(jié)點(diǎn)規(guī)模的平衡。下文將具體闡述主要組件的規(guī)劃思路。2Master節(jié)點(diǎn)性能設(shè)計(jì)2.1

4、 Master節(jié)點(diǎn)架構(gòu)和容量設(shè)計(jì)Master節(jié)點(diǎn)通過(guò)staticpod啟動(dòng)APIServer、ControllerManager、Scheduler等控制服務(wù)，以及ETCD分布式數(shù)據(jù)庫(kù)。后者是CoreOS基千Raft協(xié)議開(kāi)源的分布式key-value存儲(chǔ)，可用千服務(wù)發(fā)現(xiàn)、共享配置以及致性保障（如數(shù)據(jù)庫(kù)選主、分布式鎖等）。在這里用千存儲(chǔ)KubernetesAPIServer所接收的A回對(duì)象。對(duì)千Master的容量設(shè)計(jì)主要包括如下幾點(diǎn)1節(jié)點(diǎn)和服務(wù)高可用。關(guān)千這點(diǎn)Kubernetes本身高可用部署架構(gòu)就涉及。建議至少3臺(tái)Master節(jié)點(diǎn)。同時(shí)通過(guò)設(shè)置污點(diǎn)節(jié)點(diǎn)親和性的方式，避免應(yīng)用容器調(diào)度到Maste

5、r上。參考下圖Master節(jié)點(diǎn)架構(gòu)，Master上主要涉及kube-apiserv­er、kube-controller-manager與kube-scheduler幾個(gè)服務(wù)。kube-apiserver由千服務(wù)本身無(wú)狀態(tài)，需要確保通過(guò)負(fù)載均衡實(shí)現(xiàn)訪問(wèn)APIServer多實(shí)例的高可用訪問(wèn)。kubecontrollermanager與kubescheduler:田千這兩個(gè)服務(wù)般使用單主節(jié)點(diǎn)active,多個(gè)從節(jié)點(diǎn)standy的模式運(yùn)行。其內(nèi)部會(huì)使用鎖爭(zhēng)用方式確認(rèn)主節(jié)點(diǎn)，其余節(jié)點(diǎn)處千standy狀態(tài)。直到主節(jié)點(diǎn)發(fā)生異室鎖失效后被其他節(jié)點(diǎn)爭(zhēng)用代替（在后續(xù)開(kāi)發(fā)方案設(shè)計(jì)的文章中會(huì)涉及實(shí)現(xiàn)方法）

6、。2.ETCD本身需要高可用部署，建議至少3個(gè)節(jié)點(diǎn)，根據(jù)實(shí)際性能情況可以和Master并運(yùn)行或獨(dú)立部署。官方使用kubeadm部署的方案參考https:/kubemete.sio/docs/setup/productionenvironmen/ttools/kubeadm/setuphaetcdwithkubeadm/。物理硬件上，田千ETCD其高度依賴存儲(chǔ)和網(wǎng)絡(luò)，建議使用SSD等高IOPS存儲(chǔ)方案并確保ETCD集群之間以及APIServer訪問(wèn)ETCD網(wǎng)絡(luò)條件良好。另方面，ETCD也涉及客戶端和服務(wù)器優(yōu)化，這部分在下節(jié)再進(jìn)行討論。通常來(lái)說(shuō)Master節(jié)點(diǎn)的性能與ETCD相關(guān)，與集群中A回對(duì)象

7、的讀寫(xiě)頻率成正比。若集群節(jié)點(diǎn)數(shù)量穩(wěn)定總體而言其TPS和IOPS還是趨于穩(wěn)定的。因此建議采用合理計(jì)算資掠的高配詈方案搭建集群。2.2 Master節(jié)點(diǎn)監(jiān)控和性能調(diào)優(yōu)2.2.1 Master性能調(diào)優(yōu)確保ETCD使用3.X版本并且使用V3存儲(chǔ)模式根據(jù)ETCD官方說(shuō)明，3.x版本引入可伸縮性和性能改進(jìn)，可減少任何大小群集的CPU、內(nèi)存、網(wǎng)絡(luò)和磁盤(pán)需求，從ETCD2升級(jí)到ETCD3,APIServer的IOPS/CPU改善超過(guò)50%。根據(jù)Kubernetes版本說(shuō)明，1.5.1版本后開(kāi)始支持ETCD3,1.13廢除了ETCD2的支持。Master節(jié)點(diǎn)OS參數(shù)優(yōu)化selinuxavecachethresh

8、old=8192netnf_conntrack_hashsize=l31072sysctlnet.ipv4.ip_forward=1kernel.pid_max=>131072filter.nf_conntrack_max=1048576net.ipv4.neigh.default.gc_thresh1=8192net.ipv4.neigh.default.gc_thresh2=32768net.ipv4.neigh.default.gc_thresh3=65536net.ipv6.neigh.default.gc_thresh1=8192net.ipv6.neigh.default.g

9、c_thresh2=32768net.ipv6.neigh.default.gc_thresh3=65536kernel.sched_min_granularity_ns=lOOOOOOOkernel.sched_migration_cost_ns=SOOOOOOkernel.sched_wakeup_granularity_ns=4000000sysfs/sys/module/nvme_core/parameters/io_timeout=4294967295/sys/module/nvme_core/parameters/max_retries=lOETCD服務(wù)端客戶端優(yōu)化ETCD由千對(duì)存

10、儲(chǔ)性能依賴較大。通?？梢酝ㄟ^(guò)服務(wù)器端客戶端進(jìn)行性能優(yōu)化。關(guān)千服務(wù)器端存儲(chǔ)優(yōu)化阿里云實(shí)現(xiàn)了ETCDfreelist分配回收算法，具體參考cf.io/blog/2019/05/09/performanceoptimizationofetcd|nwebscaledatascenario/。關(guān)千客戶端性能優(yōu)化，核心在千控制及優(yōu)化對(duì)APIServer的對(duì)象讀寫(xiě)。由千Kubernetes支持CRD擴(kuò)展API資源對(duì)象，因此在CRD對(duì)象Controller設(shè)計(jì)上應(yīng)盡可能精簡(jiǎn)避免大對(duì)象的頻繁讀寫(xiě)變化。2.2.2 Master相關(guān)監(jiān)控指標(biāo)建議CPU<80%Mem<80%磁盤(pán)分區(qū)使用率<80%10

11、使用率<90%網(wǎng)卡流量使用率<50%(A-A網(wǎng)卡）主機(jī)可用性外部主機(jī)可用性監(jiān)控監(jiān)控服務(wù)可用性（通過(guò)Prometheus)99%APIServer請(qǐng)求延時(shí)4秒Kubeclient訪問(wèn)錯(cuò)誤率5%APIServer證書(shū)過(guò)期<7天APIServerDown>lCPU/MemovercommitNode不可用Nodeexporter不可用預(yù)測(cè)磁盤(pán)滿<1天Node中磁盤(pán)10>90%Pod無(wú)法啟動(dòng)（重啟失敗）Pod狀態(tài)不readyPodCPU/Mem使用率3Infra節(jié)點(diǎn)性能設(shè)計(jì)主要包含以下幾類業(yè)務(wù)無(wú)關(guān)的平臺(tái)服務(wù)日志服務(wù)、監(jiān)控服務(wù)和外部流量路由服務(wù)。3.1 EFK架構(gòu)和容

12、量Kubernetes本身支持多種日志收集方案，思路上可分為應(yīng)用直接寫(xiě)Elasticsearch日志。應(yīng)用通過(guò)emptydir等形式將日志輸出在Pod中，再通過(guò)Sidecar容器讀取日志寫(xiě)入Elasticsearch。應(yīng)用將日志輸出在Docker標(biāo)準(zhǔn)輸出再通過(guò)平臺(tái)方案寫(xiě)入Elasticsearch。當(dāng)今比較流行的方案是最后這個(gè)，通過(guò)Elasticsearch,Fluentd和Kibana(EFK)技術(shù)棧實(shí)現(xiàn)。其方案的具體思路是通過(guò)DaemonSet在需要收集日志的各個(gè)節(jié)點(diǎn)上運(yùn)行fluentd的容器，后者掛載每個(gè)節(jié)點(diǎn)宿主機(jī)的Docker日志目錄（如var/log和var/lib/docker/c

13、ontainer)。這樣當(dāng)該節(jié)點(diǎn)的容器寫(xiě)入Docker日志后就會(huì)被fluentd捕獲，最終寫(xiě)入Elasticsearch。這樣用戶通過(guò)灼bana即可查詢指定Pod日志。此方案需要應(yīng)用將日志重定向到標(biāo)準(zhǔn)輸出，以便Dockerlog捕獲。值得注意的是，由千EFK堆棧通過(guò)Fluentd將日志搬運(yùn)至Elasticsearch的數(shù)據(jù)是不斷累積的，故需要注意下列配置來(lái)保證集群可用·Fluentd容量Fluentd的作用主要是將計(jì)算節(jié)點(diǎn)宿主機(jī)日志讀取后放入本地Buffer,再異步發(fā)送給遠(yuǎn)端Elasticsearch。因此當(dāng)遠(yuǎn)端無(wú)法及時(shí)寫(xiě)入數(shù)據(jù)或本地產(chǎn)生日志過(guò)多遠(yuǎn)端無(wú)法及時(shí)消化時(shí)，F(xiàn)luentd默認(rèn)

14、本地會(huì)產(chǎn)生overflow報(bào)錯(cuò)并丟棄舊的日志。因此需要合理調(diào)整配置中chunklim凡size大小。1. <match*>2. idelasticsearch3. typeelasticsearch4. log_levelinfo5. type_name_doc6. include_tag_keytrue7. 8. port92009. userelastic10. passwordelastic11. logstash_formattrue12. <buffer>13. typefile14. path/var/log/fluentd-buffers/kubernet

15、es.system.buffer15. 于lushmodeinterval16.17. chunklimitsize20M18. overflowactionblock19. </buffer>20. </match>Elasticsearch高可用Elasticsearch部署需要注意以下幾點(diǎn)1 由千Elasticsearch對(duì)千存儲(chǔ)依賴較高，般使用本地存儲(chǔ)或基千LocalVolume的PV持久化，并使用StatefulSet啟動(dòng)多節(jié)點(diǎn)實(shí)現(xiàn)高可用。因此Elasticsearch應(yīng)用建議啟動(dòng)在Kubernetes集群固定獨(dú)占節(jié)點(diǎn)上，禁止業(yè)務(wù)容器調(diào)度。2 作為Kubern

16、etes集群的日志查詢服務(wù)，其對(duì)計(jì)算資源高度依賴。故建議使用少數(shù)節(jié)點(diǎn)高配置部署方案。節(jié)點(diǎn)數(shù)量至少為3臺(tái)。3 為了避免主節(jié)點(diǎn)腦裂，需要設(shè)置discover.zen.minimum_master_nodes節(jié)點(diǎn)數(shù)量2+1。4 由千Elasticsearch存儲(chǔ)的日志是根據(jù)Namespace和日期單獨(dú)存儲(chǔ)。故需要定義日志存儲(chǔ)時(shí)間，避免存儲(chǔ)空間不足。可以通過(guò)CronJob定期根據(jù)Namespace和日期清理歷史日志存儲(chǔ)。3.2 EFK監(jiān)控和調(diào)優(yōu)日志節(jié)點(diǎn)OS參數(shù)優(yōu)化selinuxavecachethreshold=8192netnfconntrackhashsize=131072sysctlnet.ip

17、v4.ip_forward=1kernel.pid_max=>131072filter.nfconntrackmax=1048576net.ipv4.neigh.default.gc_thresh1=8192net.ipv4.neigh.default.gc_thresh2=32768net.ipv4.neigh.default.gc_thresh3=65536net.ipv6.neigh.default.gc_thresh1=8192net.ipv6.neigh.default.gc_thresh2=32768net.ipv6.neigh.default.gc_thresh3=6553

18、6net.ipv4.tcp_fastopen=3fs.file-max=655350fs.inotify.max_user_watches=65536vm.max_map_count=262144sysfs/sys/module/nvme_core/parameters/io_timeout=4294967295/sys/module/nvme_core/parameters/max_retries=10日志節(jié)點(diǎn)監(jiān)控指標(biāo)CPU<80%Mem<80%磁盤(pán)分區(qū)使用率<80%10使用率<90%網(wǎng)卡流量使用率<50%(A-A網(wǎng)卡）主機(jī)可用性外部主機(jī)可用性監(jiān)控監(jiān)控服務(wù)可用性

19、（通過(guò)Prometheus)PV剩余空間<3%CPU/Memovercommit預(yù)測(cè)磁盤(pán)滿<1天Node中磁盤(pán)10>90%Pod無(wú)法啟動(dòng)（重啟失敗）Pod狀態(tài)不readyPodCPU/Mem使用率Cluster/Node/Index狀態(tài)（通過(guò)ESexporter)3.3 Prometheus架構(gòu)和容量傳統(tǒng)對(duì)于IT系統(tǒng)的監(jiān)控，思路上會(huì)有三種實(shí)現(xiàn)方式通過(guò)日志、通過(guò)探針和通過(guò)數(shù)據(jù)上報(bào)度量。基千日志的監(jiān)控方案典型的方案就是通過(guò)ELK/EFK。應(yīng)用層將相關(guān)監(jiān)控K回以日志形式進(jìn)行記錄，通過(guò)應(yīng)用層或平臺(tái)層輸出最終匯聚到Elasticsearch。后者通過(guò)可以通過(guò)定期查詢獲取對(duì)應(yīng)的監(jiān)控指標(biāo)，

20、或者輸出報(bào)警?；结樀谋O(jiān)控方案典型的方案就是JavaSpringCloud體系使用zipkinsleuth。其原理是通過(guò)Spring的APO在業(yè)務(wù)請(qǐng)求的兩端進(jìn)行攔截，實(shí)現(xiàn)用千標(biāo)記請(qǐng)求的TraceID和標(biāo)記最小處理單元的SpanID等信息的注入，以此來(lái)跟蹤整個(gè)微服務(wù)調(diào)用鏈。基千度量褽合的監(jiān)控方案Kubernetes默認(rèn)使用的Prometheus就是采用這個(gè)方案。基千時(shí)序數(shù)據(jù)庫(kù)，通過(guò)內(nèi)置或外掛的exporter主動(dòng)或被動(dòng)獲取段時(shí)間的監(jiān)控?cái)?shù)據(jù)，然后再通過(guò)聚合運(yùn)算，最終實(shí)現(xiàn)監(jiān)控指標(biāo)展示和趨勢(shì)預(yù)測(cè)。但同時(shí)也應(yīng)該注意到，由千度量KPI在設(shè)計(jì)上就放棄了部分?jǐn)?shù)據(jù)準(zhǔn)確性（如定義采集周期是5min,勢(shì)必會(huì)忽略其

21、中部分尖峰KPI),Prometheus針對(duì)某些強(qiáng)精準(zhǔn)性的監(jiān)控場(chǎng)景未必適用，這個(gè)需要在定義具體監(jiān)控方案時(shí)識(shí)別到。Prometheus包含以下關(guān)鍵組件：PrometheusServer用千收集和存儲(chǔ)時(shí)序數(shù)據(jù)，負(fù)責(zé)監(jiān)控?cái)?shù)據(jù)的獲取存儲(chǔ)以及查詢。監(jiān)控目標(biāo)配置PrometheusServer可以靜態(tài)配置定義監(jiān)控目標(biāo)的exporter,同時(shí)也支持通過(guò)服務(wù)發(fā)現(xiàn)（基千Kuberne­tes,DNS或Consul)來(lái)實(shí)現(xiàn)動(dòng)態(tài)管理監(jiān)控目標(biāo)。目前Kubernetes社區(qū)巳經(jīng)實(shí)現(xiàn)通過(guò)定義CRD擴(kuò)展(監(jiān)控?cái)?shù)據(jù)查詢方案PrometheusServer通過(guò)實(shí)現(xiàn)PromQL語(yǔ)言來(lái)對(duì)監(jiān)控?cái)?shù)據(jù)進(jìn)行查詢以及分析。般Kub

22、ernetes集成Prometheus主要有幾個(gè)思路：1采用原生PrometheusUI并自定義個(gè)sidecar容器，通過(guò)注入sidecar來(lái)實(shí)現(xiàn)查詢權(quán)限管理。2.基千Grafana定義查詢U|?？蛻舳吮O(jiān)控輸出。應(yīng)用將監(jiān)控指標(biāo)輸出給Prometheus主要有幾個(gè)思路：1. ClientSDK。為需要監(jiān)控的應(yīng)用服務(wù)生成相應(yīng)的Metrics并暴露給PrometheusServer。當(dāng)PrometheusServer來(lái)Pull時(shí)，直接返回實(shí)時(shí)狀態(tài)的Metrics。2. PushGateway。主要用千不適合長(zhǎng)期存在的短期Jobs等應(yīng)用。通過(guò)主動(dòng)Push將數(shù)據(jù)發(fā)送給Gateway。后者會(huì)暴露Metri

23、cs被Prometheus拉取。3自定義Exporters。通過(guò)ClientSOK額外開(kāi)發(fā)程序，用千使用應(yīng)用層私有協(xié)議等方法從被監(jiān)控目標(biāo)獲取指定K回再暴露Metrics給Prometheus。Alertmanager,出千報(bào)警信息的冗余性考慮，從PrometheusServer端接收到Alerts后，Alertmanager集群會(huì)對(duì)數(shù)據(jù)進(jìn)行去重、分組等處理，然后根據(jù)規(guī)則，觸發(fā)報(bào)警。包括原生支持的郵件、微信或自定義WebHook。架構(gòu)上田于作為容器云的核心監(jiān)控方案，需要確保自身的高可：用PrometheusPrometheus本身不支持高可用和數(shù)據(jù)分片，架構(gòu)上實(shí)現(xiàn)高可用般有2個(gè)思路。1. 冗余的

24、高可用。至少需要2個(gè)節(jié)點(diǎn)保持相同的配置和監(jiān)控目標(biāo)。各自獨(dú)立運(yùn)行進(jìn)行數(shù)據(jù)監(jiān)控?cái)?shù)據(jù)采集，并通過(guò)網(wǎng)絡(luò)等負(fù)載均衡實(shí)現(xiàn)請(qǐng)求高可用分發(fā)。需要注意的是，由千每個(gè)實(shí)例完全獨(dú)立運(yùn)行，即使配置相同也可能因?yàn)楂@取數(shù)據(jù)時(shí)間的微小差異而導(dǎo)致存儲(chǔ)的監(jiān)控?cái)?shù)據(jù)有差異。因此建議使用session粘連方式進(jìn)行負(fù)載均衡。對(duì)千Kubernetes而言需要在Service中使用sessionAffinity。同時(shí)作為最常見(jiàn)和簡(jiǎn)單的部署方案，為了避免自身出現(xiàn)監(jiān)控問(wèn)題，建議生產(chǎn)上使用2個(gè)集群的交叉監(jiān)控確保Prometheus平臺(tái)本身可用性。2. 遠(yuǎn)程存儲(chǔ)聯(lián)邦集群方案。目前開(kāi)源項(xiàng)目thanos(AlertmanagerAlertmanage

25、r基于Gossip協(xié)議實(shí)現(xiàn)高可用，避免同時(shí)獲取多個(gè)Prometheus節(jié)點(diǎn)的告警數(shù)據(jù)，因此器要至少3個(gè)節(jié)點(diǎn)保持集群穩(wěn)定。另外，針對(duì)Alertmanager監(jiān)控可以基千其自帶的Deadmanswitch進(jìn)行開(kāi)發(fā)擴(kuò)展。后者Deadmanswitch是Prometheus自帶的靜默報(bào)警測(cè)試，會(huì)直不斷觸發(fā)報(bào)警直到Prometheus或Alertmanager集群自身不可用當(dāng)然這個(gè)報(bào)警默認(rèn)是被忽略的。部署方案上針對(duì)PrometheusServer的持久化，根據(jù)Prometheus社區(qū)官方的說(shuō)明(ServiceMonitor、AlertManager以及PrometheusRule4個(gè)CRD對(duì)象來(lái)創(chuàng)建集群

26、。這樣針對(duì)監(jiān)控目標(biāo)的調(diào)整可直接通過(guò)CRD進(jìn)行，相關(guān)OperatorController會(huì)自動(dòng)刷新Prometheus對(duì)應(yīng)的配置規(guī)則。需要額外注意的是，當(dāng)前版本的prometheusoperator代碼將針對(duì)Kubernetes的監(jiān)控規(guī)則以binary形式編譯在operator程序中。因此除非調(diào)整代碼，外部無(wú)法通過(guò)環(huán)境變量或配置注入的方式更新這部分規(guī)則。不過(guò)可以通過(guò)Alertmanager禁用報(bào)警并且額外建立其他監(jiān)控規(guī)則的方式繞過(guò)。物理部署上同樣建議啟動(dòng)在Kubernetes集群固定獨(dú)占節(jié)點(diǎn)上，使用少數(shù)節(jié)點(diǎn)高配詈部署方案，禁止業(yè)務(wù)容器調(diào)度。整體節(jié)點(diǎn)數(shù)量至少為3臺(tái)。具體容量參考如下Pod數(shù)噩Pro

27、metheus每日增長(zhǎng)內(nèi)存網(wǎng)絡(luò)18006.3G6G16M360013GlOG26M540019G12G36M720025G14G46M3.4 Prometheus監(jiān)控和調(diào)優(yōu)日志節(jié)點(diǎn)OS參數(shù)優(yōu)化selinuxavecachethreshold=8192netnfconntrackhashsize=131072sysctlnet.ipv4.ip_forward=1kernel.pid_max=>l31072filter.nfconntrackmax=1048576net.ipv4.neigh.default.gc_thresh1=8192net.ipv4.neigh.default.gc_t

28、hresh2=32768net.ipv4.neigh.default.gc_thresh3=65536net.ipv6.neigh.default.gc_thresh1=8192net.ipv6.neigh.default.gc_thresh2=32768net.ipv6.neigh.default.gc_thresh3=65536net.ipv4.tcp_fastopen=3fs.file-max=655350fs.inotify.max_user_watches=65536sysfs/sys/module/nvme_core/parameters/io_timeout=4294967295

29、/sys/module/nvme_core/parameters/max_retries=lO監(jiān)控節(jié)點(diǎn)監(jiān)控指標(biāo)CPU<80%Mem<80%磁盤(pán)分區(qū)使用率<80%10使用率<90%網(wǎng)卡流量使用率<50%(A-A網(wǎng)卡）主機(jī)可用性外部主機(jī)可用性監(jiān)控監(jiān)控服務(wù)可用性（通過(guò)Prometheus)PV剩余空間<3%CPU/Memovercommit預(yù)測(cè)磁盤(pán)滿<1天Node中磁盤(pán)10>90%Prometheus不可用（通過(guò)AlertManager)AlertManager配置異常AlertManager服務(wù)不可用(Deadmanswitch)Prometheus

30、ob不可用Pod無(wú)法啟動(dòng)（重啟失?。㏄od狀態(tài)不readyCPU/Mem使用率3.5 Ingress架構(gòu)和容量在Kubernetes集群中，Ingress是組路由規(guī)則，用于對(duì)集群的入站訪問(wèn)提供7層服務(wù)器負(fù)載均衡功能。個(gè)Ingress可以配置用千提供外部可訪問(wèn)的服務(wù)url上下文負(fù)載均衡流量SSL證書(shū)裝載和域名流量綁定配置。不同廠商通過(guò)不同產(chǎn)品實(shí)現(xiàn)IngressController來(lái)滿足Ingress功能，包括常用的Nginx(Kubernetes官方清單(https:/kubemetes.io/docs/concepts/servicesnetworking/ingresscontrollers

31、/)。本章以使用最多的NginxIngressController做進(jìn)步介紹。田于IngressController本身基千Deployment安裝，遇到性能問(wèn)題時(shí)可以比較方便進(jìn)行手工或自動(dòng)的彈性伸縮，但仍然需要注意下列問(wèn)題·獨(dú)占部署。物理部署上建議啟動(dòng)在Kubernetes集群固定獨(dú)占節(jié)點(diǎn)上，使用少數(shù)節(jié)點(diǎn)高配置部署方案，至少使用獨(dú)立2個(gè)節(jié)點(diǎn)實(shí)現(xiàn)物理上高可用。禁止業(yè)務(wù)容器調(diào)度并使用DaemonSet部署。具體容量參考Nginx官方的RPS性能測(cè)試來(lái)刑大蘭二HTTPHTTPS請(qǐng)求大小1K1K2Core74,19258,0414Core148,936117,2558Core300,625

32、236,70316Core342,651341,232配置優(yōu)化和普通nginx類似，針對(duì)高并發(fā)場(chǎng)景需要額外進(jìn)行優(yōu)化。主要涉及HTTP會(huì)話保持是否使用HTTPS、TLS會(huì)話恢復(fù)單POD請(qǐng)求分?jǐn)偤侠砩蠈泳W(wǎng)絡(luò)優(yōu)化、后端應(yīng)用請(qǐng)求大小優(yōu)化等。具體參考Kubernetes官方建議(https:/kubernetes.github.io八ngressnginx/userguide/nginxcon廿guration/conflgmap/)，需要在Conflgmap中調(diào)整如下等參數(shù):keepalive、keepaliverequests、keepalivetimeout。3.6 Ingress監(jiān)控和調(diào)優(yōu)日志節(jié)

33、點(diǎn)OS參數(shù)優(yōu)化selinuxavecachethreshold=8192netnfconntrackhashsize=131072sysctlnet.ipv4.ip_forward=1kernel.pid_max=>131072filter.nf_conntrack_max=1048576net.ipv4.neigh.default.gc_thresh1=8192net.ipv4.neigh.default.gc_thresh2=32768net.ipv4.neigh.default.gc_thresh3=65536net.ipv6.neigh.default.gc_thresh1=81

34、92net.ipv6.neigh.default.gc_thresh2=32768net.ipv6.neigh.default.gc_thresh3=65536net.ipv4.tcp_fastopen=3fs.file-max=655350fs.inotify.max_user_watches=65536sysfs/sys/module/nvme_core/parameters/io_timeout=4294967295/sys/module/nvme_core/parameters/max_retries=lO監(jiān)控節(jié)點(diǎn)監(jiān)控指標(biāo)CPU<80%Mem<80%磁盤(pán)分區(qū)使用率<8

35、0%10使用率<90%網(wǎng)卡流量使用率<50%(A-A網(wǎng)卡）主機(jī)可用性外部主機(jī)可用性監(jiān)控監(jiān)控服務(wù)可用性（通過(guò)Prometheus)CPU/Memovercommit預(yù)測(cè)磁盤(pán)滿<1天Node中磁盤(pán)10>90%Pod無(wú)法啟動(dòng)（重啟失?。㏄od狀態(tài)不readyCPU/Mem使用率4應(yīng)用節(jié)點(diǎn)規(guī)劃和調(diào)整4.1 計(jì)算節(jié)點(diǎn)架構(gòu)和容量與Infra節(jié)點(diǎn)類似，Kubernetes計(jì)算節(jié)點(diǎn)也需要做定容量規(guī)劃，避免集群過(guò)載。同時(shí)，針對(duì)部分組件特性需要有的放矢，這里主要介紹CPUManager和不同存儲(chǔ)方案的使用場(chǎng)景。4.1.1 容量規(guī)劃Node數(shù)量節(jié)點(diǎn)數(shù)量應(yīng)不大于5000。但官方文檔建議不同數(shù)量

36、Node對(duì)Master節(jié)點(diǎn)性能有額外性能要求。節(jié)點(diǎn)數(shù)量CPUCore數(shù)量1-516-10211-1004101-2508250-50016>50032Pod數(shù)量單節(jié)點(diǎn)Pod數(shù)量不超過(guò)100個(gè)，總數(shù)量不超過(guò)150000個(gè)。Namespace數(shù)量由千Namespace數(shù)量過(guò)多會(huì)導(dǎo)致ETCD性能下降，建議不超過(guò)10000個(gè)。每個(gè)Namespace中對(duì)象數(shù)量由千大量Controller會(huì)實(shí)現(xiàn)Pod控制循環(huán)，故建議每個(gè)NamespacePod數(shù)量不超過(guò)25000個(gè)。Deployment等部署對(duì)象數(shù)量不超過(guò)2000個(gè)。Service數(shù)量由千Service在Kubernetes實(shí)現(xiàn)依賴千lptable

37、規(guī)則，故數(shù)量建議不超過(guò)10000個(gè)。4.1.2 CPUManager默認(rèn)kubelet使用CFS配額來(lái)執(zhí)行Pod對(duì)CPU約束。正室Pod的CPU工作負(fù)載可能會(huì)由千其QoS等原因被分配到不同的CPUCore中。這通室般對(duì)工作負(fù)載不敏感的應(yīng)用未必能感受出明顯的差異，但是如果Pod中的應(yīng)用是CPU密集型的，有些工作負(fù)載的性能明顯地受到CPU緩存親和性以及調(diào)度延遲的影響。對(duì)此，kubelet提供了可選的CPUManager策略，來(lái)確定節(jié)點(diǎn)上的些分配倌好。None策略None策略顯式地啟用現(xiàn)有的默認(rèn)CPU親和方案，不提供操作系統(tǒng)調(diào)度器默認(rèn)行為之外的親和性策略。通過(guò)CFS配額來(lái)實(shí)現(xiàn)Guaranteedpo

38、ds的CPU使用限制。Static策略Static策略針對(duì)具有整數(shù)型CPUrequests的Guaranteedpod,它允許該類pod中的容器訪問(wèn)節(jié)點(diǎn)上的獨(dú)占CPU資源。這種獨(dú)占性是使用cpusetcgroup控制器來(lái)實(shí)現(xiàn)的。需要額外注意的是，由千獨(dú)占資源可能會(huì)導(dǎo)致該節(jié)點(diǎn)平臺(tái)級(jí)容器無(wú)法獲取CPU調(diào)度，因此在kubelet中需要額外添加kubereserved/systemreserved/reservedcpus參數(shù)保留平臺(tái)計(jì)算資源。另方面，若Kubernetes集群同時(shí)包含CPU密集型和CPU非密集型應(yīng)用，建議使用節(jié)點(diǎn)親和性進(jìn)行隔離。4.1.3 存儲(chǔ)Kubernetes雖然支持基千Stor

39、ageClass和CS的存儲(chǔ)接口實(shí)現(xiàn)，但物理存儲(chǔ)歸根結(jié)底分為以下三類塊存儲(chǔ)即傳統(tǒng)的SAN存儲(chǔ)作為塊設(shè)備呈現(xiàn)給操作系統(tǒng)。適用千使用方需要完全控制存儲(chǔ)文件系統(tǒng)的場(chǎng)景。本身不可共享。般云平臺(tái)（如Vmware等）通過(guò)實(shí)現(xiàn)CSI接口以提供容器平臺(tái)PVprovision。文件存儲(chǔ)即傳統(tǒng)的NAS存儲(chǔ)作為NFS端點(diǎn)由下層操作系統(tǒng)或軟件導(dǎo)出。通過(guò)手工建立NFSPV或?qū)崿F(xiàn)NFSStor­ageClass可提供基千NAS的PV。對(duì)象存儲(chǔ)即通過(guò)RESTfulA回訪問(wèn)的文件存儲(chǔ)。般需要應(yīng)用或平臺(tái)層驅(qū)動(dòng)支持方可作為抽象文件系統(tǒng)使用，否則需要直接通過(guò)RESTful操作文件。AWSS3是個(gè)典型的實(shí)現(xiàn)。不同類型存儲(chǔ)使

40、用的場(chǎng)景參考如下：存儲(chǔ)類型讀寫(xiě)類型PrometheusElasticsearchRegistry應(yīng)用塊存儲(chǔ)ROX建議建議不可實(shí)現(xiàn)建議文件存儲(chǔ)ROX/RWX可實(shí)現(xiàn)但避免可實(shí)現(xiàn)可實(shí)現(xiàn)建議對(duì)象存儲(chǔ)ROX/RWX不可實(shí)現(xiàn)不可實(shí)現(xiàn)建議（取決產(chǎn)品）不可實(shí)現(xiàn)4.2 計(jì)算節(jié)點(diǎn)監(jiān)控和性能調(diào)優(yōu)日志節(jié)點(diǎn)OS參數(shù)優(yōu)化selinuxavecachethreshold=8192netnfconntrackhashsize=131072sysctlnet.ipv4.ip_forward=1kernel.pid_max=>131072filter.nfconntrackmax=l048576net.ipv4.neigh

41、.default.gc_thresh1=8192net.ipv4.neigh.default.gc_thresh2=32768net.ipv4.neigh.default.gc_thresh3=65536net.ipv6.neigh.default.gc_thresh1=8192net.ipv6.neigh.default.gc_thresh2=32768net.ipv6.neigh.default.gc_thresh3=65536net.ipv4.tcp_fastopen=3fs.file-max=655350fs.inotify.max_user_watches=65536sysfs/sy

42、s/module/nvme_core/parameters/io_timeout=4294967295/sys/module/nvme_core/parameters/max_retries=lO監(jiān)控節(jié)點(diǎn)監(jiān)控指標(biāo)CPU<80%Mem<80%磁盤(pán)分區(qū)使用率<80%10使用率<90%網(wǎng)卡流量使用率<50%(A-A網(wǎng)卡）主機(jī)可用性外部主機(jī)可用性監(jiān)控監(jiān)控服務(wù)可用性（通過(guò)Prometheus)單節(jié)點(diǎn)Pod數(shù)量250PV剩余空間<3%CPU/MemovercommitNode不可用Nodeexporter不可用預(yù)測(cè)磁盤(pán)滿<1天Node中磁盤(pán)10>90%Pod

43、無(wú)法啟動(dòng)（重啟失敗）Pod狀態(tài)不readyCPU/Mem使用率應(yīng)用自定義指標(biāo)（如直接實(shí)現(xiàn)Metrics、JavaJMXexporter等第三方擴(kuò)展等）4.3 應(yīng)用規(guī)劃4.3.1 應(yīng)用資源依賴通室個(gè)容器化應(yīng)用部署，勢(shì)必會(huì)對(duì)周邊產(chǎn)生依賴。本章節(jié)將列舉室見(jiàn)的幾個(gè)依賴：計(jì)算資源依賴通室Pod需要定義QoS以便聲明合理地獨(dú)占或共享計(jì)算資源。Kubernetes默認(rèn)支持Pod對(duì)CPU和Mem資源進(jìn)行定義。其中requests關(guān)鍵字定義的是Pod所需的最小資源量。例如應(yīng)用啟動(dòng)依賴的內(nèi)容如果大千512M,但requests設(shè)詈為512M,它可能將無(wú)法啟動(dòng)。而limits關(guān)鍵字限制定義了你需要為給定Pod提供的

44、最大資源量。同時(shí)通過(guò)實(shí)現(xiàn)Deviceplugin,Kubernetes可支持第三方硬件（如GPU)調(diào)度。具體QoS說(shuō)明如下·另外，Kubernetes1.11版本后還支持通過(guò)定義和orityClass來(lái)聲明Pod的調(diào)度優(yōu)先級(jí)，這樣當(dāng)資源不足時(shí)優(yōu)先級(jí)低的Pod就會(huì)被優(yōu)先驅(qū)離。1. apiVersion:scheduling.k8s.io/vl2. kind:PriorityClass3. metadata:4. name:high-priority5. value:10006.-7. apiVersion:vl8. kind:Pod9. metadata:10. name:mypod1

45、1. spec:12. containers13. -miage:redis14 .name:mycontainer15 .priorityClassName:high-priority存儲(chǔ)依賴通常Pod中存儲(chǔ)主要涉及三類，包括Pod本身、emptyDir和PersistentVolumes持久卷（這里暫將Loca|Path記為以PV形式暴露）。需要注意，Pod容器本身存儲(chǔ)大小由dockerdevicemapper限制（默認(rèn)10G)，應(yīng)用若超出這個(gè)數(shù)值可能導(dǎo)致容器應(yīng)用異常。emptyDir可以通過(guò)對(duì)ephemeraI-storage的request和limit限制大小，如果超出設(shè)置數(shù)值容器可能

46、會(huì)被驅(qū)離。1.apiVersion:vl2.kind:Pod3.metadata4. name:frontend5. spec:6. containers:7. -name:db8. image:mysql9. env10.-name:MYSQL_ROOT_PASSWORD11.value:"password"12 .resources:13 .requests:14.ephemeral-storage:"2Gi"15.limits:16.ephemeral-storage:"4Gi"17.-name:wp18 .image:word

47、press19 .resources:20. .requests:21. ephemeral-storage:"2Gi"22. .limits:23. .ephemeral-storage:"4Gi"使用PV需要取人持久卷是否可以隨著計(jì)算節(jié)點(diǎn)遷移，否則需要通過(guò)計(jì)算節(jié)點(diǎn)親和性避免容器重新調(diào)度到其他節(jié)點(diǎn)后無(wú)法訪問(wèn)持久卷或持久卷丟失的情況。下圖就是個(gè)基千localpath的本地存儲(chǔ)，應(yīng)進(jìn)行親和性規(guī)避。1. apiVersion:vl2. kind:PersistentVolmueClaim3. metadata:4. name:my-pvc5. spec6.

48、storageClassName:local7. accessModes:8. -ReadWriteonce9. resources:10. requests:11. storage:100Mi12.-13. apiVersion:vl14. kind:Pod15.metadata:16.name:pvc-example17. spec:18. containers·19.-miage::pvc-examplemand:'sh','-c','sleep10000'22.volmueMounts:23. .-mo

49、untPath:"/data"24. .name:my-vol25.26. .volmues:27. .-name:my-vol28. .persistentVolumeClaim:29. claimName:my-pvc上層依賴需要確認(rèn)應(yīng)用是否對(duì)外有額外依賴或約束。例如應(yīng)用使用Ingress泰露服務(wù)時(shí)對(duì)所綁定的域名有約束、通過(guò)NodePort暴露時(shí)對(duì)VIP和端口有約束，或是使用HostPort暴露時(shí)對(duì)綁定的宿主機(jī)IP和端口有約束。4.3.2 應(yīng)用配置優(yōu)化對(duì)千高負(fù)載應(yīng)用，如果直接使用水平伸縮HorizontalPodAutoscale,隨著應(yīng)用的自動(dòng)擴(kuò)容和收縮，往往發(fā)現(xiàn)期間

50、會(huì)有部分請(qǐng)求出現(xiàn)錯(cuò)誤和中斷。這Kubelet和刪除Pod原理有關(guān)，其正室是步驟是1如果收到個(gè)請(qǐng)求來(lái)刪除Pod,默認(rèn)的優(yōu)雅退出時(shí)間是30秒。超過(guò)該時(shí)間Pod被認(rèn)為死亡，其顯示狀態(tài)為Terminating。2. 當(dāng)Kubelet發(fā)現(xiàn)Pod標(biāo)記為退出中的時(shí)候，開(kāi)始pod關(guān)閉的流程。3. 如果該P(yáng)od定義了個(gè)停止前的鉤子preStop,其會(huì)在pod內(nèi)部被調(diào)用。如果鉤子在優(yōu)雅退出時(shí)間段超時(shí)仍然在運(yùn)行，第二步會(huì)有個(gè)很小的優(yōu)雅時(shí)間斷被調(diào)用。隨后進(jìn)程被發(fā)送TERM的信號(hào)。4 與此同時(shí)，Pod對(duì)應(yīng)的Endpoint對(duì)象會(huì)從Service的列表中被刪除，但緩慢關(guān)閉的pod可能繼續(xù)運(yùn)行。5 當(dāng)優(yōu)雅退出時(shí)間超時(shí)了，任

51、何Pod中正在運(yùn)行的進(jìn)程會(huì)被發(fā)送SIGKILL信號(hào)被殺死。Kubelet會(huì)完成pod的刪除，將優(yōu)雅退出的時(shí)間設(shè)置為0（表示立即刪除）。此時(shí)Pod會(huì)被真正刪除。當(dāng)?shù)谌綀?zhí)行時(shí)，應(yīng)用程序會(huì)獲取TERM信號(hào)，如果不做任何響應(yīng)，則會(huì)等最終被SIGKILL殺死。但事實(shí)上對(duì)般Java程序而言，獲取TERM信號(hào)會(huì)直接退出，若此時(shí)存在正在進(jìn)行的業(yè)務(wù)請(qǐng)求，該請(qǐng)求會(huì)由千JVM嘗試退出而異室終止。另方面，第四步執(zhí)行與第三步并行，這也意昧著應(yīng)用退出時(shí)可能Kube-Proxy沒(méi)有及時(shí)完全刪除Service上的關(guān)聯(lián)著的該實(shí)例Endpoint以及對(duì)應(yīng)的集群內(nèi)所有計(jì)算節(jié)點(diǎn)的iptable規(guī)則。因此前端仍會(huì)有請(qǐng)求被送到這個(gè)已經(jīng)

52、停止的應(yīng)用端口，進(jìn)而導(dǎo)致請(qǐng)求失敗。因此解決這類問(wèn)題最簡(jiǎn)單的方法就是在停止應(yīng)用前設(shè)置s個(gè)leep時(shí)間，因?yàn)樵谶@個(gè)時(shí)候Kube-Proxy會(huì)刪除Service上該實(shí)例的Endpoint并更新ptable,同時(shí)也可以給應(yīng)用時(shí)間處理完正在進(jìn)行的業(yè)務(wù)請(qǐng)求。1. apiVersion:extensions/vlbetal2. kind:Deployment3. metadata:4. name:nginx1sraocti1P1eers5. spec:ce678. matchLabels:9. component:nginx10. template:11. metadata12. ponent:nginx14.spec:15.containers:16.-name:nginx17.image:"nginx"18.ports19.-name:http20.h