簡介

你可能經(jīng)常在公司聽說Kubernetes，這項源自于Google的容器編排技術(shù)現(xiàn)在非?；?，似乎不論是Devops還是CTO，不論他們是否完全理解這項技術(shù)，他們都在談?wù)撍Ｗx了這篇文章可能會使您更加困惑，有可能您無法完全理解。有人寄希望于Kubernetes可以幫助他解決所有問題，但是事實并非如此。在這篇文章中，我會重點介紹幾個關(guān)鍵因素，來幫助您決定是否采用Kubernetes以及采用到何種程度。我還將為您提供一個方法對Kubernetes進行一步步的評估并逐步引入到您的組織之中， Kubernetes是一項偉大的技術(shù)，如果使用得當，它會帶來很大益處。

[[312753]]

1. 從寵物到羊群

> 過去服務(wù)就像寵物一樣，需要管理員一個個管理維護，現(xiàn)在服務(wù)器更像是羊群，管理員通過簡單的命令或者配置就可以管理大量的服務(wù)器。

曾幾何時，系統(tǒng)管理員用主機名和便簽來管理服務(wù)器，如今，我們并不知道我們的工作負載運行在哪種類型的服務(wù)器上，因為這些本來應(yīng)該躺在機房以及數(shù)據(jù)中心的機器已經(jīng)讓位給像是 亞馬遜，微軟以及谷歌這些公有云提供商了。系統(tǒng)管理員的確像以前一樣為運行在公共云上的虛擬機命名，就像他們養(yǎng)寵物一樣。但在過去如果銷售人員需要服務(wù)器時，系統(tǒng)管理員可能需要花費數(shù)周的時間，然后通過電話或電子郵件與銷售人員交談以進行配置。但是隨著高性能虛擬化和公有云API的出現(xiàn)，一個簡單的API調(diào)用可以在幾秒鐘內(nèi)啟動機器。聰明的技術(shù)人員意識到公有云不僅提供了對計算的快速訪問，而且還能通過提供易用的RESTful API來提供了自動化的能力。這真是太美好了。

2. 代碼即基礎(chǔ)設(shè)施以及Devops

隨著Chef, Puppet, Ansible以及SaltStack技術(shù)的出現(xiàn)，開發(fā)和運維之簡的界限越來越模糊。以前系統(tǒng)管理員很少冒險使用除了Shell腳本之外的語言，而Chef，Puppet以及Ansible都是發(fā)展成熟的系統(tǒng)編排框架。Puppet使用了特定于域的語言(DSL: Domain Specified Language)來讓系統(tǒng)管理員定義其基礎(chǔ)架構(gòu)設(shè)置的最終狀態(tài)，而Chef使用的是基于Ruby語言的DSL，可以充分發(fā)揮Ruby語言的表達能力來定義基礎(chǔ)架構(gòu)的最終狀態(tài)。這些技術(shù)使我們直接進入聲明式以及命令式架構(gòu)的時代，我們可以通過文件中的代碼來定義服務(wù)器基礎(chǔ)架構(gòu)的最終狀態(tài)，因此可以像管理源代碼一樣對架構(gòu)進行版本控制。這和手動設(shè)置服務(wù)器并登入安裝各種軟件，設(shè)置硬件資源(如網(wǎng)絡(luò)，存儲等)非常不同，盡管管理員可能會運行一些腳本使這個過程更加高效，但是現(xiàn)在，使用Chef以及Puppet可以集中化管理系統(tǒng)配置，并且通過他們功能強大的API，可以輕松的管理大量服務(wù)器。

3. Docker的興起

