簡介

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

[[312753]]

1. 從寵物到羊群

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

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

2. 代碼即基礎設施以及Devops

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

3. Docker的興起

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

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

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

4. 進入Kubernetes

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

4.1不僅僅是Docker

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

4.2 為什么選擇Kubernetes

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

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

4.3 是否托管

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

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

這取決一系列因素。

5.1 公有云還是私有云

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

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

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

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

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

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

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

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

6. Kubernetes陷阱

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

6.1 托管的Kubernetes不是萬能藥

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

6.2 Kubernetes上的有狀態應用仍在不斷發展

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

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

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

6.3 Kubernetes升級

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

6.4 許多靈活的部件

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

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

6.5 保留Kubernetes人才

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

7.將Kubernetes引入您的組織

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

7.1培訓或雇用Kubernetes人才

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

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

7.2將工作負載遷移到Docker

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

7.3 在Kubernetes上運行非生產的工作負載

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

7.4 把無狀態工作負載的遷移放在前面

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

7.5 遷移非關鍵性工作負載

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

7.6 大飛躍

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

8.結論

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

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

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