【個人Linux，我作主！】DevOps文化及kubernetes概述

（1）DevOps文化
DevOps即運維自動化，目前在國外，互聯網巨頭如Google、Amazon、Facebook、LinkedIn、Netflix、Airbnb，傳統軟件公司如Adobe、IBM、微軟、SAP等，亦或是網絡業務非核心企業如蘋果、沃爾瑪、可口可樂、星巴克等都在採用DevOps或提供相關支持產品。那麼DevOps到底是怎樣一回事呢。
DevOps一詞來自於Development和Operations的組合，突出重視軟件開發人員和運維人員的溝通合做，經過自動化流程來使得軟件構建、測試、發佈更加快捷、頻繁和可靠。DevOps概念早先升溫於2009年的歐洲，因傳統模式的運維之痛而生。DevOps是爲了填補開發端和運維端之間的信息鴻溝，改善團隊之間的協做關係。不過須要澄清的一點是，開發到運維，中間還有測試環節。DevOps其實包含了三個部分：開發、測試和運維。換句話說，DevOps但願作到的是軟件產品交付過程當中IT工具鏈的打通，使得各個團隊減小時間損耗，更加高效地協同工做。
應用程序的架構在早期是單體架構，在早期應用程序是比較簡單的，因此仍是能夠招架住，可是到後來人們發現單體應用程序難以承載愈來愈複雜的系統，就算能夠橫向擴展，可是單體應用的內部業務複雜度也會致使擴展很容易達到上限，因此單體的下一個時代就是分層架構，讓應用程序各自分離開開發；再日後就是微服務，不是在簡單的分層，而是把每個應用都拆解成一個微小的服務，只幹一件事，因此一個傳統的3級應用程序須要拆解成數百個微型服務，讓彼此之間進行協做。所以微服務自然的和容器很是契合，由於容器在分發、構建、部署起來都是很是方便的，因此把爲服務和對應的容器結合起來後迅速的讓它們找到了適合於落地的實現方案。包括DevOps理念也是如此，早期的DevOps技術中的交互環節和部署環節由於環境因素異構致使部署起來及其困難，由於docker技術的出現恰好彌補了這個裂縫，使得DevOps很是容易實現了。
在DevOps中有三種概念，其中第一個CI（CONTINUOUS INTEGRATION）是指持續集成，它屬於開發人員的自動化流程，成功的CI意味着應用代碼的更新會按期構建、測試併合併到共享存儲庫中，該解決方案能夠解決在一次開發中有太多應用分支，從而致使相互衝突的問題；第二個CD（CONTINUOUS DELIVERY）是指持續交付，一般是指開發人員對應用的更改會自動進行錯誤測試並上傳到存儲庫，而後由運維團隊將其部署到實時生產環境中。這旨在解決開發和運維團隊之間可見性及溝通較差的問題，所以持續交付的目的就是確保儘量減小部署新代碼時所需的工做量；第三個CD（CONTINUOUS DEPLOYMENT）是持續部署，指的是自動將開發人員的更改從存儲庫發佈到生產環境，以供客戶使用，它主要是爲了解決因手動流程下降應用交付速度，從而提升運維團隊超負荷的問題，持續部署以持續交付的優點爲根基，實現了管道後續階段的自動化。

