淺談基于 OpenStack 和 k8s 輕量研發(fā)私有云建設(shè)

背景

面臨的挑戰(zhàn)

功能簡(jiǎn)介

核心優(yōu)勢(shì)

核心設(shè)施平臺(tái)（IaaS云）

基礎(chǔ)服務(wù)平臺(tái)（PaaS云）

背景

面臨的挑戰(zhàn)

功能簡(jiǎn)介

核心優(yōu)勢(shì)

核心設(shè)施平臺(tái)（IaaS云）

基礎(chǔ)服務(wù)平臺(tái)（PaaS云）

技術(shù)落地

整體架構(gòu)

技術(shù)選型

IaaS云技術(shù)

PaaS云技術(shù)

實(shí)踐的過程

OpenStack & CloudStack

KVM & VMWare

CentOS & Ubuntu

OpenStack & k8s

擁抱開源面臨的困難

云原生架構(gòu)帶來的挑戰(zhàn)

私有云建設(shè)路線

私有云的容量評(píng)估

全棧監(jiān)控

k8s集群規(guī)模

k8s集群計(jì)算資源

壓力引擎

其它

運(yùn)行效果展示

基礎(chǔ)服務(wù)平臺(tái)（IaaS云）

登錄認(rèn)證

高效管理物理資源（計(jì)算、網(wǎng)絡(luò)、存儲(chǔ)）

1.2、輕松管理系統(tǒng)鏡像

web桌面

集群管理 Web UI

基礎(chǔ)服務(wù)平臺(tái)（PaaS云）

DevOps流水線

負(fù)載均衡

代碼倉庫

敏捷研發(fā)管理

調(diào)用鏈監(jiān)控

服務(wù)注冊(cè)

服務(wù)監(jiān)控

日志聚合

API文檔

配置管理

制品倉庫

容器倉庫

靜態(tài)代碼掃描

可視化微服務(wù)管理

壓力引擎

資源監(jiān)控

服務(wù)可視化監(jiān)控

自定義告警

經(jīng)驗(yàn)心得

未來展望

背景

建設(shè)公司研發(fā)私有云，為研發(fā)部門提供安全、可靠、高效的基礎(chǔ)資源、數(shù)據(jù)存儲(chǔ)服務(wù)、DevOps 流水線以及運(yùn)維自動(dòng)化服務(wù)等。

面臨的挑戰(zhàn)

運(yùn)維：高效管理基礎(chǔ)設(shè)施資源、監(jiān)控報(bào)警完善且易用；

產(chǎn)品：彈性擴(kuò)容、資源隨時(shí)可用；

研發(fā)整體：提升資源利用率、提高產(chǎn)品交付效能，降低成本。

功能簡(jiǎn)介

核心優(yōu)勢(shì)

任務(wù)調(diào)度：為集群系統(tǒng)中的任務(wù)提供調(diào)度服務(wù)，自動(dòng)將服務(wù)按資源需求分配到資源限制的計(jì)算節(jié)點(diǎn);

資源隔離：為產(chǎn)品提供管控與服務(wù)節(jié)點(diǎn)隔離能力，保證研發(fā)應(yīng)用跟管控服務(wù)不互相產(chǎn)生影響;

高可用能力：自動(dòng)監(jiān)控服務(wù)的運(yùn)行，根據(jù)運(yùn)行情況對(duì)失效的服務(wù)進(jìn)行自動(dòng)重啟恢復(fù);

網(wǎng)絡(luò)互聯(lián)互通能力：提供統(tǒng)一的IP地址分配和網(wǎng)絡(luò)互通能力;

統(tǒng)一編排管理能力：結(jié)合 gitlab 和 k8s 對(duì)輸出的產(chǎn)品進(jìn)行統(tǒng)一的編排管理;

公共產(chǎn)品組件為團(tuán)隊(duì)提供了統(tǒng)一部署、驗(yàn)證、授權(quán)、調(diào)度和管控能力，為私有云服務(wù)提供基礎(chǔ)性的支撐。

核心設(shè)施平臺(tái)（IaaS云）

提供計(jì)算、網(wǎng)絡(luò)、存儲(chǔ)等核心資源設(shè)備的虛擬化；

支持不同操作系統(tǒng)，包括主流的 win 和 Linux 系統(tǒng)；

提供主要包括三種服務(wù)：云主機(jī)、云網(wǎng)絡(luò)、云硬盤；

提供可視化 Web UI。

提供 k8s 集群（容器云）規(guī)劃、部署和運(yùn)營(yíng)；

支持多種計(jì)算、存儲(chǔ)和網(wǎng)絡(luò)方案；

集成 Ansible 運(yùn)維自動(dòng)化工具；

支持在線環(huán)境和離線環(huán)境部署；

提供可視化 Web UI。

基礎(chǔ)服務(wù)平臺(tái)（PaaS云）

提供數(shù)據(jù)存儲(chǔ)、應(yīng)用服務(wù)、DevOps、運(yùn)維管理等服務(wù)；

數(shù)據(jù)存儲(chǔ)類：支持常見 NFS 、Ceph RBD、Local Volume 等；