Docker并不是一項容器技術(shù)，它是一個強大的利用linux原始特性來輕松管理和組合容器的工具，Linux容器是使用Linux的操作系統(tǒng)的原始特性(CGroups即Control Groups和Namespaces)來構(gòu)建的。Docker只是使構(gòu)建和管理容器變得容易。使用Docker，可以輕松的打包應(yīng)用程序及其所有依賴關(guān)系。就像一個真正的容器一樣，“運送”變得十分容易。之后這個容器可以運行在任意Linux機器之上，而不用預(yù)先安裝其依賴項(其中一些可能是特定的Linux發(fā)行版)。通過容器技術(shù)，我們可以運行來自Debian Linux的Nginx，以及來自Ubuntu的Python Flask框架，與此同時，還可以運行來自 Alpine的MySQL, 這些軟件一起構(gòu)成了用戶的應(yīng)用，所有這些軟件包都在同一Linux服務(wù)器上運行?？偠灾?，Docker，提供了聲明式構(gòu)建容器的標準，并提供了在Linux服務(wù)器上運行和管理容器的生命周期的工具，成功駕馭了Linux的容器技術(shù)并且提供了巨大的便利。

盡管 Puppet和Chef擅長管理物理機和虛擬機的配置，Devops更喜歡用容器來部署應(yīng)用，容器很快成為了標準，并且容器可以包含很多應(yīng)用部署的邏輯，從而使業(yè)務(wù)流程的其余部分變得更加簡單，是時候使用一種更現(xiàn)代的以容器為中心的編排系統(tǒng)了。

與此同時，另一種快速發(fā)展的方法使得運維人員越來越深入到開發(fā)者的領(lǐng)域之中，Devops，工程師發(fā)現(xiàn)，運維人員希望系統(tǒng)穩(wěn)定，而開發(fā)人員希望隨時發(fā)布新的功能，這給穩(wěn)定性的帶來了巨大的挑戰(zhàn)。這兩個目標相互矛盾，致使團隊互相爭執(zhí)，直接影響了產(chǎn)品的交付速度。并且開發(fā)團隊的人員在沒有意識到他們的代碼會在生產(chǎn)環(huán)境中引起何種問題之前，他們是不會花費力氣去修復(fù)它的。因為生產(chǎn)環(huán)境通常是由運維團隊來處理的。為了解決這些問題。團隊開始嘗試一種新的方法：Devops，這個方法很簡單，誰寫代碼，誰負責發(fā)布到生產(chǎn)環(huán)境。同時也將負責之后的值班。如果開發(fā)人員想要更加頻繁的發(fā)布新功能，那么他們需要了解作為運維人員需要做哪些事情來支持發(fā)布。云和容器技術(shù)以及其強大的API和工具鏈，使得這種方式可以被并入云操作中?？焖侔l(fā)展的DevOps團隊會構(gòu)建由微服務(wù)組成的大型應(yīng)用程序，每個微服務(wù)都可以獨立開發(fā)和發(fā)布，而無需測試和發(fā)布整個大型應(yīng)用程序。嘗試DevOps的團隊會使用微服務(wù)架構(gòu)，他們喜歡云和容器的可塑性和靈活性，程序員可以通過可編寫腳本的工具和API輕松控制。

4. 進入Kubernetes

當Devops和微服務(wù)遇到了容器，一個新的，原生的編排框架應(yīng)運而生，受Google Borg系統(tǒng)的啟發(fā)，Kubernetes是一個開源容器編排系統(tǒng)，最初由Google的工程師構(gòu)建，現(xiàn)在由CNCF(Cloud Native Computing Foundation,云原生計算基金會)維護。作為容器編排平臺，Kubernetes可以實現(xiàn)自動化應(yīng)用程序部署，擴展和管理。盡管像Docker這樣的系統(tǒng)也可以管理服務(wù)器中的容器，但Kubernetes的功能更強大，其主要功能之一是可以管理運行容器的服務(wù)器或節(jié)點的集群。與此類似的框架有Apache Mesos和Docker Swarm。但到目前為止，顯然，Kubernetes已經(jīng)成為贏家?，F(xiàn)在，選擇Kubernetes作為容器編排框架是一個非常安全的選擇。

4.1不僅僅是Docker