由上所述，相信你們對DevOps有了必定的瞭解。可是除了觸及工具鏈以外，做爲文化和技術的方法論，DevOps還須要公司在組織文化上的變革。回顧軟件行業的研發模式，能夠發現大體有三個階段：瀑布式開發、敏捷開發、DevOps。DevOps早在十幾年前就有人提出來，可是爲何最近纔開始受到愈來愈多的企業重視和實踐呢？由於DevOps的發展是獨木不成林的，如今有愈來愈多的技術支撐。微服務架構理念、容器技術使得DevOps的實施變得更加容易，計算能力和雲環境的發展使得快速開發的產品能夠馬上得到更普遍的使用。
那麼DevOps的好處是什麼呢？它的一個巨大的好處就是能夠高效交付，這也正好是它的初衷。Puppet和DevOps Research and Assessment（DORA）主辦了2016年DevOps調查報告中，根據全球4600位各IT公司的技術工做者的提交數據統計，得出高效公司能夠完成平均每一年1460次部署。與低效組織相比，高效組織的部署頻繁200倍，產品投入使用速度快2555倍，服務恢復速度快24倍。在工做內容的時間分配上，低效者多花22%的時間用在爲規劃好或者重複工做上，而高效者卻能夠多花29%的時間用在新的工做上。因此這裏的高效不只僅指公司產出的效率提升，還指員工的工做質量獲得提高。DevOps另一個好處就是會改善公司組織文化、提升員工的參與感。員工們變得更高效，也更有知足和成就感；調查顯示高效員工的僱員淨推薦值更高，即對公司更加認同。
那麼DevOps爲何會興起呢？第一，首先條件成熟，技術的發展使得DevOps有了更多的配合。早期時，你們雖然意識到這個問題，可是苦於當時沒有完善豐富的技術工具，是一種理想很豐滿的狀況。DevOps的實現能夠基於新興的容器技術；也能夠在自動化運維工具Puppet、SaltStack、Ansible以後的延伸；還能夠構建在傳統的Cloud Foundry、OpenShift等PaaS廠商之上。第二，是來自市場的外部需求，IT行業已經愈來愈於市場的經濟發展緊密掛鉤，專家們認爲IT將會由支持中心變成利潤驅動中心。事實上，這個變化已經開始了，這不只體如今Google、蘋果這些大企業中，並且也發生在傳統行業中，好比出租車業務中的Uber、酒店連鎖行業中的Airbnb、圖書經銷商Amazon等。可否讓公司的IT配套方案及時跟上市場需求的步伐，在今天顯得相當重要。第三，對於工程師而言，他們也是DevOps的受益者。工具鏈的打通使得開發者們在交付軟件時能夠完成生產環境的構建、測試和運行，正如Amazon的CTO那句讓人印象深入的話：「誰開發誰運行。」（You build it,you run it）
（2）kubernetes概述
Kubernetes是Google開源的一個容器編排引擎，它支持自動化部署、大規模可伸縮、應用容器化管理。在生產環境中部署一個應用程序時，一般要部署該應用的多個實例以便對應用請求進行負載均衡，
Kubernetes，又稱爲k8s或者簡稱爲「kube」，是一種可自動實施Linux容器操做的開源平臺。它能夠幫助用戶省去應用容器化過程的許多手動部署和擴展操做。也就是說，您能夠將運行Linux容器的多組主機彙集在一塊兒，由Kubernetes幫助您輕鬆高效地管理這些集羣。並且，這些集羣可跨公共雲、私有云或混合雲部署主機。所以，對於要求快速擴展的雲原生應用而言（例如藉助Apache Kafka進行的實時數據流處理），Kubernetes是理想的託管平臺。
Kubernetes最初由Google的工程師開發和設計。Google是最先研發Linux容器技術的企業之一（組件了cgroups），曾公開分享介紹Google如何將一切都運行於容器之中（這個是Google雲服務背後的技術）。Google每週會啓用超過20億個容器--所有由內部平臺Borg支撐。Borg是Kubernetes的前身，多年來開發Borg的經驗教訓成了影響Kubernetes中許多技術的主要因素。
爲何須要Kubernetes呢？真正的生產型應用會涉及多個容器。這些容器必須跨多個服務器主機進行部署。容器安全性須要多層部署，所以可能會比較複雜。但Kubernetes有助於解決這一問題。Kubernetes能夠提供所需的編排和管理功能，以便您針對這些工做負載大規模部署容器。藉助Kubernetes編排功能，您能夠構建多個容器的應用服務、跨集羣調度、擴展這些容器，並長期持續管理這些容器的健康情況。有了Kubernetes，您即可切實採起一些措施來提升IT安全性。Kubernetes還須要與聯網、存儲、安全性、遙測和其餘服務整合，以提供全面的容器基礎架構。
Redhat公司目前也已經花大價錢壓住在容器編排工具之上了，同時這個也體如今Kubernetes已經成爲了紅帽產品中的PaaS，你們知道Kubernetes屬於開源技術，因此，沒有正式的技術支持機構能夠爲您的商業業務提供支持。若是生產過程當中Kubernetes出現實施問題，您必定會感到很是擔憂，您的客戶可能也會如此。這時就是企業Kubernetes容器平臺大展身手的時候了。OpenShift是企業版的Kubernetes，此外，它還具有更多功能。OpenShift引入了額外的先進技術，從而使Kubernetes成爲可供企業使用的強大平臺，這些技術包括：註冊表、聯網、遙測、安全性、自動化和服務。藉助OpenShift的可擴展性以及控制和編排功能，您的開發人員能夠構建新的容器化應用、對其進行託管並在雲端加以部署，從而輕鬆快速地將各類奇思妙想轉變爲新業務。這些都是由開源領域的領導者紅帽所開發，並提供全面支持的。
Kubernetes的代碼託管在GitHub之上，官方站點爲https://github.com/kubernetes ，咱們能夠看到目前K8S版本的迭代速度。同時亞馬遜的AWS、微軟的Azure、阿里雲等大型雲廠商也已經宣佈原生支持K8S。