應(yīng)用服務(wù)類：自愈和自動(dòng)伸縮、調(diào)度和發(fā)布、負(fù)載均衡、消息隊(duì)列、容器引擎、調(diào)用鏈監(jiān)控、Metrics 監(jiān)控、日志聚合、服務(wù)安全、API管理、彈性和容錯(cuò)、配置管理等；

DevOps：敏捷研發(fā)管理、持續(xù)交付流水線、代碼掃描、代碼倉庫、制品倉庫、容器倉庫、壓測(cè)引擎等；

運(yùn)維管理：日志監(jiān)控、資源監(jiān)控、消息告警等。

技術(shù)落地

整體架構(gòu)

技術(shù)選型

實(shí)踐的過程

作為兩大主流開源云平臺(tái)，OpenStack 和 CloudStack 各具優(yōu)勢(shì)。

CloudStack 是從 cloud.com 公司的產(chǎn)品轉(zhuǎn)向開源，從產(chǎn)品化方面來說，本身是個(gè)比較成熟的產(chǎn)品，安裝和部署都很方便，且提供了完整的升級(jí)流程，可以便于將來和社區(qū)保持同步。然而隨著社區(qū)版本的不斷更新和兼容各家產(chǎn)品，CloudStack 也逐漸變得龐大。以目前公司搭建私有云落地方案而言，很多功能無用且顯得多余。

OpenStack 目前已經(jīng)成為了大家選擇云計(jì)算技術(shù)落地框架的事實(shí)標(biāo)準(zhǔn)，優(yōu)勢(shì)在于其插件化的框架，因?yàn)榧夹g(shù)框架允許自由的選擇可用插件，私有云落地方案中，可以只選擇需要的組件進(jìn)行安裝。因?yàn)榭蚣茉试S插入不同組件，所以 OpenStack 社區(qū)也獲得了更多廠商的支持，社區(qū)活躍度也比較高。在企業(yè)實(shí)施落地方案的時(shí)候，可以有更多的選擇余地，對(duì)遇到的問題，也有了更多更快的響應(yīng)。

考慮到如果將來公司還需要進(jìn)一步開發(fā)所需要的組件，并且需要對(duì)云平臺(tái)進(jìn)行針對(duì)性的調(diào)優(yōu)，例如虛擬機(jī)的 IO、CPU 綁定等操作，而不只是依賴于開源社區(qū)的版本，OpenStack 的框架則是更好的選擇。CloudStack 如果進(jìn)行二次開發(fā)，代碼未合并入社區(qū)版本的時(shí)候，升級(jí)則需要再次 merge 代碼，重復(fù)工作比較多。OpenStack 則可以做成插件，在升級(jí) OpenStack 版本的時(shí)候，保持插件的可用。

但是由于 OpenStack 的產(chǎn)品化復(fù)雜度較高，搭建落地到將來的升級(jí)，以及后續(xù)的二次開發(fā)，都需要進(jìn)行不少的開發(fā)和測(cè)試人力投入。對(duì)于非互聯(lián)網(wǎng)公司來說，咱們并沒有比較成熟的運(yùn)維團(tuán)隊(duì)和研發(fā)團(tuán)隊(duì)，開發(fā)和測(cè)試在人力資源成本方面計(jì)算都很緊張，所以對(duì)于有公有云需求還是直接購買大廠的云服務(wù)即可。

最終的在開源方案選擇上，更傾向于 OpenStack。

OpenStack 原生對(duì) KVM 支持更加完善。

KVM 也是比較成熟的虛擬化平臺(tái)，于 2006 年寫入 Linux 內(nèi)核，且在 Redhat 6 以后，轉(zhuǎn)向?qū)?KVM 的支持而非之前大力推廣 Xen 的虛擬化方案。

VMware 是商業(yè)軟件，在虛擬化平臺(tái)中，目前應(yīng)該屬于 IO 和穩(wěn)定性都最優(yōu)化的方案。OpenStack 中，因?yàn)?VMware 本身提供了相應(yīng)的 driver，對(duì) VMware 的支持也比較成熟。

最終放棄 VMware 的原因，是因?yàn)槠涫跈?quán)比較昂貴。

目前選擇的方案，以 KVM 為主。

OpenStack 社區(qū) 對(duì) Ubuntu 支持比較完善，Ubuntu 更新速度快，內(nèi)核版本比較新，可以支持更高版本的KVM，對(duì)OpenStack使用者來說，Ubuntu 可以提供更好的性能。

就系統(tǒng)的穩(wěn)定性而言，CentOS 來自 Redhat 商業(yè)版本的重新編譯，穩(wěn)定性和系統(tǒng)優(yōu)化以及兼容性方面，CentOS 有著比較完善的測(cè)試和發(fā)型流程。CentOS 7 以后，也換用了 Linux 3.x 內(nèi)核版本。

鑒于系統(tǒng)可靠性的選擇和之前公司的技術(shù)積累，還是選用 CentOS 系列，比 Ubuntu 管理更為方便。

OpenStack 主要是面向資源分配，虛擬機(jī)創(chuàng)出來了就基本沒有責(zé)任了，至于服務(wù)高可用，自動(dòng)伸縮，監(jiān)控等這類的功能完全由應(yīng)用方來處理，平臺(tái)不提供支持，適合傳統(tǒng)的部署模式，對(duì)應(yīng)用而言和物理機(jī)時(shí)代沒有區(qū)別；