值得注意的是，Kubernetes可以編排不僅由Docker管理的容器。它還可以編排由類似于Docker的系統(tǒng)管理的容器，例如ContainerD，Cri-O和RktLet。盡管您可以創(chuàng)建和管理這些系統(tǒng)的容器，但在本文中，我們將用“ Docker”來指代“容器管理”?，F(xiàn)在，讓我們看一下Kubernetes的一些最重要的功能。

4.2 為什么選擇Kubernetes

要想知道為什么Kubernets如此重要，首先要了解Docker的邊界在哪，盡管Docker可以輕松管理一個服務(wù)器內(nèi)容器的生命周期，但是Kubernets可以輕松管理多個運行Docker容器的服務(wù)器(即集群)。另一方面，現(xiàn)在，微服務(wù)應(yīng)用常常由幾個容器構(gòu)成，Kubernets提供了“應(yīng)用程序部署”這個概念，指的是組成應(yīng)用程序的一組容器，在集群上以分布式方式運行。當您要運行由一組容器組成的應(yīng)用程序時，只需告訴Kubernetes，它便可以找出集群中的哪些節(jié)點具有足夠的計算資源來運行容器，并在其中調(diào)度它們。Kubernetes會在容器出現(xiàn)故障時重啟容器，甚至可以根據(jù)某些參數(shù)來擴展你的應(yīng)用，如增加容器的數(shù)量以應(yīng)對激增流量。這就是Kubernetes的本質(zhì)，這也就是人們所談?wù)摰?ldquo;容器編排”。

在集群上運行多個應(yīng)用時，Kubernets還提供了其他的功能來簡化管理，它使管理應(yīng)用程序的配置和證書變得更加容易，Kubernetes還管理其他基礎(chǔ)架構(gòu)，例如存儲和網(wǎng)絡(luò)，計算，這是構(gòu)成任何基礎(chǔ)架構(gòu)的最基本三個組成部分。

4.3 是否托管

盡管你可以在私有云上從頭開始搭建Kubernetes，但在擴展kubernetes基礎(chǔ)架構(gòu)之前您最好還是選擇OpenShift的Kubernetes發(fā)行版，它提供付費支持。當然，您也可以選擇在AWS,Azure或GCP的集群上搭建Kubernetes。Kubernetes是由多個組件構(gòu)成，這些組件一起運行一個集群(稱為計算節(jié)點)，每個計算節(jié)點也會運行Kubernetes。當您選擇任何公有云提供的托管Kubernetes產(chǎn)品時，您可以選擇他們提供的任何類型的計算節(jié)點來組成Kubernets集群，這些可以用于容器部署，但是Kubernetes的主要主組件(也稱為“控制平面”)是由云服務(wù)提供商管理。

5. 您的組織準備好使用Kubernetes嗎?

這取決一系列因素。

5.1 公有云還是私有云

Kubernetes可以部署在公有云和私有云上。在私有云上，雖然理論上您可以自己安裝和維護Kubernetes，但最好是運行諸如OpenShift之類提供的Kubernetes發(fā)行版，該發(fā)行版可以獲得供應(yīng)商技術(shù)支持。 Kubernetes誕生于云中，是一種所謂的“云原生”技術(shù)，它是管理計算集群的絕佳選擇。實際上，Kubernetes也是管理私有云的絕佳選擇。

對于像是AWS,Azure以及GCP這類公有云，你可以在一組計算節(jié)點上運行Kubernetes，例如，你可以使用Kops(一種流行的解決方案)在AWS的EC2實例上部署Kubernetes，但是，我強烈建議您選擇使用托管的Kubernetes產(chǎn)品，從而將維護Kubernetes控制平面的工作移交給云服務(wù)提供商，以便您可以專注于如何在Kubernetes上運行工作負載。

5.2 您項目中目前對Docker的采用程度如何?

