經典干貨:容器云平臺運維學習思路和方法

軟件運維不是靠赤手空拳,從效率方面講借助于工具的運維效率是成級數(shù)倍的。因此需要熟練掌握和使用運維工具,運維方法。

本文來自微信公眾號“twt企業(yè)IT社區(qū)”,作者/汪照輝。

一、容器云平臺運維范圍

不同的公司容器云平臺的建設思路和方法可能是不同的,會有差別,但對運維人員來說,首先要明白運維的范圍和內容。

(一)梳理要運維哪些內容

作為運維人員最重要的職責是采用一切合適的方法保障系統(tǒng)的正常運行,從而保障業(yè)務的正常運營。一旦系統(tǒng)出現(xiàn)問題了,就會影響到業(yè)務,可能影響到客戶,可能會帶來損失,因此運維人員要對自己的運維內容有清晰的認識。才能定義設計合適的部署架構,運維架構。

容器云平臺運維可能包括基礎設施資源運維,比如服務器、存儲、網絡層、操作系統(tǒng)等,也包括容器云平臺自身的運維,Docker,kubernetes,鏡像倉庫,Portal、數(shù)據(jù)庫、ETCD、ingress等,還會涉及日志、監(jiān)控、告警、認證權限、配置等,更重要的是支撐應用的運維,應用的部署、遷移、運行狀況查看、監(jiān)控、告警提醒、擴容、彈性伸縮、配置更新、流量分發(fā)管控、負載均衡、訪問控制等等都是容器云平臺制成應用運維的能力。

(二)明確運維的工具和手段

軟件運維不是靠赤手空拳,從效率方面講借助于工具的運維效率是成級數(shù)倍的。因此需要熟練掌握和使用運維工具,運維方法。

Google SRE其實就是一個專職做運維工具的團隊,借助于工具化不但提高運維效率,也提高了系統(tǒng)的穩(wěn)定性和可靠性。自動化運維工具、監(jiān)控工具、配置管理工具等等都是在日常運維過程中不可少的。

(三)選擇運維架構

不同的系統(tǒng)運維方法和運維架構也是不一樣。容器云平臺有其獨特的特點,不同于傳統(tǒng)系統(tǒng)的運維。對運維人員來說,最大的要求就是確定性。容器的彈性、自恢復、自動遷移等特性在帶來便利的同時也帶來了不確定性。特別是在龐大的云計算環(huán)境。不確定性會對運維人員來說面臨著巨大的壓力。因此作為運維人員就需要選擇合適的架構來規(guī)避不確定性和不穩(wěn)定性。結合容器云平臺的特性和API網關組成兩層服務治理體系,在提高安全性和可靠性的同時也充分利用了容器的輕量彈性特點。

(四)開發(fā)測試和運維工作的差別在哪

我們都知道做運維和開發(fā)測試工作是不一樣的。開發(fā)追求敏捷、快速,所以這些年DevOps大行其道。但運維可能就是另外一個方向了。運維追求的是穩(wěn)定與可靠性,每次變動都會存儲風險,所以盡可能穩(wěn)定。但完全穩(wěn)定是不可能的,運維就需要實現(xiàn)一種動態(tài)的穩(wěn)定,這和容器的彈性和可遷移性非常匹配。

(五)DevOps和SRE的精髓在哪里

DevOps追求開發(fā)運維一體化,但在國內并沒有多少人真正思考DevOps該如何落地。Google SRE我覺得是一種非常好的實踐,他并沒有要求開發(fā)人員去做運維,而是很多運維人員去做開發(fā),而開發(fā)的主要是運維工具。所以我們看到國內很多DevOps的宣傳其實都是很片面的,并不是基于實踐的總結,而是概念的炒作。當前云計算環(huán)境下的運維已經不同于傳統(tǒng)的應用系統(tǒng)運維。當前應用系統(tǒng)逐步的融合、微服務化,以云計算為底座,云就像一個大的容器,docker是這個大的容器中的小容器,承載微服務應用的敏捷部署和彈性伸縮等能力。

所以運維重點還是要保障系統(tǒng)的穩(wěn)定性,但側重在采用或自主開發(fā)眾多的、適合自己的運維工具來協(xié)助提升運維效率和系統(tǒng)穩(wěn)定性。

其實,認真想一下,誰開發(fā)誰運維,一個開發(fā)人員能開發(fā)幾個服務幾個應用?開發(fā)和運維的工作量基本上是2:8,所以一個開發(fā)人員如果同時也做運維的話,就會陷入運維之中,也無法體現(xiàn)效率。

二、運維架構設計

基于上面的思考,那么對于容器云平臺來說,該如何設計其運維架構?首先鏡像倉庫是一個神一般的存在,用好鏡像倉庫將非常省力。

(一)鏡像倉庫的作用

一個鏡像倉庫可以同時配置給不同的集群,甚至不同的容器云平臺。這些集群和平臺是可以共用同一個鏡像倉庫的?;谶@些考慮,我們就把鏡像倉庫作為容器云平臺不同環(huán)境之間的媒介。測試鏡像庫隔離開發(fā)和測試,生產鏡像庫隔離測試和生產,鏡像倉庫之間可以實現(xiàn)鏡像的同步,或者下載上傳操作。

鏡像保證了在不同環(huán)境中部署的環(huán)境一致性。實現(xiàn)了應用分發(fā)的標準化。而存儲鏡像的鏡像倉庫就很好的充當起應用標準化接收和分發(fā)的能力。鏡像倉庫就可以作為一個中轉連接站,將開發(fā)、測試、生產隔離,在提高安全性的同時也提高了穩(wěn)定性。

(二)實踐SRE