而 k8s 容器云主要面向的是服務(wù)，強(qiáng)調(diào)服務(wù)能力，具有彈性與高可用保障，而不是簡(jiǎn)單地提供 IT 資源。對(duì)應(yīng)的，應(yīng)用服務(wù)也要使用云原生的理念來進(jìn)行改造拆分，以更好地利用 k8s 提供的平臺(tái)能力。

就咱們公司而言目前還需要 OpenStack，因?yàn)楹芏嗬舷到y(tǒng)沒有容器化，所以到了現(xiàn)實(shí)環(huán)境下就要妥協(xié)。

但是無論是 OpenStack 還是 k8s 上手技術(shù)門檻較高，最痛苦的事情，莫過于看它的架構(gòu)。

不信？好，扔個(gè) OpenStack 架構(gòu)圖給你看：

我還是用一個(gè)簡(jiǎn)單的圖吧，看得更明白些。如下：

k8s 架構(gòu)圖如下：

看上去比 OpenStack 的架構(gòu)圖稍微好點(diǎn)，不過從技術(shù)上來說也是比較復(fù)雜的。

云計(jì)算發(fā)展到今天，無論是在技術(shù)、服務(wù)層面，還是在商業(yè)層面都已經(jīng)相對(duì)比較成熟。當(dāng)前絕大多數(shù)初創(chuàng)公司在基礎(chǔ)設(shè)施上的策略一定是公有云，已經(jīng)極少再有自建或托管 IDC 的情況，所以不會(huì)存在是否上云這樣的糾結(jié)。

但是對(duì)于我們這樣體量的公司，全部上云，就必須要考慮得更全面：考慮基礎(chǔ)設(shè)施的變化，業(yè)務(wù)的平穩(wěn)過度，運(yùn)維模式的轉(zhuǎn)變，成本管控的調(diào)整，以及眾多的細(xì)節(jié)問題。

雖然需要比較和考慮的因素非常多，主要從人員能力、技術(shù)掌控、未來發(fā)展等方面進(jìn)行說明。

人的因素是放在第一位的，企業(yè)中一般是業(yè)務(wù)開發(fā)應(yīng)用及基礎(chǔ)架構(gòu)運(yùn)維人員（比如系統(tǒng)、網(wǎng)絡(luò)管理等），采用開源的方案的話，如果僅僅是在開發(fā)、測(cè)試環(huán)境去試著安裝、使用是沒有問題的，但是當(dāng)準(zhǔn)備在生產(chǎn)上進(jìn)行實(shí)施部署，并且后續(xù)為了進(jìn)一步提升開源平臺(tái)化的能力（比如生產(chǎn)遇到問題需要分析、內(nèi)部系統(tǒng)集成、進(jìn)行前端定制、跟隨社區(qū)優(yōu)化/升級(jí)等），會(huì)發(fā)現(xiàn)這些均需要能力較強(qiáng)的既懂開發(fā)也懂基礎(chǔ)架構(gòu)的人員團(tuán)隊(duì)時(shí)候就寸步難行了。

越是底層的技術(shù)，技術(shù)門檻就越高、越復(fù)雜，也越離不開高端人才的投入。比如硬件資源虛擬化，就需要有懂內(nèi)核、懂網(wǎng)絡(luò)、懂 OpenStack、懂 k8s、懂分布式存儲(chǔ)如 Ceph 等等的專業(yè)人才。但是真正精通的人卻不多，加上要搞定整套解決方案，還需要一個(gè)完整的團(tuán)隊(duì)，這就難上加難，在團(tuán)隊(duì)組建上面臨更大的困難。人才緊缺，就意味著人力成本會(huì)很高，這個(gè)就是技術(shù)投入的隱性成本。而且因?yàn)榧夹g(shù)門檻高，一旦發(fā)生人員流動(dòng)，那么，對(duì)于原有技術(shù)平臺(tái)來說，無人能把控的風(fēng)險(xiǎn)就會(huì)更高。這一點(diǎn)往往會(huì)是最大的隱性管理成本所在。

當(dāng)然，在人才招攬上，我們可以加大人力成本投入，招聘最優(yōu)秀的人才。但是作為像咱們這樣以更加聚焦于業(yè)務(wù)，以業(yè)務(wù)發(fā)展為生命線的公司，我們更期望能夠在業(yè)務(wù)上取得創(chuàng)新和發(fā)展，而不是在技術(shù)上取得多么非凡的成就（這一點(diǎn)與公司的發(fā)展訴求是不一致的）。所以這就從根本上決定了，我們不會(huì)無限度地投入，或投入非常大的成本在這些基礎(chǔ)技術(shù)的研究上。

所以從未來發(fā)展來看，私有云（存量+測(cè)試&開發(fā)）與公有云（生產(chǎn)+增量）方案是適合我們的方向，開源方案和商業(yè)方案會(huì)長(zhǎng)時(shí)間存在，這是受每個(gè)公司的技術(shù)戰(zhàn)略定位決定的。而對(duì)于大多數(shù)企業(yè)來說，以實(shí)現(xiàn)功能服務(wù)前端業(yè)務(wù)為主的技術(shù)戰(zhàn)略，則選擇上更應(yīng)該傾向于選擇商業(yè)方案。

