Kubernetes容量規(guī)劃與擴(kuò)展技術(shù)方案

1、 Kubernetes 容量規(guī)劃與擴(kuò)展技術(shù)方案 1 Kubernetes整體容量規(guī)劃通常一個(gè)完整的高可用Kubernetes群集由3類節(jié)點(diǎn)組成：Master節(jié)點(diǎn)：用于運(yùn)行API Server和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ì)算資源，在確保平臺(tái)本身穩(wěn)定性的同時(shí)滿足業(yè)務(wù)需求并提升資源利用率，這就需要對(duì)集群的容量進(jìn)

2、行規(guī)劃。針對(duì)集群計(jì)算資源，首先需要定義節(jié)點(diǎn)數(shù)量和總資源容量。假設(shè)要在群集上運(yùn)行的一個(gè)應(yīng)用需要總?cè)萘繛? Core 32G的計(jì)算資源，這里主要有2種部署思路：一個(gè)思路是使用2臺(tái)4Core 16GB服務(wù)器實(shí)例作為Kubernetes工作節(jié)點(diǎn)，即較少的節(jié)點(diǎn)、較高配的服務(wù)器（類似集群直接使用物理機(jī)）。另一個(gè)思路是使用4臺(tái)2Core 8GB服務(wù)器實(shí)例作為Kubernetes工作節(jié)點(diǎn)（類似集群使用虛擬機(jī)）。這么，哪種思路更有優(yōu)勢(shì)？下文我們做下對(duì)比：由上圖可以發(fā)現(xiàn)，如果使用高配置方案，針對(duì)集群的管理便利性由于節(jié)點(diǎn)數(shù)量較少而變得較為簡單，同時(shí)針對(duì)應(yīng)用的資源利用率會(huì)有所提升。但是同樣也需要注意到由于節(jié)點(diǎn)密度較高

3、，單個(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ī)劃思路。2 Master節(jié)點(diǎn)性能設(shè)計(jì)2.1 Master節(jié)點(diǎn)架構(gòu)和容量設(shè)計(jì)Master節(jié)點(diǎn)通過static pod啟動(dòng)API Server、Controller Manager、Scheduler等控制服務(wù)，以及ETCD分布式數(shù)據(jù)庫。后者是CoreOS基于Raft協(xié)議開源的分布式key-value存儲(chǔ)，可用于服務(wù)發(fā)現(xiàn)、共享配置以及一致性保障（如數(shù)據(jù)庫選主、分布式鎖等）。在這里用于存儲(chǔ)Kub

4、ernetes API Server所接收的API對(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í)通過設(shè)置污點(diǎn)節(jié)點(diǎn)親和性的方式，避免應(yīng)用容器調(diào)度到Master上。參考下圖Master節(jié)點(diǎn)架構(gòu)，Master上主要涉及kube-apiserv-er、kube-controller-manager與kube-scheduler幾個(gè)服務(wù)。kube-apiserver：由于服務(wù)本身無狀態(tài)，需要確保通過負(fù)載均衡實(shí)現(xiàn)訪問API Server多實(shí)例的高可用訪問。kube-controller-man

5、ager與kube-scheduler：由于這兩個(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ù)開發(fā)方案設(shè)計(jì)的文章中會(huì)涉及實(shí)現(xiàn)方法）。2. ETCD本身需要高可用部署，建議至少3個(gè)節(jié)點(diǎn)，根據(jù)實(shí)際性能情況可以和Master一并運(yùn)行或獨(dú)立部署。官方使用kubeadm部署的方案參考：https:/kubernetes.io/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kub