Kubernets并不是入門級產(chǎn)品，它是一個容器編排平臺。如果您準備運行在Kubernets的應(yīng)用還沒有容器化，您首先必須確保這些應(yīng)用程序已在生產(chǎn)中的Docker上經(jīng)過了良好的測試。稍后，我們將提出一個簡單的策略，說明如何逐步實施這個步驟。 Docker已被廣泛采用，工具已經(jīng)非常成熟，可以肯定地說，Docker已經(jīng)遠遠超出了炒作階段。無論您的組織有多么“謹慎”的IT策略，采用Docker是沒有太大風險的。如果將Docker與Kubernetes以合適的方式結(jié)合，可以真正提高服務(wù)器利用率。因此，這件事值得考慮。

5.3 組織中的DevOps文化有多成熟?

一個強大的Devops文化意味著開發(fā)者需要負責在生產(chǎn)環(huán)境中運行他們開發(fā)的服務(wù)，他們會始終尋找一些自動化操作來提高他們的生產(chǎn)力。尤其是當應(yīng)用或者服務(wù)是以微服務(wù)的架構(gòu)為基礎(chǔ)，意味著不同的團隊需要獨立運行不同的微服務(wù)，Kubernetes非常適合這種情況，并且能很快被內(nèi)部采用。不過另一方面，Kubernetes也可以很好的運行單體的工作負載。這里的關(guān)鍵點在于，如果有兩個獨立的團隊，開發(fā)和運維，如果運維團隊以一種全新的部署方式工作，然后讓開發(fā)團隊努力適應(yīng)一種用于容器化和應(yīng)用程序配置的構(gòu)建系統(tǒng)，那么兩個團隊可能都不會付出太大的努力來促成這件事。

5.4 組織中是否有足夠的了解Kubernetes的員工

Kubernetes需要花費一定的時間去學(xué)習，而且只有當你學(xué)習了容器化之后再去學(xué)Kubernetes才有意義。如果您確信Kubernetes適合您的組織并且已經(jīng)考慮了以上列出的幾個要點，那么您可能需要幾個有能力和信心在生產(chǎn)中使用Kubernetes的擁護者，如果您的組織中只有剛接觸Kubernetes的人員，我們會提供一條路徑幫助你們積累經(jīng)驗，與此同時，降低再生產(chǎn)中使用Kubernetes的風險。稍后我將介紹如何實現(xiàn)。

6. Kubernetes陷阱

如果有人將Kubernetes稱為靈丹妙藥，那么他們可能還停留在初級階段。這是您需要注意的一些事情。

6.1 托管的Kubernetes不是萬能藥

Kubernetes是一個由許多協(xié)同工作的軟件組成的系統(tǒng)。無論您是直接管理它還是選擇托管Kubernetes，都可能遇到問題。就算是托管的Kubernetes，它的各個組成部分也可能出現(xiàn)問題。不要僅僅因為Kubernetes控制平面是由您的云服務(wù)提供商管理的，就覺得它不會出錯。您可以在Github上找到幾個特定于云提供商的Kubernetes問題。當出現(xiàn)問題時，您可能仍需要聯(lián)系支持人員并進行處理。這可能涉及停機時間。因為控制平面中的Kubernetes組件僅創(chuàng)建和監(jiān)視容器，所以如果它們出現(xiàn)故障，它們通常不會影響已經(jīng)在運行的容器。但是，控制平面出問題可能會影響您創(chuàng)建新容器以及自動調(diào)整容器數(shù)量等操作。

6.2 Kubernetes上的有狀態(tài)應(yīng)用仍在不斷發(fā)展

Kubernetes適用于創(chuàng)建和銷毀(短期存在)容器的應(yīng)用。為了應(yīng)對流量激增，可以臨時創(chuàng)建很多容器，一旦情況恢復(fù)正常，這些容器將被終止。跟后臺作業(yè)運行器一樣。這意味著它將是一個非常動態(tài)的環(huán)境，服務(wù)器被當做一個整體而不是個體。這意味著，像數(shù)據(jù)庫這樣有狀態(tài)的應(yīng)用似乎沒有被考慮到。實際上，數(shù)據(jù)庫這塊領(lǐng)域的開發(fā)一直非?；钴S，現(xiàn)在這個功能也比較穩(wěn)定了。不過Kubernetes的有狀態(tài)的應(yīng)用的功能仍在快速變化中。