大致來說，在部署應(yīng)用程序的方式上，我們現(xiàn)在主要經(jīng)歷了三個(gè)時(shí)代：

傳統(tǒng)部署時(shí)代：早期企業(yè)直接將應(yīng)用程序部署在物理機(jī)上。由于物理機(jī)上不能為應(yīng)用程序定義資源使用邊界，我們也就很難合理地分配計(jì)算資源。例如：如果多個(gè)應(yīng)用程序運(yùn)行在同一臺(tái)物理機(jī)上，可能發(fā)生這樣的情況：其中的一個(gè)應(yīng)用程序消耗了大多數(shù)的計(jì)算資源，導(dǎo)致其他應(yīng)用程序不能正常運(yùn)行。應(yīng)對(duì)此問題的一種解決辦法是，將每一個(gè)應(yīng)用程序運(yùn)行在不同的物理機(jī)上。然而，這種做法無法大規(guī)模實(shí)施，因?yàn)橘Y源利用率很低，且企業(yè)維護(hù)更多物理機(jī)的成本昂貴。

虛擬化部署時(shí)代：針對(duì)上述問題，虛擬化技術(shù)應(yīng)運(yùn)而生。用戶可以在單臺(tái)物理機(jī)的CPU上運(yùn)行多個(gè)虛擬機(jī)，虛擬化技術(shù)使得應(yīng)用程序被虛擬機(jī)相互分隔開，限制了應(yīng)用程序之間的非法訪問，進(jìn)而提供了一定程度的安全性。虛擬化技術(shù)提高了物理機(jī)的資源利用率，可以更容易地安裝或更新應(yīng)用程序，降低了硬件成本，因此可以更好地規(guī)模化實(shí)施。每一個(gè)虛擬機(jī)可以認(rèn)為是被虛擬化的物理機(jī)之上的一臺(tái)完整的機(jī)器，其中運(yùn)行了一臺(tái)機(jī)器的所有組件，包括虛擬機(jī)自身的操作系統(tǒng)。

容器化部署時(shí)代：容器與虛擬機(jī)類似，但是降低了隔離層級(jí)，共享了操作系統(tǒng)。因此，容器可以認(rèn)為是輕量級(jí)的。與虛擬機(jī)相似，每個(gè)容器擁有自己的文件系統(tǒng)、CPU、內(nèi)存、進(jìn)程空間等。運(yùn)行應(yīng)用程序所需要的資源都被容器包裝，并和底層基礎(chǔ)架構(gòu)解耦。容器化的應(yīng)用程序可以跨云服務(wù)商、跨Linux操作系統(tǒng)發(fā)行版進(jìn)行部署。借助容器技術(shù)呈現(xiàn)了一個(gè)優(yōu)雅的抽象場(chǎng)景：讓開發(fā)所需要的靈活性、開放性和運(yùn)維所關(guān)注的標(biāo)準(zhǔn)化、自動(dòng)化達(dá)成相對(duì)平衡。容器鏡像迅速成為了應(yīng)用分發(fā)的 工業(yè)標(biāo)準(zhǔn)。

前面我們說了，我們公司目前正處于 「虛擬化部署時(shí)代」 到 「容器化部署時(shí)代」的過渡階段，那么它必然帶來了更高的要求：

敏捷地創(chuàng)建和部署應(yīng)用程序：相較于創(chuàng)建虛擬機(jī)，創(chuàng)建容器更加容易和快速；

高度自動(dòng)化的軟件交付：可以更快更頻繁地構(gòu)建、部署的、并且輕松地回滾；

分離開發(fā)和運(yùn)維的關(guān)注點(diǎn)：在開發(fā)構(gòu)建階段可以部署到多種基礎(chǔ)設(shè)施上，將部署階段需要關(guān)注的內(nèi)容聚焦在如何提供基礎(chǔ)設(shè)施以及如何使用的過程中。降低了開發(fā)和運(yùn)維的耦合度；

可監(jiān)控性：不僅可以查看操作系統(tǒng)級(jí)別的資源監(jiān)控信息，還可以查看應(yīng)用程序健康狀態(tài)以及 k8s 集群的監(jiān)控信息;

開發(fā)、測(cè)試、生產(chǎn)不同階段的環(huán)境一致性：在開發(fā)環(huán)境的容器與測(cè)試、生產(chǎn)環(huán)境中運(yùn)行的容器一致;

跨云服務(wù)商、跨操作系統(tǒng)的可移植性：容器支持運(yùn)行在 Ubuntu、RHEL、CentOS 等不同的操作系統(tǒng)發(fā)行版上，可以運(yùn)行在私有云、也可以支持阿里云等不同的云供應(yīng)商的環(huán)境中；

以應(yīng)用程序?yàn)橹行牡墓芾恚禾摂M機(jī)時(shí)代的考慮的問題是在虛擬硬件上運(yùn)行一個(gè)操作系統(tǒng)，而容器化時(shí)代，問題的焦點(diǎn)則是在操作系統(tǒng)的邏輯資源上運(yùn)行一個(gè)應(yīng)用程序；

