《容器的編排和調(diào)度：計算型牛群的放牧》要點：
本文介紹了容器的編排和調(diào)度：計算型牛群的放牧，希望對您有用。如果有疑問，可以聯(lián)系我們。

原諒我打了一個可能不恰當?shù)谋确?但是我們正在越來越多地被勸說把我們的基礎設施和應用想象成家中的牲口.我們關心牲口,但是程度可能不如寵物.我們盡量不對牛群漠不關心讓它們?nèi)狈﹃P愛；我們想要它們呆在在最好的牧地上啃草；我們不時地疏散走擁擠在一起或者踏入危險區(qū)域的牛群；如果它們生病了,我們想要有獸醫(yī)能把它們照顧好直到康復.

在云原生容器平臺(cloud-native container platforms)的世界中,如果我們的應用是牧場的牲口,那編排和調(diào)度器框架扮演了所有這些照顧者的角色.一個優(yōu)秀的應用“牧民”(application “farmers”)會將資源利用率最大化,同時均衡系統(tǒng)因容錯需要不斷變化的需求.

在IT界的有一個完美的風暴正在形成,其包含三個重要的趨勢：真正可編程的基礎設施架構的崛起,這包含云,配置管理工具和容器；高適應能力應用架構的開發(fā),包含微服務的使用,大規(guī)模分布式消息/日志處理,和事件驅(qū)動的應用；新流程和新方法論的出現(xiàn),如精益和DevOps.

在所有這些革新面前,為什么我們要在乎一個容器編排和調(diào)度的主題?原因是我們應該像后農(nóng)業(yè)革命中那些成功的牧民一樣關心他們?nèi)绾畏拍僚Ｈ?

你目前采用的是哪個類型的容器牧場?

托管和部署容器化應用目前有很多的選擇,如果我們我只考慮現(xiàn)代的云平臺,我們可以把它們分成三類：基礎設施即服務(IaaS)、容器即服務(CaaS)和平臺即服務(PaaS).

根據(jù)部署的應用的差別,每個類別都有自身的強項和弱點.盡管一些機構趨向于根據(jù)直覺,分析報告或者與廠商現(xiàn)有的關系來簡單地決定使用哪一種平臺,但這是一個需要進行嚴肅評估的根本性決定.

平臺的選擇對于能實現(xiàn)哪一種編排和調(diào)度有重大的影響.下面的比較能讓你了解每一種類型提供的關鍵抽象,控制面和合適的應用場景 .需要值得注意的是,容器即服務仍然是一個存在熱烈爭議的領域 – 很多人說我們傳統(tǒng)上被稱作的容器服務也是CaaS的一種；然而,Docker建議使用一組不同的條件來認定一個CaaS方案,而這些條件中最重要的是云基礎設施不可知性(cloud infrastructure agnostic).我們認為廣闊市場對于這個產(chǎn)品類別仍然有被解釋的空間.

平臺和服務的比較

1. 基礎設施即服務(IaaS)

描述：在應用部署之前必須組合并準備好的抽象化計算資源(CPU、內(nèi)存、存儲、網(wǎng)絡等)

抽象核心：計算資源

示例：AWS、Azure、Digital Ocean、Google Cloud Platform、IBM Cloud Infrastructure、VMware

應用調(diào)度：

• 手動或者通過配置管理(CM)工具
• 資源需求通常通過基礎設施選擇和配置指定
• 容錯通常由程序?qū)崿F(xiàn)(implemented procedurally)

服務發(fā)現(xiàn)：

• 手動或者通過配置管理工具,如Puppet、Chef或Ansible
• CM工具通常與分布式的KV存儲結合,如Consul或Zookeeper,以進行服務發(fā)現(xiàn)

資源分配(provisioning)：

• 手動或者通過配置管理工具,如Puppet,Chef或者Ansible
• 操作員根據(jù)資源分配和分布來進行容錯和伸縮的措施

數(shù)據(jù)存儲/中間件：通常是數(shù)據(jù)庫即服務(DBaaS)或者自托管

典型應用場景：進行云遷移并且需要遷移內(nèi)部部署的虛擬機和同類型應用,或者需要對資源的組合和分配進行更細粒度控制的公司機構

2. 容器即服務(CaaS)/容器化服務

描述：在計算資源的基礎上提供了一層抽象以允許容器的部署和編排

抽象核心：容器

示例：CoreOS Tectonic、Docker Cloud、Google Container Engine(GKE)、HashiCorp Nomad、IBM Container Service、Joyent Triton、Mesosphere Datacenter Operation System(DCOS)

應用調(diào)度：

• 容器調(diào)度通常由平臺自帶,能力水平可能很原始可以很復雜
• 資源需求以聲明式的方式指定
• 自動處理容錯

服務發(fā)現(xiàn)：從程序式的指定方式(如在Mesos中,Registrator和srv_router)和聲明式指定方式(如Kubernete中的service和label)