6、eadm/物理硬件上，由于ETCD其高度依賴存儲(chǔ)和網(wǎng)絡(luò)，建議使用SSD等高IOPS存儲(chǔ)方案并確保ETCD集群之間以及API Server訪問ETCD網(wǎng)絡(luò)條件良好。另一方面，ETCD也涉及客戶端和服務(wù)器優(yōu)化，這部分在下一節(jié)再進(jìn)行討論。通常來說Master節(jié)點(diǎn)的性能與ETCD相關(guān)，與集群中API對(duì)象的讀寫頻率成正比。若集群節(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官方說明，3.x版本引入可伸縮性和性能改進(jìn)，可減少

7、任何大小群集的CPU、內(nèi)存、網(wǎng)絡(luò)和磁盤需求，從ETCD2升級(jí)到ETCD3，API Server的IOPS/CPU改善超過50%。根據(jù)Kubernetes版本說明，1.5.1版本后開始支持ETCD3，1.13廢除了ETCD2的支持。Master節(jié)點(diǎn)OS參數(shù)優(yōu)化ETCD服務(wù)端/客戶端優(yōu)化ETCD由于對(duì)存儲(chǔ)性能依賴較大。通?？梢酝ㄟ^服務(wù)器端/客戶端進(jìn)行性能優(yōu)化。關(guān)于服務(wù)器端存儲(chǔ)優(yōu)化阿里云實(shí)現(xiàn)了ETCD freelist 分配回收算法，具體參考：cf.io/blog/2019/05/09/performance-optimization-of-etcd-in-web-scale-data-scenar

8、io關(guān)于客戶端性能優(yōu)化，核心在于控制及優(yōu)化對(duì)API Server的對(duì)象讀寫。由于Kubernetes支持CRD擴(kuò)展API資源對(duì)象，因此在CRD對(duì)象Controller設(shè)計(jì)上應(yīng)盡可能精簡避免大對(duì)象的頻繁讀寫變化。2.2.2 Master相關(guān)監(jiān)控指標(biāo)建議3 Infra節(jié)點(diǎn)性能設(shè)計(jì)主要包含以下幾類業(yè)務(wù)無關(guān)的平臺(tái)服務(wù)：日志服務(wù)、監(jiān)控服務(wù)和外部流量路由服務(wù)。3.1 EFK架構(gòu)和容量Kubernetes本身支持多種日志收集方案，思路上可分為： 應(yīng)用直接寫Elasticsearch日志。 應(yīng)用通過emptydir等形式將日志輸出在Pod中，再通過Sidecar容器讀取日志寫入Elasticsearch。 應(yīng)

9、用將日志輸出在Docker標(biāo)準(zhǔn)輸出再通過平臺(tái)方案寫入Elasticsearch。當(dāng)今比較流行的方案是最后這個(gè)，通過Elasticsearch、Fluentd 和 Kibana（EFK）技術(shù)棧實(shí)現(xiàn)。其方案的具體思路是通過DaemonSet在需要收集日志的各個(gè)節(jié)點(diǎn)上運(yùn)行fluentd的容器，后者掛載每個(gè)節(jié)點(diǎn)宿主機(jī)的Docker日志目錄（如/var/log 和 /var/lib/docker/container）。這樣當(dāng)該節(jié)點(diǎn)的容器寫入Docker日志后就會(huì)被fluentd捕獲，最終寫入Elasticsearch。這樣用戶通過Kibana即可查詢指定Pod日志。此方案需要應(yīng)用將日志重定向到標(biāo)準(zhǔn)輸出，

10、以便Docker log捕獲。值得注意的是，由于EFK堆棧通過Fluentd將日志搬運(yùn)至Elasticsearch的數(shù)據(jù)是不斷累積的，故需要注意下列配置來保證集群可用：Fluentd 容量Fluentd的作用主要是將計(jì)算節(jié)點(diǎn)宿主機(jī)日志讀取后放入本地Buffer，再異步發(fā)送給遠(yuǎn)端Elasticsearch。因此當(dāng)遠(yuǎn)端無法及時(shí)寫入數(shù)據(jù)或本地產(chǎn)生日志過多遠(yuǎn)端無法及時(shí)消化時(shí)，F(xiàn)luentd默認(rèn)本地會(huì)產(chǎn)生overflow報(bào)錯(cuò)并丟棄舊的日志。因此需要合理調(diào)整配置中chunk_limit_size大小。 Elasticsearch高可用Elasticsearch部署需要注意以下幾點(diǎn)：1. 由于Elastic

11、search對(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. 作為Kubernetes集群的日志查詢服務(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í)間，避免

12、存儲(chǔ)空間不足。可以通過CronJob定期根據(jù)Namespace和日期清理歷史日志存儲(chǔ)。3.2 EFK監(jiān)控和調(diào)優(yōu) 日志節(jié)點(diǎn)OS參數(shù)優(yōu)化 日志節(jié)點(diǎn)監(jiān)控指標(biāo)3.3 Prometheus架構(gòu)和容量傳統(tǒng)對(duì)于IT系統(tǒng)的監(jiān)控，思路上會(huì)有三種實(shí)現(xiàn)方式：通過日志、通過探針和通過數(shù)據(jù)上報(bào)度量。 基于日志的監(jiān)控方案典型的方案就是通過ELK/EFK。應(yīng)用層將相關(guān)監(jiān)控KPI以日志形式進(jìn)行記錄，通過應(yīng)用層或平臺(tái)層輸出最終匯聚到Elasticsearch。后者通過可以通過定期查詢獲取對(duì)應(yīng)的監(jiān)控指標(biāo)，或者輸出報(bào)警。 基于探針的監(jiān)控方案典型的方案就是Java Spring Cloud體系使用zipkin sleuth。其原理是

13、通過Spring的APO在業(yè)務(wù)請(qǐng)求的兩端進(jìn)行攔截，實(shí)現(xiàn)用于標(biāo)記請(qǐng)求的Trace ID和標(biāo)記最小處理單元的Span ID等信息的注入，以此來跟蹤整個(gè)微服務(wù)調(diào)用鏈。 基于度量聚合的監(jiān)控方案Kubernetes默認(rèn)使用的Prometheus就是采用這個(gè)方案?；跁r(shí)序數(shù)據(jù)庫，通過內(nèi)置或外掛的exporter主動(dòng)或被動(dòng)獲取一段時(shí)間的監(jiān)控?cái)?shù)據(jù)，然后再通過聚合運(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ì)忽略其中部分尖峰KPI），Prometheus針對(duì)某些強(qiáng)精準(zhǔn)性的監(jiān)控場(chǎng)景未必適用，這個(gè)需要在定義具體監(jiān)控方案時(shí)識(shí)別