松耦合、分布式、彈性、無約束的微服務(wù)：滿足更小的、獨(dú)立的微服務(wù)，可以動(dòng)態(tài)部署和管理；

資源隔離：支持多租戶，確保應(yīng)用程序性能不受干擾；

資源利用：需要滿足資源高效、高密度利用。

針對(duì)上述更高訴求，我們?cè)诮ㄔO(shè)私有云的過程中需要重點(diǎn)考慮并逐一落地。

私有云建設(shè)很少有一步到位的，往往最開始的階段是滿足最基礎(chǔ)的需求，例如計(jì)算虛擬化，存儲(chǔ)虛擬化，然后網(wǎng)絡(luò)虛擬化，然后容器，監(jiān)控，大數(shù)據(jù)，編排，數(shù)據(jù)庫，等等公共應(yīng)用。

其實(shí)，這個(gè)和云計(jì)算的分層也是有很大關(guān)系的。從 IaaS 到 PaaS，再到 SaaS，層層遞進(jìn)。研發(fā)云的建設(shè)，往往也是遵循這個(gè)規(guī)律。在實(shí)踐中，可能會(huì)有一些交集。

通常都是分幾期的。第一期為試點(diǎn)項(xiàng)目，第二期根據(jù)一期結(jié)果形成規(guī)范，標(biāo)準(zhǔn)，成為新開發(fā)應(yīng)用的標(biāo)準(zhǔn)平臺(tái)。第三期逐漸將老應(yīng)用遷移到私有云上。

對(duì)于私有云實(shí)施：

通常來講私有云基礎(chǔ)設(shè)施只被公司研發(fā)團(tuán)隊(duì)使用，支持單租戶即可；

一般使用 4 個(gè)網(wǎng)：管理網(wǎng)、業(yè)務(wù)網(wǎng)（vxlan）、帶外網(wǎng)、存儲(chǔ)網(wǎng)；

使用不同子網(wǎng)

私有云的容量需要根據(jù)公司業(yè)務(wù)來評(píng)估，以一般行業(yè)來說，都有 web 區(qū)，有 app，有 db。需要根據(jù)運(yùn)行在私有云上的業(yè)務(wù)的多少，來統(tǒng)計(jì)所需要的資源的多少。例如，web區(qū)需要 nginx，需要考慮 HA 和 LB，那么就需要 2 臺(tái)以上；如果多個(gè)業(yè)務(wù)共享 nginx，那么就需要多個(gè) nginx 集群來分擔(dān)壓力。

OpenStack Celimeter 模塊專門用來擁擠CPU，內(nèi)存，網(wǎng)絡(luò)的使用量，可以統(tǒng)計(jì)出使用云資源，相對(duì)傳統(tǒng)環(huán)境節(jié)省了多少資源。

至于成本和效率的平衡，一般在私有云建設(shè)初期很難做到。設(shè)備的購置，部署，人員的配置等等都是一筆不小的開支；私有云真正的優(yōu)勢(shì)體現(xiàn)在后期的使用中。

容量如何評(píng)估，這個(gè)肯定是沒有普適標(biāo)準(zhǔn)的了。容量通常從三方面考慮：計(jì)算能力、存儲(chǔ)容量、網(wǎng)絡(luò)帶寬。這三方面可以說也是數(shù)據(jù)中心最基本的三大核心要素了，我們都知道，云計(jì)算是以規(guī)模取勝的，這個(gè)規(guī)模如何決定？究竟是 20 節(jié)點(diǎn)，50 節(jié)點(diǎn)，還是 100+ 節(jié)點(diǎn)，這個(gè)得根據(jù)你自己的業(yè)務(wù)需求來考慮了，在小規(guī)模情況下，為了高可用，如果可用容量評(píng)估是 N，那你就按 2N 來計(jì)算，私有云一般不會(huì)像達(dá)到公有云那種規(guī)模，所以通常也不可能達(dá)到很多大佬口中的虛機(jī)隨便掛，真掛了你宿主機(jī)資源沒有了，咋整？

至于成本，的看你的方案了，我們是采用開源自建，如果是與廠商合作共建，合作情況下如何分工，哪些外包出去，這個(gè)得仔細(xì)考慮。通常，如果人力資源有限，技術(shù)實(shí)力有限，那就由承包給廠商來實(shí)施吧，不然到后面也是個(gè)爛攤子。但是，全部外部給廠商的不足也是明顯的，一不小心就被人家鎖定，每年燒錢的跑不掉的了，尤其是項(xiàng)目上馬后，停也停不下來了。

首先我們要了解監(jiān)控的必要性，如果沒有監(jiān)控?cái)?shù)據(jù)，運(yùn)維側(cè)無從談起，沒有數(shù)據(jù)，那么如何去度量一個(gè)指標(biāo)呢？

所以，在建設(shè)研發(fā)私有云盡量搭建一套適合的監(jiān)控體系是必要的。

而從監(jiān)控分類來說，常見的是以下幾種：

Metrics 監(jiān)控主要包括核心業(yè)務(wù)指標(biāo)監(jiān)控和資源監(jiān)控，核心業(yè)務(wù)指標(biāo)監(jiān)控主要方式還是埋點(diǎn)，目前這塊我們基本是空白。至于資源監(jiān)控，我們集成云原生的開源監(jiān)控系統(tǒng) Prometheus 可以 cover 大部分的需求。