資源分配(provisioning)：

• 通常由平臺自帶,并且有如bin-packing and spread等算法來最大化資源利用率和容錯
• 容器實例的伸縮可以通過平臺實現(xiàn)

數(shù)據(jù)存儲/中間件：通常是基于IaaS的DBaaS,也有可能供容器化的數(shù)據(jù)庫

典型應用場景：已經(jīng)在開發(fā)云原生的應用,并且想從IaaS的運維復雜度中解放出來,但是不想使用那些不合胃口的PaaS的公司.

3. 平臺即服務(PaaS)

描述：在計算基礎設施上提供了一層抽象允許應用的部署和編排

抽象核心：應用

示例：AWS Elastic Beanstalk、Deis、Google App Engine、Heroku、IBM Bluemix、Pivotal Cloud Platform、Red Hat OpenShift

應用調(diào)度：

• 平臺自帶
• 資源需求以聲明式的方式指定
• 自動處理容錯

服務發(fā)現(xiàn)：通常平臺自帶,如服務發(fā)現(xiàn)“作為一個服務”提供

資源分配(provisioning)：

• 對用戶不可見
• 費用開銷通常基于資源的分配和消耗情況

數(shù)據(jù)存儲/中間件：作為平臺的一部分進行提供,例如,作為一個服務的代理(broker)

典型應用場景：可以是那些想要削減維護平臺基礎設施的創(chuàng)業(yè)公司,也可以是尋求標準化流程和提升開發(fā)者效率的大規(guī)模機構.

順著我們之前放牧的比方,我們把計算資源(CPU、內(nèi)存、磁盤、網(wǎng)絡等)想象成我們的牲口吃草玩耍的牧地.編排和調(diào)度的角色就是將應用和資源匹配,就如將牲口匹配到牧地,并保證方式以最有力有效.第一眼看,將應用高效地匹配到資源可能感覺不是特別困難,但是用解決裝箱問題(bin-packing)的方式來優(yōu)化資源利用率在計算上一個NP-hard問題.再加上下面易失和臨時的云網(wǎng)絡,我們面對的絕對是一個困難的挑戰(zhàn).

圈養(yǎng)容器化的牲畜

從一個IaaS創(chuàng)建一個容器化的應用好比買一款空地然后從頭開始修建你的牧場 – 這十分的費勁,但是你擁有最大程度的控制.而利用CaaS就像購買一塊牧場,然后雇傭?qū)I(yè)的牧人來搭建圍欄并且看管牲口.這讓你有對土地的可見性,聲明你的想法,并且不需要自己做即時即地的決定.在PaaS上部署應用好比實際將牲口付托給另外的牧民.可以說,這樣這就有多余的精力去關注真正值得關注的事情(購買并且培育最好的牲畜,最快的把你的牛推向市場),但是你可能就不知道牧地上都發(fā)生了什么事情,而且你可能不贊成其他牧民管理牧場的方式.

在我們的OpenCredo的工作日子里,我們和多個客戶一起設計,構建并且管理容器化的應用和平臺.下面的部分是我們經(jīng)歷的兩個案例的分享.這些例子用來說明在創(chuàng)建這些編排的技術棧的時候經(jīng)歷的決策過程.

在Mesos和Google Cloud Platform上運行Spring Boot Services

對于我們的第一個客戶,我們實現(xiàn)的編排器是Apache Mesos.客戶期望能混合持久運行的容器化應用服務和基于Spark的批量數(shù)據(jù)處理.Mesos自身實際上就是一個“數(shù)據(jù)中心內(nèi)核”,因為它把計算資源從基礎設施集群抽象了出來,并且把這些資源提供給了框架,比如讓Mesosphere的Marathon運行持久運行服務,Chronos執(zhí)行批量式任務,讓Spark處理數(shù)據(jù)處理的工作量.部署和運行Mesos是一件運維復雜的事情；然而它已經(jīng)被證明可以在大規(guī)模使用,它受到了Twitter,Airbnb和eBay的喜愛,可以混合不同類型的工作量,可以跨整個數(shù)據(jù)中心調(diào)度應用,這些對于客戶來說都是非常有吸引力的提案.

Mesos通過Ansible進行部署和管理,并且通過Jenkins來構建容器化應用并且部署進Marathon框架.服務發(fā)現(xiàn)通過結合Consul、Registrator和srv_router來實現(xiàn),而因為容錯進行的服務重啟或者重新分配是由Marathon提供的.QA團隊可以在Google Cloud Platform中啟動自己的的Mesos平臺實例,這可以減少資源競爭以加快測試(這在之前是一個問題).然而,我們吸取到了幾個嚴重的教訓,因為個人的環(huán)境資源受限和完整的平臺是以不同方式調(diào)度工作量的.例如,在一個單機器組成的集群中運行多個Mesos框架通常導致其中一個框架資源耗盡.