（3）Kubernetes的特性
Kubernetes的主要特性主要體如今，第一它可以實現自動裝箱，基於資源依賴以及其餘約束可以自動完成容器的部署並且不影響其可用性。第二是可以實現自我修復，一旦一個容器崩潰了，能夠在一秒中啓動，把缺失的服務kill掉從新起一個就能夠了，因此有了Kubernetes容器編排平臺之後，咱們更多關注的是羣體，而再也不是個體了。第三是能自動實現水平擴展，一個容器不夠能夠再起一個，不斷的進行向上擴展，只要物理平臺的資源是足夠的，它還可以實現自動的服務發現和負載均衡，同時還可以實現自動的發佈和回滾。第四個是能夠支持密鑰的配置和管理，咱們若是啓動了一個容器後，但願換一種配置來運行，咱們定義一個ENTRYPOINT腳本，這個腳本可以接受用戶傳遞給容器一些變量，把這些變量的值轉換爲容器內的應用程序可讀取的配置信息，從而完成容器化應用配置，這是由於早期的應用程序不是面向雲原生而開發的，因此那些應用程序須要讀取配置文件來獲取配置，而云原生開發的最好能基於環境變量獲取配置，若是咱們使用容器編排平臺讓容器啓動自動化了，但每一次啓動還要手工傳環境變量的值這是一個很麻煩的事，因此咱們須要一個外部的組件保存這些配置信息於外部，當鏡像啓動爲容器時，咱們只須要讓鏡像加載配置中心當中的配置信息就能夠完成配置。第五個是Kubernetes還能實現存儲編排，讓存儲卷實現動態供給，也就意味着某一個容器須要用到存儲卷時根據容器自身的需求建立可以知足它的須要的存儲卷，從而實現存儲編排。第六個是可以實現任務的批處理運行。
（4）Kubernetes的架構
Kubernetes其實就是一個集羣，要組合多臺主機的資源整合成一個大的資源池統一對外提供計算、存儲等能力的集羣。咱們在許多臺主機上都安裝上Kubernetes的相關應用程序，並經過應用程序協同工做，把多個主機當一臺主機來使用。可是在Kubernetes當中集羣是分角色的，咱們知道模型一般分爲兩種，一種是P2P的，例如redis沒有中心節點，每個節點自己都可以直接接受服務請求，能路由請求的這種模型，第二種是由中心節點的集羣，例如MySQL的主從複製，有一個節點是主節點，其餘的都和它進行同步，那麼K8S就是一個有中心節點架構的集羣系統，即master/nodes模型，master主節點通常不須要太多，通常可以作冗餘有3個就足夠了，而nodes咱們稱之爲worker，就相似於蜂王和工蜂的概念。客戶端的請求先發送給Master，Master中會有一個調度器去分析各node現有的可用資源狀態，找一個最佳適配運行用戶所請求的容器的節點，並把它調度上去，由這個node本地的容器引擎負責把docker啓動起來，這個node負責啓動容器時先檢查是否本地是否有鏡像，若是沒有須要到Registry將鏡像拖下來，固然咱們也能夠建私有Registry，並且Registry本身也能夠是一個容器，咱們能夠把私有Registry託管在Kubernetes自身之上。