日志監(jiān)控這塊包括應(yīng)用日志和平臺(tái)日志的聚合，這塊目前的技術(shù)比較成熟，基本是集成成熟 ELK & EFk 開源方案解決。

健康檢查方面，在 k8s 容器云層提供存活和就緒探針，另外，在微服務(wù)框架也提供了應(yīng)用監(jiān)控中心，可以很方便進(jìn)行監(jiān)控。

告警系統(tǒng)是每個(gè)監(jiān)控系統(tǒng)的必備功能，Prometheus 支持豐富的告警規(guī)則和方式，常見的郵件、釘釘、微信等都支持。

這里特別提一下調(diào)用鏈監(jiān)控，這個(gè)在目前的微服務(wù)系統(tǒng)里面是必可少的組件，分布式追蹤、服務(wù)網(wǎng)格遙測(cè)分析、度量聚合和可視化還是挺好用的，這里我們選擇了 Skywalking，具體考量可以參考下表：

綜上所述，我們可以通過下圖來簡(jiǎn)單概況全棧監(jiān)控這塊的設(shè)計(jì)：

在實(shí)踐中，大家經(jīng)常問到的一個(gè)問題是我們公司應(yīng)該選擇一個(gè)還是多個(gè) k8s 集群？

一個(gè)大一統(tǒng)的的平臺(tái)，支持多種應(yīng)用負(fù)載、環(huán)境和多租戶隔離；

或者，一組以應(yīng)用為中心的小集群，支持不同應(yīng)用和環(huán)境的生命周期管理。

我們可以比較一下這兩種選擇：

默認(rèn)情況下，kubelet 使用 CFS 配額 來執(zhí)行 pod 的 CPU 約束。當(dāng)節(jié)點(diǎn)上運(yùn)行了很多 CPU 密集的應(yīng)用時(shí)，工作負(fù)載可能會(huì)遷移到不同的 CPU 核，工作負(fù)載的會(huì)受到 CPU 緩存親和性以及調(diào)度延遲的影響。當(dāng)使用大規(guī)格實(shí)例類型時(shí)，節(jié)點(diǎn)的 CPU 數(shù)量較多，現(xiàn)有的 Java，Golang 等應(yīng)用在多 CPU 共享的場(chǎng)景，性能會(huì)出現(xiàn)明顯下降。所有對(duì)于大規(guī)格實(shí)例，需要對(duì)CPU管理策略進(jìn)行配置，利用 CPU set 進(jìn)行資源分配。

此外一個(gè)重要的考慮因素就是 NUMA 支持。在 NUMA 開啟的物理機(jī)實(shí)例或者大規(guī)格實(shí)例上，如果處理不當(dāng)，內(nèi)存訪問吞吐可能會(huì)比優(yōu)化方式降低了30%。Topology 管理器可以開啟 NUMA 感知 https://kubernetes.io/docs/tasks/administer-cluster/topology-manager/ 。但是目前 k8s 對(duì) NUMA 的支持比較簡(jiǎn)單，還無法充分發(fā)揮 NUMA 的性能。

選擇后者典型的場(chǎng)景是：

開發(fā)、測(cè)試環(huán)境使用不同的集群；

不同的部門使用不同的集群進(jìn)行隔離；

不同的應(yīng)用使用不同的集群；

不同版本的 k8s 集群。

采用以多個(gè)小集群的主要原因在于爆炸半徑比較小，可以有效提升系統(tǒng)的可用性。同時(shí)通過集群也可以比較好地進(jìn)行資源隔離。管理、運(yùn)維復(fù)雜性的增加是采用多個(gè)小集群的一個(gè)不足之處。

值得一提的是源自 Google Borg 的理念，Kubernetes 的愿景是成為 Data Center Operating System，而且 Kubernetes 也提供了 RBAC、namespace 等管理能力，支持多用戶共享一個(gè)集群，并實(shí)現(xiàn)資源限制。 但是這些更多是 “軟多租” 能力，不能實(shí)現(xiàn)不同租戶之間的強(qiáng)隔離。在多租戶最佳實(shí)踐中，我們可以有如下的一些建議：

數(shù)據(jù)平面：可以通過 PSP (PodSecurityPolicy) 提升容器的隔離性；利用 Network Policy 提升應(yīng)用之間網(wǎng)絡(luò)隔離性；可以通過將 nodes 和 namespace 綁定在一起，來提升 namespace 之間資源的隔離。

控制平面：Kubernetes 的控制平面包括 master 組件 API Server, Scheduler, etcd 等，系統(tǒng) addon 如CoreDNS, Ingress Controller 等，以及用戶的擴(kuò)展，如第三方的CRD (Customer Resource Definition) controller。這些組件大多不具備良好的租戶之間的安全、資源和故障隔離能力。一個(gè)錯(cuò)誤的CRD contoller 實(shí)現(xiàn)有可能打掛一個(gè)集群的 API Server。

目前而言，Kubernetes 對(duì)硬隔離的支持存在很多局限性，同時(shí)社區(qū)也在積極探索一些方向。