SRE非常注重運維人員的開發(fā)能力,而不是開發(fā)人員的運維能力。所以SRE其實是全能人才。在國內很多人對運維有誤解,覺得不懂開發(fā)的人才去做運維。如何提升運維的效率是運維人員需要關注的問題。而采用工具,自動化是必要的運維手段。為了更好的使專業(yè)的人員去做專業(yè)的工作,將資源運維與應用運維分離。

(三)運維分層

從運維的內容我們知道,運維從基礎設施資源、到平臺、到應用的維護都是運維人員的工作內容。所以作為運維人員要維護這么多內容,往往是比較困難的,所以一個比較好的方法是把運維內容劃分為不同的層次,基礎設施資源、平臺、應用。這樣運維人員可以更專注自己的工作,更好的提供服務。

(四)接口標準化

要高效協(xié)同,定義標準化接口是必須的。就像基礎設施資源團隊提供基礎設施資源服務,需要標準化的虛擬機接口服務(云管平臺來實現(xiàn)),這樣才能做到敏捷擴展,或者動態(tài)擴容。

(五)流程自動化

運維架構中要想提高運維效率,就需要考慮運維流程的自動化,減少人為的介入和干預。比如虛擬機申請,盡量不要眾多的審批節(jié)點。完全自動化。像ip地址網段、虛擬機配置、操作系統(tǒng)參數(shù)調整等都可以在擴容虛擬機之前定義好,根據(jù)不同的需求自動來創(chuàng)建分配(按規(guī)則定義自動化創(chuàng)建)。

(六)將資源運維與應用運維分離

資源運維相對比較簡單,就是運維我們常用的服務器、網絡、存儲、虛擬化、超融合等基礎設施資源。這些工作大部分是相對標準化的,通??梢圆捎米詣踊绞絹韺崿F(xiàn)。也沒有太多的開發(fā)工作量,基本上有一套監(jiān)控管理系統(tǒng)就可以了。不過隨著多云資源管理需求的普及,多云資源管理可能會有一些復雜度。

資源運維同樣需要不同專業(yè)的人員,比如網絡、存儲、虛擬化等。這些人員專注于基礎設施資源的維護,為容器云平臺或容器化PaaS平臺提供資源服務。

(七)應用運維是核心

我們一直覺得應用運維才是容器云平臺的核心。因為最終是為業(yè)務應用來服務的。應用運維通常是在平臺提供的應用管理的能力下,由業(yè)務應用使用團隊來負責應用的運維,研發(fā)團隊給予支持。容器云平臺的能力就成為了關鍵。如果容器云平臺能提供完善的部署、監(jiān)控、彈性擴容、灰度、負載策略、訪問控制、統(tǒng)計查詢等等能力,對應用運維人員則使運維工作非常簡單。

(八)平臺和組件支撐應用運維

容器云平臺的能力在于平臺和平臺周邊組件所實現(xiàn)的能力。平臺和組件需要持續(xù)的完善和優(yōu)化,才能更好的支撐應用運維的需要。我們覺得這是容器云平臺運維的重點。需要容器云平臺運維團隊來持續(xù)的開發(fā)和建設運維工具、流程、方法來優(yōu)化容器云平臺運維。

(九)微服務架構微服務治理是難點

應用運維中,微服務架構下,服務治理可能是個難點。微服務架構帶來了服務運維的復雜度,服務的部署、遷移、彈性伸縮、流量分發(fā)、內外部負載均衡、高可用、穩(wěn)定性等需求對容器云平臺支撐的應用運維能力要求很高。選擇了什么樣的微服務架構,如何更好的管理治理好微服務,是容器云平臺不得不考慮的一個重要問題。比如微服務中實現(xiàn)了注冊發(fā)現(xiàn),比如用springcloud的開發(fā)框架,已經有了一套自己的服務治理方法,如何跟容器云平臺更好的融合?開發(fā)的微服務是否需要自己去實現(xiàn)注冊發(fā)現(xiàn),流量控制,熔斷降級等機制,或是簡單可以在容器云平臺來實現(xiàn)?

我們有個需求是根據(jù)響應時間來彈性擴容。我們沒有采用cpu內存作為彈性伸縮的指標,因為cpu內存是不準確的。Java內存機制不適合采用內存方式,而cpu變化又太快,如果拉長時間則可能導致延誤,出現(xiàn)大量超時。所以根據(jù)響應時間作為擴容指標則相對更優(yōu)。那么這就需要在服務網關或容器云平臺或者api網關來實現(xiàn)了。服務網關的話需要開發(fā)人員自己實現(xiàn),每個團隊都需要部署個這么的網關,明顯不合適。在容器云平臺如果實現(xiàn)這樣的能力,則每個服務都可以直接使用。形成了標準化。

因此,在容器云平臺可以把服務治理能力固化,既可以減少開發(fā)工作量,也提高了運維的效率,降低了運維的難度。

(十)兩層治理體系

把服務治理劃分為容器云平臺層和API網關層則可以更好的利用容器的特點,同時又保留了虛擬化部署、物理服務器部署的應用服務治理的需求。

360截圖16251112669372.png

在傳統(tǒng)企業(yè)向云遷移的過程中,還有眾多的系統(tǒng)可能不適合容器化,或者目前階段不能完全容器化(穩(wěn)定壓倒一切),因此目前可以考慮利用API網關來實現(xiàn)兩層的微服務治理體系,更好的管理和維護微服務應用。

總的來說,我們定義了容器云平臺的“鏡像倉庫為媒介,將開發(fā)測試運維分離,應用管理為核心,將資源運維、平臺運維和應用運維分析,實現(xiàn)容器云/API網關兩次服務治理體系,既利用容器的優(yōu)點,也盡可能規(guī)避其弱點”。

THEEND

最新評論(評論僅代表用戶觀點)

更多
暫無評論