在Kubernetes上第一個組件名爲API Server，能夠負責接收請求、解析請求、處理請求。第二個組件爲，若是用戶的請求時建立一個容器，那麼這個容器不該該運行在Master之上，而應該運行在Node之上，那麼哪個Node更合用，這個應該是由Master之上的組件scheduler調度器來決定，它負責去觀測每個Node上的總共計算資源，並根據用戶所請求容器所需建立的資源量的下限來評估哪個Node節點最合適。咱們不能根據容器中的應用程序運行與否判斷容器的健康與否，咱們能夠根據額外定義的可用性探測機制來探測服務的可用性，若是一旦容器中的應用掛了，咱們又須要容器始終是運行的，在Node之上有一個應用程序，第三個就是kubelet，這個應用程序就是確保容器始終處於運行狀態的。Kubernetes還運行了不少控制器的應用程序，負責去監控所管理的每個容器是不是健康的，一旦發現容器是不健康的，控制器就向Master的API Server發請求，而後由scheduler調度從其餘節點挑一個合適的並從新起一個容器。用於監控容器健康的控制器不健康了，那麼容器的健康也就沒法獲得保證了，因此在Master之上還有第四個組件控制器管理器（Controller-Manager），由控制器管理器負責監控每個控制器是否健康的，若是控制器不健康了，由控制器管理器確保它是健康的，而控制器管理器（Controller-Manager）則是經過冗餘來保證其自身的可用性。因此從這個角度說Master是集羣的大腦，它有如上的幾個核心組件。
在K8S之上運行的最小單元不在是容器，Pod是K8S之上調度的最小的邏輯單元。在Pod內能夠運行容器，一個Pod內包含多個容器，衆多容器共享同一個UTS、Network、IPC三個名稱空間，而另外三個User、Mount、PID三個名稱空間是互相隔離的。並且同一個Pod內的各容器還共享第二種資源即存儲卷，存儲卷不在屬於容器，存儲卷是屬於Pod的。通常來講同一個Pod只包含一個容器，除非容器之間有很是緊密的關係須要放在同一個Pod中。若是一個Pod中須要放多個容器，一般有一個容器是主容器，其餘容器是輔助主容器中的應用程序完成更多功能而存在的，例如主容器中運行Nginx，會生成不少日誌，這時候就能夠在輔助的容器（邊車）中運行ELK等日誌收集程序。因此調度器調度的是一個Pod，Node運行的也是一個Pod，而Pod是一個原子單元。

理論上說Node能夠是任何形式的計算設備，只要可以有傳統意義上的CPU、內存等，而且能裝上Kubernetes的集羣代理程序，均可以做爲Kubernetes的一個份子來進行工做。例以下圖，全部的node節點做爲一個總體看做爲一個大的計算池使用，有x個CPU和y容量的內存，由Kube_Cluster來統一管理的，Master就擁有這樣一個統一的視圖，當用戶請求在Master建立資源時，咱們能夠作一個統一資源池的調度和評估，這樣一來終端用戶就無需再關心咱們的資源是運行在哪一個節點上了，因此就實現了雲計算。

若是未來咱們想分類管理某一類Pod，咱們應該怎麼挑選出來某一類統一功能的Pod呢，爲了可以作Pod識別，咱們須要在Pod之上附加一些元數據，即key-value類型的標籤，在建立完Pod的時候能夠給Pod打上標籤，讓人能夠基於標籤的值來識別出Pod來，例如咱們建立4個Nginx的Pod，咱們給每一個Pod加一個標籤叫App，而後它的值是nginx，這樣之後咱們根據鍵和值信息就能夠把一類的Pod分揀出來了，因此這個篩選的機制咱們是靠一個組件標籤選擇器（Label Selector）來實現的。

—————— 本文至此結束，感謝閱讀 ——————