14、到。Prometheus包含以下關(guān)鍵組件： Prometheus Server用于收集和存儲(chǔ)時(shí)序數(shù)據(jù)，負(fù)責(zé)監(jiān)控?cái)?shù)據(jù)的獲取、存儲(chǔ)以及查詢。 監(jiān)控目標(biāo)配置Prometheus Server可以靜態(tài)配置定義監(jiān)控目標(biāo)的exporter，同時(shí)也支持通過服務(wù)發(fā)現(xiàn)（基于Kubernetes、DNS或Consul）來實(shí)現(xiàn)動(dòng)態(tài)管理監(jiān)控目標(biāo)。目前Kubernetes社區(qū)已經(jīng)實(shí)現(xiàn)通過定義CRD擴(kuò)展(/coreos/prometheus-operator/）MonitorRule來自動(dòng)生成并重新加載Pro-metheus監(jiān)控目標(biāo)配置。 監(jiān)控?cái)?shù)據(jù)查詢方案Prometheus Server通過實(shí)現(xiàn)PromQL語言來對(duì)監(jiān)控

15、數(shù)據(jù)進(jìn)行查詢以及分析。一般Kubernetes集成Prometheus主要有幾個(gè)思路：1. 采用原生Prometheus UI并自定義一個(gè)sidecar容器，通過注入sidecar來實(shí)現(xiàn)查詢權(quán)限管理。2. 基于Grafana定義查詢UI。 客戶端監(jiān)控輸出。應(yīng)用將監(jiān)控指標(biāo)輸出給Prometheus主要有幾個(gè)思路：1. Client SDK。為需要監(jiān)控的應(yīng)用服務(wù)生成相應(yīng)的Metrics并暴露給Prometheus Server。當(dāng)Prometheus Server來Pull時(shí)，直接返回實(shí)時(shí)狀態(tài)的Metrics。2. Push Gateway。主要用于不適合長期存在的短期Jobs等應(yīng)用。通過主動(dòng)Pu

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

17、身不支持高可用和數(shù)據(jù)分片，架構(gòu)上實(shí)現(xiàn)高可用一般有2個(gè)思路。1. 冗余的高可用。至少需要2個(gè)節(jié)點(diǎn)保持相同的配置和監(jiān)控目標(biāo)。各自獨(dú)立運(yùn)行進(jìn)行數(shù)據(jù)監(jiān)控?cái)?shù)據(jù)采集，并通過網(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í)作為最常見和簡單的部署方案，為了避免自身出現(xiàn)監(jiān)控問題，建議生產(chǎn)上使用2個(gè)集群的交叉監(jiān)控確保Prometheus平臺(tái)本身可用性。2. 遠(yuǎn)程存儲(chǔ)+聯(lián)邦集群方案。

18、目前開源項(xiàng)目thanos (/thanos-io/thanos）就是使用這個(gè)思路。通過Sidecar容器攔截Prometheus的請(qǐng)求并存放一份數(shù)據(jù)在云端。同時(shí)通過Querier實(shí)現(xiàn)Prometheus查詢API，當(dāng)需要監(jiān)控查詢時(shí)前者會(huì)根據(jù)Store確認(rèn)分片實(shí)例位置再進(jìn)行查詢。 AlertmanagerAlertmanager基于Gossip協(xié)議實(shí)現(xiàn)高可用，避免同時(shí)獲取多個(gè)Prometheus節(jié)點(diǎn)的告警數(shù)據(jù)，因此需要至少3個(gè)節(jié)點(diǎn)保持集群穩(wěn)定。另外，針對(duì)Alertmanager監(jiān)控可以基于其自帶的Deadman switch進(jìn)行開發(fā)擴(kuò)展。后者Deadman switch是Prometheus自帶的靜默報(bào)警測(cè)試，會(huì)一直不斷觸發(fā)報(bào)警直到Prometheus或A