容器云平臺的性能設(shè)計

1、容器云平臺的性能設(shè)計（下載原文可改文字顏色）II目錄目錄4.1 計算節(jié)點(diǎn)架構(gòu)和容量154.2 計算節(jié)點(diǎn)監(jiān)控和性能調(diào)優(yōu)174.3 應(yīng)用規(guī)劃18亨1Kubernetes整體容量規(guī)劃通常個完整的高可用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)。每個計算節(jié)點(diǎn)都具有些可分配的資源(CPU,內(nèi)存，GPU等）。因此如何更合理地分配這些計算資

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

3、用適配靈活單節(jié)點(diǎn)資源較少、應(yīng)用單實(shí)例資源依賴不可過大應(yīng)用穩(wěn)定性單節(jié)點(diǎn)應(yīng)用較多，爆炸半徑大單節(jié)點(diǎn)應(yīng)用較少，爆炸半徑小資源利用率單節(jié)點(diǎn)資源顆粒度大，可充分利用單節(jié)點(diǎn)資源顆粒度小，可能無法滿足應(yīng)用而閑置由上圖可以發(fā)現(xiàn)，如果使用高配置方案，針對集群的管理便利性由千節(jié)點(diǎn)數(shù)量較少而變得較為簡單，同時針對應(yīng)用的資源利用率會有所提升。但是同樣也需要注意到由千節(jié)點(diǎn)密度較高，單個節(jié)點(diǎn)出現(xiàn)故障后的導(dǎo)致應(yīng)用影響的爆炸半徑會比較大，對節(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è)計2.1

4、 Master節(jié)點(diǎn)架構(gòu)和容量設(shè)計Master節(jié)點(diǎn)通過staticpod啟動APIServer、ControllerManager、Scheduler等控制服務(wù)，以及ETCD分布式數(shù)據(jù)庫。后者是CoreOS基千Raft協(xié)議開源的分布式key-value存儲，可用千服務(wù)發(fā)現(xiàn)、共享配置以及致性保障（如數(shù)據(jù)庫選主、分布式鎖等）。在這里用千存儲KubernetesAPIServer所接收的A回對象。對千Master的容量設(shè)計主要包括如下幾點(diǎn)1節(jié)點(diǎn)和服務(wù)高可用。關(guān)千這點(diǎn)Kubernetes本身高可用部署架構(gòu)就涉及。建議至少3臺Master節(jié)點(diǎn)。同時通過設(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幾個服務(wù)。kube-apiserver由千服務(wù)本身無狀態(tài)，需要確保通過負(fù)載均衡實(shí)現(xiàn)訪問APIServer多實(shí)例的高可用訪問。kubecontrollermanager與kubescheduler:田千這兩個服務(wù)般使用單主節(jié)點(diǎn)active,多個從節(jié)點(diǎn)standy的模式運(yùn)行。其內(nèi)部會使用鎖爭用方式確認(rèn)主節(jié)點(diǎn)，其余節(jié)點(diǎn)處千standy狀態(tài)。直到主節(jié)點(diǎn)發(fā)生異室鎖失效后被其他節(jié)點(diǎn)爭用代替（在后續(xù)開發(fā)方案設(shè)計的文章中會涉及實(shí)現(xiàn)方法）

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

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

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

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

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

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

14、本地會產(chǎn)生overflow報錯并丟棄舊的日志。因此需要合理調(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對千存儲依賴較高，般使用本地存儲或基千LocalVolume的PV持久化，并使用StatefulSet啟動多節(jié)點(diǎn)實(shí)現(xiàn)高可用。因此Elasticsearch應(yīng)用建議啟動在Kubernetes集群固定獨(dú)占節(jié)點(diǎn)上，禁止業(yè)務(wù)容器調(diào)度。2 作為Kubern

16、etes集群的日志查詢服務(wù)，其對計算資源高度依賴。故建議使用少數(shù)節(jié)點(diǎn)高配置部署方案。節(jié)點(diǎn)數(shù)量至少為3臺。3 為了避免主節(jié)點(diǎn)腦裂，需要設(shè)置discover.zen.minimum_master_nodes節(jié)點(diǎn)數(shù)量2+1。4 由千Elasticsearch存儲的日志是根據(jù)Namespace和日期單獨(dú)存儲。故需要定義日志存儲時間，避免存儲空間不足?？梢酝ㄟ^CronJob定期根據(jù)Namespace和日期清理歷史日志存儲。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%磁盤分區(qū)使用率<80%10使用率<90%網(wǎng)卡流量使用率<50%(A-A網(wǎng)卡）主機(jī)可用性外部主機(jī)可用性監(jiān)控監(jiān)控服務(wù)可用性

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

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

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

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

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

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

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

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

27、metheus每日增長內(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%磁盤分區(qū)使用率<80%10使用率<90%網(wǎng)卡流量使用率<50%(A-A網(wǎng)卡）主機(jī)可用性外部主機(jī)可用性監(jiān)控監(jiān)控服務(wù)可用性（通過Prometheus)PV剩余空間<3%CPU/Memovercommit預(yù)測磁盤滿<1天Node中磁盤10>90%Prometheus不可用（通過AlertManager)AlertManager配置異常AlertManager服務(wù)不可用(Deadmanswitch)Prometheus

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

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

32、236,70316Core342,651341,232配置優(yōu)化和普通nginx類似，針對高并發(fā)場景需要額外進(jìn)行優(yōu)化。主要涉及HTTP會話保持是否使用HTTPS、TLS會話恢復(fù)單POD請求分?jǐn)偤侠砩蠈泳W(wǎng)絡(luò)優(yōu)化、后端應(yī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%磁盤分區(qū)使用率<8

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

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

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

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

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

40、用的場景參考如下：存儲類型讀寫類型PrometheusElasticsearchRegistry應(yīng)用塊存儲ROX建議建議不可實(shí)現(xiàn)建議文件存儲ROX/RWX可實(shí)現(xiàn)但避免可實(shí)現(xiàn)可實(shí)現(xiàn)建議對象存儲ROX/RWX不可實(shí)現(xiàn)不可實(shí)現(xiàn)建議（取決產(chǎn)品）不可實(shí)現(xiàn)4.2 計算節(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%磁盤分區(qū)使用率<80%10使用率<90%網(wǎng)卡流量使用率<50%(A-A網(wǎng)卡）主機(jī)可用性外部主機(jī)可用性監(jiān)控監(jiān)控服務(wù)可用性（通過Prometheus)單節(jié)點(diǎn)Pod數(shù)量250PV剩余空間<3%CPU/MemovercommitNode不可用Nodeexporter不可用預(yù)測磁盤滿<1天Node中磁盤10>90%Pod

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

44、最大資源量。同時通過實(shí)現(xiàn)Deviceplugin,Kubernetes可支持第三方硬件（如GPU)調(diào)度。具體QoS說明如下·另外，Kubernetes1.11版本后還支持通過定義和orityClass來聲明Pod的調(diào)度優(yōu)先級，這樣當(dāng)資源不足時優(yōu)先級低的Pod就會被優(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存儲依賴通常Pod中存儲主要涉及三類，包括Pod本身、emptyDir和PersistentVolumes持久卷（這里暫將Loca|Path記為以PV形式暴露）。需要注意，Pod容器本身存儲大小由dockerdevicemapper限制（默認(rèn)10G)，應(yīng)用若超出這個數(shù)值可能導(dǎo)致容器應(yīng)用異常。emptyDir可以通過對ephemeraI-storage的request和limit限制大小，如果超出設(shè)置數(shù)值容器可能

46、會被驅(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需要取人持久卷是否可以隨著計算節(jié)點(diǎn)遷移，否則需要通過計算節(jié)點(diǎn)親和性避免容器重新調(diào)度到其他節(jié)點(diǎn)后無法訪問持久卷或持久卷丟失的情況。下圖就是個基千localpath的本地存儲，應(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)用是否對外有額外依賴或約束。例如應(yīng)用使用Ingress泰露服務(wù)時對所綁定的域名有約束、通過NodePort暴露時對VIP和端口有約束，或是使用HostPort暴露時對綁定的宿主機(jī)IP和端口有約束。4.3.2 應(yīng)用配置優(yōu)化對千高負(fù)載應(yīng)用，如果直接使用水平伸縮HorizontalPodAutoscale,隨著應(yīng)用的自動擴(kuò)容和收縮，往往發(fā)現(xiàn)期間

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

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

52、停止的應(yīng)用端口，進(jìn)而導(dǎo)致請求失敗。因此解決這類問題最簡單的方法就是在停止應(yīng)用前設(shè)置s個leep時間，因?yàn)樵谶@個時候Kube-Proxy會刪除Service上該實(shí)例的Endpoint并更新ptable,同時也可以給應(yīng)用時間處理完正在進(jìn)行的業(yè)務(wù)請求。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