另一個(gè)需要考慮的方案是 Kubernetes 自身的可擴(kuò)展性，我們知道一個(gè) Kubernetes 集群的規(guī)模在保障穩(wěn)定性的前提下受限于多個(gè)維度，一般而言 Kubernetes 集群小于 5000 節(jié)點(diǎn)。云廠商 Kubernetes 規(guī)模化上有豐富的經(jīng)驗(yàn)，但是對(duì)于絕大多數(shù)公司而言，是無法解決超大集群的運(yùn)維和定制化復(fù)雜性的。

另外值得一提的是可以利用 Istio 服務(wù)網(wǎng)格輕松實(shí)現(xiàn)對(duì)多個(gè) k8s 集群的應(yīng)用的統(tǒng)一路由管理。

k8s 集群計(jì)算資源考量可以參考下表：

傳統(tǒng)虛擬化技術(shù) I/O 損耗較大；對(duì)于 I/O 密集型應(yīng)用，物理機(jī)相比傳統(tǒng)虛擬機(jī)有更好的性能表現(xiàn)；

在物理機(jī)上部署有更少的額外資源開銷（如虛擬化管理、虛擬機(jī)操作系統(tǒng)等）；可以有更高的部署密度，從而降低基礎(chǔ)設(shè)施成本；

在物理機(jī)上可以更加靈活地選擇網(wǎng)絡(luò)、存儲(chǔ)等設(shè)備和軟件應(yīng)用生態(tài)。

一般而言建議：

對(duì)性能極其敏感的應(yīng)用，如高性能計(jì)算，物理機(jī)是較好的選擇；

云主機(jī)支持熱遷移，可以有效降低運(yùn)維成本；

在工作實(shí)踐，我們會(huì)為 k8s 集群劃分靜態(tài)資源池和彈性資源池。通常而言，固定資源池可以根據(jù)需要選擇物理機(jī)或者云主機(jī)實(shí)例。彈性資源池建議根據(jù)應(yīng)用負(fù)載使用合適規(guī)格的云主機(jī)實(shí)例來優(yōu)化成本、避免浪費(fèi)，提升彈性供給保障。

在壓力引擎這塊，目前還是傾向選擇開源壓測(cè)工具一哥：Jmeter。

Jmeter 容器云的設(shè)計(jì)如下：

目前常規(guī) Jmeter 存在的問題：

并發(fā)數(shù)超過單節(jié)點(diǎn)承載能力時(shí)，多節(jié)點(diǎn)環(huán)境配置、維護(hù)復(fù)雜；

默認(rèn)配置下無法并行運(yùn)行多個(gè)測(cè)試，需要更改配置啟動(dòng)額外進(jìn)程；

難以支持云環(huán)境下測(cè)試資源的彈性伸縮需求。

Jmeter 容器云帶來的改變：

壓測(cè)執(zhí)行節(jié)點(diǎn)一鍵安裝；

多個(gè)項(xiàng)目、多個(gè)測(cè)試可并行使用同一個(gè)測(cè)試資源池（多租戶），提高資源利用率；

對(duì)接 k8s HPA 根據(jù)并發(fā)數(shù)自動(dòng)啟動(dòng)、釋放壓測(cè)執(zhí)行節(jié)點(diǎn)，可以做到自動(dòng)伸縮容。

這個(gè)過程中其實(shí)還有許許多多的技術(shù)細(xì)節(jié)可以拿來展開說，但是鑒于文章篇幅有限就不在本文一一列舉了，有機(jī)會(huì)的話可以另開一篇詳細(xì)闡述。

運(yùn)行效果展示

基礎(chǔ)服務(wù)平臺(tái)（IaaS云）

這里我們對(duì)默認(rèn)的首頁定制成了阿里云首頁的風(fēng)格：

可視化UI的方式一鍵創(chuàng)建云主機(jī)：

支持簡(jiǎn)單編輯云網(wǎng)絡(luò)：

很容易的掛載云硬盤：

定制的操作系統(tǒng)可以輕松上傳：

支持 web VNC 訪問桌面：

傻瓜式的創(chuàng)建 k8s 集群，并支持集群擴(kuò)展：

基礎(chǔ)服務(wù)平臺(tái)（PaaS云）

基于 Kubernetes 的容器編排和管理能力，整合 DevOps 工具鏈、微服務(wù)和應(yīng)用框架，來幫助研發(fā)團(tuán)隊(duì)實(shí)現(xiàn)敏捷化的應(yīng)用交付和自動(dòng)化的運(yùn)營(yíng)管理：

集成 Ingress 授權(quán)入站連接到達(dá)集群服務(wù)的規(guī)則集合，提供七層負(fù)載均衡能力，配置提供外部可訪問的 URL、負(fù)載均衡、SSL、基于名稱的虛擬主機(jī)等。作為集群流量接入層，提供高可靠性：

基于 Git 的項(xiàng)目管理平臺(tái)。提供網(wǎng)頁版和客戶端版接口，提供給用戶空間存儲(chǔ) git 倉儲(chǔ)，保存用戶的一些數(shù)據(jù)文檔或者代碼等數(shù)據(jù)。一個(gè)開源的分布式版本控制系統(tǒng)，用于處理項(xiàng)目中的版本迭代問題：