Kuberntes本身就支持在有狀態(tài)的應(yīng)用中使用持久卷，當然你可以以云提供商的方式來分配持久卷給有狀態(tài)的應(yīng)用。

如果您想使用由基礎(chǔ)云提供商管理的有狀態(tài)服務(wù)(例如RDS，DynamoDB等)，您需要使用Kubernetes的服務(wù)目錄(Service Catalog,)，那么kubernetes就可以消費云提供商托管的服務(wù)。

6.3 Kubernetes升級

您可能會害怕Kubernetes集群升級會帶來嚴重的后果，導(dǎo)致您更希望維持現(xiàn)有的集群設(shè)置。那么最好的方法可能是使用和生產(chǎn)集群相同版本的Kubernetes和配置來創(chuàng)建一個新集群，安裝所有關(guān)鍵應(yīng)用程序并升級該集群，檢查一切是否正常，如果正常，再升級生產(chǎn)中的集群。如果您對Kubernetes及其帶來的好處持認真態(tài)度，那么集群升級是您無法避免的的。因此，計劃并執(zhí)行是最好的解決辦法。

6.4 許多靈活的部件

說到虛擬化技術(shù)，這已經(jīng)是我們習以為常的抽象化技術(shù)了。實際上，當某人引用“計算機”或“服務(wù)器”時，他們很可能指的是虛擬機。對于應(yīng)用來說，Kubernetes很有可能成為新的標準底層。一個新的抽象級別，成為新的常態(tài)。對于虛擬機而言，由于大多數(shù)大型系統(tǒng)都采用Linux的KVM技術(shù)進行標準化，因此它是操作系統(tǒng)層的組成部分，盡管還涉及其他組件，但是它們是相當?shù)讓拥?。它與Kubernetes截然不同，Kubernetes上有十幾個服務(wù)在不同機器之間相互通信，在計算，存儲，網(wǎng)絡(luò)和自動擴展方面進行相當復(fù)雜的操作。

當問題出現(xiàn)時，您可能不得不袖手旁觀。我們只能在某種程度上假設(shè)Kubernetes使用的這些組件的所有不同版本在某種程度上是相互協(xié)調(diào)的。至少云服務(wù)提供商希望我們相信這一點。

6.5 保留Kubernetes人才

如果您希望采用Kubernetes，但是只有一個人在后面支撐你，您將獨自承擔風險。雖然Kubernetes在您的項目中證明了自己的價值，但正如我們將要看到的，讓整個DevOps團隊接受Kubernetes的培訓(xùn)或者自學(xué)。畢竟，誰都想接受一次培訓(xùn)的機會，來研究一項炙手可熱的技術(shù)?另一方面，您需要一群熟悉Kubernetes的DevOps團隊而不是一兩個人，以便在未來也能保持Kubernetes執(zhí)行的連續(xù)性。相信我，隨著Kubernetes在LinkedIn頁面上被列為一項技能，人們很容易跳槽，不能只依賴一兩個人來執(zhí)行這項任務(wù)。

7.將Kubernetes引入您的組織

至此，如果您確信可以從在組織中部署Kubernetes受益，您可以按照以下步驟，讓您的團隊逐步了解Kubernetes以及采用它來管理生產(chǎn)工作負載。

7.1培訓(xùn)或雇用Kubernetes人才

您需要DevOps團隊里具有Kubernetes知識和實操能力的人員來執(zhí)行您的計劃。鑒于官網(wǎng)提供了高質(zhì)量的培訓(xùn)材料，他們可以自學(xué)，也可以通過更正式的培訓(xùn)計劃。您應(yīng)該咨詢您的云提供商，看他們是否可以為您的組織專門培訓(xùn)，或者他們有什么培訓(xùn)可以讓您的團隊參加。在您所在的地區(qū)可能還有其他付費選擇。