在AWS Kubenernetes上部署基于Go的微服務

在這個項目中,Kubenernetes通過Terraform和Ansible被部署到了AWS上,主要的目的是為開發(fā)者提供IaaS之上一層的抽象,讓他們無需在PaaS花大工夫. Google Container Engine因為客戶端/廠商的限制無法使用.很容易說大多數(shù)的機構會最終構建某一種形式的PaaS,因為很多PaaS的特性對于一個典型的開發(fā)團隊是必要的,如測試,部署,服務發(fā)現(xiàn),存儲,數(shù)據(jù)庫集成和開發(fā)者社區(qū)引導.相應的,這個案例確實也實現(xiàn)了很多這種特性.

Kubenenetes提供了命名空間的隔離,這對于在同一個集群上運行多個測試和staging的部署有用.分隔的集群被用來做真正的隔離.部署是通過集成Kubenernetes API的或者kubectl CLI工具來管理的.持續(xù)集成使用的是Jenkins框架,它也負責構建和測試我們應用服務.服務發(fā)現(xiàn)由Kubernetes自帶,開箱即用.因為具備Node健康檢查和應用/容器級別的活動性探針健康檢查,其也提供了良好的容錯.其底層的IaaS層也提供了存儲和數(shù)據(jù)庫集成,并且結合版本控制系統(tǒng)和一個內(nèi)維護良好的wiki,開發(fā)模式得到很好的共享和重用.

在我們牧場上得到的教訓

這篇文章的目的是基于你自己的需求,和相應的編排和調(diào)度機制,提供一些容器平臺選擇的參考.然而,這主要基于兩個客戶示例案例研究.有很多其他的產(chǎn)品組合及由其催生的技術棧,包括全部混雜使用Docker Swarm和Mesos(https://mesosphere.com/blog/2015/05/20/hyperscaling-docker-swarm-with-mesos-mesosphere-hackweek/),包括IBM的基于PaaS的云編排(http://www-03.ibm.com/software/products/en/ibm-cloud-orchestrator).

這里是一些我們在OpenCredo目前為止學習到的主要的學習經(jīng)驗：

工具鏈

• 盡可能的自動自動化,這可以節(jié)省時間,可以大規(guī)模的重用,可以減少基礎設施和配置的差異.
• 不鼓勵但是允許人工的干預,特別是當把尚處于新興階段的容器技術引入到公司的時候.我們都知道不應該直接SSH到生產(chǎn)環(huán)境的主機上,但是保留這個入口作為一種救命稻草,可能會在關鍵時候挽拯救你的商業(yè).

性能錯誤

• 語法錯誤,又被稱作“對業(yè)務造成影響(business impact)”錯誤,在云和容器的世界里尤其重要,甚至比底層的基礎設施錯誤更加的重要.即使你一半的生產(chǎn)環(huán)境都掛掉了也沒關系,只要你的系統(tǒng)仍然能優(yōu)雅的降級并讓客戶正常獲取價值.我們經(jīng)常看到運維團隊被基礎設施錯誤警報淹沒,但是他們不知道實際的對用戶造成的影響.
• 了解Brendan Gregg的USE(Utilization、Saturation and Error,即利用率、飽和量和錯誤數(shù))方法論和Tom Wilie的RED(Rate、Error and Duration,即請求頻率、錯誤頻次和時長分布)方法論.我們發(fā)現(xiàn)這些方法對于解決性能的問題特別的有用.

監(jiān)控和資源競爭

• 在所有的層次都需要具備可見性.容器監(jiān)控和管理是任何在生產(chǎn)環(huán)境中使用容器方案的公司應主要擔心的問題.
• 正確地編寫程序,只對于必要的信息記錄日志.
• 提供業(yè)務層(語義)的指標.這有助于促進關鍵的相關利益者的采納度,也會有助于解決故障.
• 網(wǎng)絡：確保正確地規(guī)劃計算實例的大小.例如,你的應用只需要一個小型實例提供的CPU和內(nèi)存就夠了,但是你配置了相應的網(wǎng)絡帶寬了嗎?
• 一定要對于磁盤和CPU層進行全面的監(jiān)控.對于CPU,如果你部署的是一個公有云,那請留意被偷竊時間(http://iamondemand.com/blog/who-stole-my-cpu/).
• 熵的缺少(lack of entropy)是很難調(diào)試的問題,在容器化的環(huán)境中經(jīng)常出奇的看到多個容器在爭奪主機的/dev/random.容器化的應用通常會不明所以就掛起(hang住),而在調(diào)試的時候回發(fā)現(xiàn)是一個安全方面的操作(如：會話或者加密的令牌生成操作)阻塞了它.

文/鐘最龍?譯

文章出處：Docker微信公眾號

轉(zhuǎn)載請注明本頁網(wǎng)址：
http://www.snjht.com/jiaocheng/4504.html