實(shí)現(xiàn)缺陷和問題跟蹤；提供高效方式規(guī)劃、可視化和管理研發(fā)工作，同時(shí)為 Scrum 和 Kanban 流程提供支持；支持多個(gè)可共享的儀表板；支持任務(wù)時(shí)間管理：

提供微服務(wù)分布式追蹤、服務(wù)網(wǎng)格遙測(cè)分析、度量聚合和可視化一體化解決方案：

提供了一組簡(jiǎn)單易用的特性集，快速實(shí)現(xiàn)動(dòng)態(tài)服務(wù)發(fā)現(xiàn)和服務(wù)監(jiān)控檢查。

SpringBoot 服務(wù)應(yīng)用可以通過 Actuator 來暴露應(yīng)用運(yùn)行過程中的各項(xiàng)指標(biāo)，Spring Boot Admin 通過這些指標(biāo)來監(jiān)控 SpringBoot 應(yīng)用，通過圖形化界面呈現(xiàn)出來：

ELK 即 Elasticsearch、Logstash、Kibana，組合起來搭建日志聚合系統(tǒng)：

微服務(wù)聚合 Swagger 文檔，支持在線接口調(diào)試：

動(dòng)態(tài)配置服務(wù)可以讓以中心化、外部化和動(dòng)態(tài)化的方式管理所有環(huán)境的應(yīng)用配置和服務(wù)配置：

提供 maven 私服和二進(jìn)制制品倉庫：

提供存儲(chǔ)、管理和分發(fā) Docker 鏡像的企業(yè)級(jí)倉庫：

代碼質(zhì)量分析平臺(tái)，便于管理代碼的質(zhì)量，可檢查出項(xiàng)目代碼的漏洞和潛在的邏輯問題。同時(shí)提供了豐富的插件，支持多種語言的檢測(cè)：

可視化UI的方式管理應(yīng)用和組件，降低了 k8s 容器云使用門檻：

web 在線編輯容器應(yīng)用：

方便查看應(yīng)用日志：

在線編輯配置文件：

通過可視化看板收集壓測(cè)結(jié)果：

k8s 集群資源監(jiān)控：

服務(wù)器資源監(jiān)控：

關(guān)系型數(shù)據(jù)庫資源監(jiān)控：

消息隊(duì)列資源監(jiān)控：

NoSQL 數(shù)據(jù)庫資源監(jiān)控：

k8s 集群數(shù)據(jù)庫資源監(jiān)控：

k8s 集群核心組件資源監(jiān)控：

應(yīng)用服務(wù)拓?fù)湔故荆?/p>

釘釘實(shí)時(shí)告警：

經(jīng)驗(yàn)心得

基于開源，擁抱開源；

盡量使用成熟的第三方平臺(tái)；

不重復(fù)造輪子；

技術(shù)棧和組件要適合研發(fā)團(tuán)隊(duì)技術(shù)能力及主流技術(shù)方向；

KISS 原則(Keep It Simple and Stupid)；

盡量考慮 ROI（投入產(chǎn)出比）；

不斷演進(jìn)迎合公司業(yè)務(wù)發(fā)展、大公司方案不一定是適合的、避免為技術(shù)而技術(shù)；

任何方案不必最求大而全和完美，實(shí)踐中不斷完善和演進(jìn)；

需求導(dǎo)向，借力開源，科學(xué)選型，快速集成，重視擴(kuò)展，演進(jìn)改善。

未來展望

在容器時(shí)代，不能只看 k8s 本身，對(duì)于企業(yè)內(nèi)的基礎(chǔ)設(shè)施，“向上”和“向下”的融合和兼容問題也很關(guān)鍵?！跋蛏稀笔敲嫦驑I(yè)務(wù)場(chǎng)景為用戶提供對(duì)接，因?yàn)槿萜鞑⒉荒苤苯臃?wù)于業(yè)務(wù)，它還涉及到如何部署應(yīng)用、服務(wù)治理、調(diào)度等諸多層面。“向下”，即容器與基礎(chǔ)設(shè)施相結(jié)合的問題，這里更多的是兼容資源類型、更強(qiáng)大的隔離性、更高的資源使用效率等都是關(guān)鍵問題；

云原生應(yīng)用管理：當(dāng)前，我們已有項(xiàng)目云原生應(yīng)用管理在生產(chǎn)環(huán)境落地，未來我們需進(jìn)一步擴(kuò)大云原生應(yīng)用的覆蓋面，不斷提升研發(fā)效率；

云原生架構(gòu)落地：推進(jìn)各個(gè)中間件、存儲(chǔ)系統(tǒng)、大數(shù)據(jù)以及核心業(yè)務(wù)合作落地各個(gè)領(lǐng)域的云原生系統(tǒng)。

參考資料：

[1]：阿里云原生架構(gòu)白皮書

[2]：基于OpenStack搭建公司私有云平臺(tái)

[3]：Kubernetes如何改變美團(tuán)的云基礎(chǔ)設(shè)施

[4]：關(guān)于Kubernetes規(guī)劃的靈魂n問

OpenStack 容器 虛擬私有云 VPC 運(yùn)維

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請(qǐng)聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時(shí)內(nèi)刪除侵權(quán)內(nèi)容。