雇用Kubernetes人才是另一種選擇。尋找使用過Kubernetes來運行生產(chǎn)工作負載的人員。雇用他們時，您可能需要跟他們討論之前投入生產(chǎn)的方式以及在Kubernetes上運行生產(chǎn)工作負載時面臨的挑戰(zhàn)。詢問他們是否運行任何有狀態(tài)的工作負載。通過這些討論，您應(yīng)該能夠確定他們是否適合您的項目。

7.2將工作負載遷移到Docker

首先您需要將您的工作負載遷移至Docker，然后再從Dodcker遷移至kubernetes，如果您的應(yīng)用程序沒有運行在docker上，而您想要直接遷移到Kubernetes，那么遇到問題時，您將無法準確指出是由構(gòu)建時，運行時或配置問題引起的。另一方面，如果您的團隊花時間在容器化工作負載，并在生產(chǎn)環(huán)境中使用Docker運行它們，你遇到的問題，需要考慮的問題就會變少了。

7.3 在Kubernetes上運行非生產(chǎn)的工作負載

現(xiàn)在您的工作負載已被容器化，您可以將一些非生產(chǎn)型工作負載(例如開發(fā)和臨時的工作負載)遷移到Kubernetes。這樣，您的大型團隊可以先適應(yīng)新環(huán)境，將Kubernetes集成到您的持續(xù)部署管道中，等等。

7.4 把無狀態(tài)工作負載的遷移放在前面

在將生產(chǎn)工作負載轉(zhuǎn)移到Kubernetes時，可以從無狀態(tài)工作負載開始：無狀態(tài)的工作負載指的是只提供請求服務(wù)但不直接保留任何數(shù)據(jù)的容器。在Kubernetes上運行有狀態(tài)工作負載需要更深的Kubernetes專業(yè)知識。對于有狀態(tài)的工作負載，您需要做一些更仔細的計劃，以了解在節(jié)點發(fā)生故障時如何管理。例如，對于像Elasticsearch這樣的分布式有狀態(tài)應(yīng)用程序，這將尤其復(fù)雜。

7.5 遷移非關(guān)鍵性工作負載

一開始只將非關(guān)鍵工作負載轉(zhuǎn)移到Kubernetes上，并讓您的團隊在上運行生產(chǎn)工作負載以積累相關(guān)經(jīng)驗。例如，在生產(chǎn)中運行工作負載需要的監(jiān)控，警報和應(yīng)用程序升級等。

7.6 大飛躍

從以上步驟我們看到了如何以一種既可以建立專業(yè)知識又可以降低風險的方式在組織中采用Kubernetes。我們還從工程角度討論了如何做好準備以進行容器化并將生產(chǎn)工作負載緩慢引入Kubernetes。您只需要判斷何時是最佳時機。每個組織的采用率與風險率都不相同，因此您應(yīng)該做出最佳判斷。我的建議是您使用Terraform之類的工具來自動化Kubernetes集群本身的部署。

8.結(jié)論

最好的計劃總是會考慮最差的情況，這就是本文的主要思想：告訴您潛在的問題以及如何減輕采用Kubernetes風險。 Kubernetes是偉大的技術(shù)。在很多方面，它肯定會為您提供幫助。但是，與打算使用生產(chǎn)工作負載的任何技術(shù)一樣，您將需要權(quán)衡風險，看看收益是否大于風險。查看Kubernetes的失敗案例對于找出最常見的問題以及如何解決這些問題很有用。

就個人而言，我對Kubernetes以及在上面運行生產(chǎn)工作負載感到非常興奮， Kubernetes提供的編排，自動擴展，提高服務(wù)器利用率和自我修復(fù)功能，這些都帶來了真正的好處，并且都不需要花費您自己的時間去實現(xiàn)。

譯者介紹：Grace，程序員，研究生畢業(yè)于SUNY at Stony Brook，目前供職于Linktime Cloud Company，對容器化技術(shù)以及數(shù)據(jù)可視化技術(shù)感興趣。