第1章 Kubernetes入門

1.1 Kubernetes是什么

Kubernetes是什么？

首先，它是一個全新的基于容器技術的分布式架構領先方案。這個方案雖然還很新，但它是谷歌十幾年以來大規模應用容器技術的經驗積累和升華的重要成果。確切地說，Kubernetes是谷歌嚴格保密十幾年的秘密武器——Borg的一個開源版本。Borg是谷歌的一個久負盛名的內部使用的大規模集群管理系統，它基于容器技術，目的是實現資源管理的自動化，以及跨多個數據中心的資源利用率的最大化。十幾年以來，谷歌一直通過Borg系統管理著數量龐大的應用程序集群。由于谷歌員工都簽署了保密協議，即便離職也不能泄露Borg的內部設計，所以外界一直無法了解關于它的更多信息。直到2015年4月，傳聞許久的Borg論文伴隨Kubernetes的高調宣傳被谷歌首次公開，大家才得以了解它的更多內幕。正是由于站在Borg這個前輩的肩膀上，汲取了Borg過去十年間的經驗與教訓，所以Kubernetes一經開源就一鳴驚人，并迅速稱霸容器領域。

其次，如果我們的系統設計遵循了Kubernetes的設計思想，那么傳統系統架構中那些和業務沒有多大關系的底層代碼或功能模塊，都可以立刻從我們的視線中消失，我們不必再費心于負載均衡器的選型和部署實施問題，不必再考慮引入或自己開發一個復雜的服務治理框架，不必再頭疼于服務監控和故障處理模塊的開發。總之，使用Kubernetes提供的解決方案，我們不僅節省了不少于30%的開發成本，還可以將精力更加集中于業務本身，而且由于Kubernetes提供了強大的自動化機制，所以系統后期的運維難度和運維成本大幅度降低。

然后，Kubernetes是一個開放的開發平臺。與J2EE不同，它不局限于任何一種語言，沒有限定任何編程接口，所以不論是用Java、Go、C++還是用Python編寫的服務，都可以被映射為Kubernetes的Service（服務），并通過標準的TCP通信協議進行交互。此外，Kubernetes平臺對現有的編程語言、編程框架、中間件沒有任何侵入性，因此現有的系統也很容易改造升級并遷移到Kubernetes平臺上。

最后，Kubernetes是一個完備的分布式系統支撐平臺。Kubernetes具有完備的集群管理能力，包括多層次的安全防護和準入機制、多租戶應用支撐能力、透明的服務注冊和服務發現機制、內建的智能負載均衡器、強大的故障發現和自我修復能力、服務滾動升級和在線擴容能力、可擴展的資源自動調度機制，以及多粒度的資源配額管理能力。同時，Kubernetes提供了完善的管理工具，這些工具涵蓋了包括開發、部署測試、運維監控在內的各個環節。因此，Kubernetes是一個全新的基于容器技術的分布式架構解決方案，并且是一個一站式的完備的分布式系統開發和支撐平臺。

在正式開始本章的Hello World之旅之前，我們首先要學習Kubernetes的一些基本知識，這樣才能理解Kubernetes提供的解決方案。

在Kubernetes中，Service是分布式集群架構的核心，一個Service對象擁有如下關鍵特征。

◎ 擁有唯一指定的名稱（比如mysql-server）。

◎ 擁有一個虛擬IP（Cluster IP、Service IP或VIP）和端口號。

◎ 能夠提供某種遠程服務能力。

◎ 被映射到提供這種服務能力的一組容器應用上。

Service的服務進程目前都基于Socket通信方式對外提供服務，比如Redis、Memcache、MySQL、Web Server，或者是實現了某個具體業務的特定TCP Server進程。雖然一個Service通常由多個相關的服務進程提供服務，每個服務進程都有一個獨立的Endpoint（IP+Port）訪問點，但Kubernetes能夠讓我們通過Service（虛擬Cluster IP +Service Port）連接到指定的Service。有了Kubernetes內建的透明負載均衡和故障恢復機制，不管后端有多少服務進程，也不管某個服務進程是否由于發生故障而被重新部署到其他機器，都不會影響對服務的正常調用。更重要的是，這個Service本身一旦創建就不再變化，這意味著我們再也不用為Kubernetes集群中服務的IP地址變來變去的問題而頭疼了。

容器提供了強大的隔離功能，所以有必要把為Service提供服務的這組進程放入容器中進行隔離。為此，Kubernetes設計了Pod對象，將每個服務進程都包裝到相應的Pod中，使其成為在Pod中運行的一個容器（Container）。為了建立Service和Pod間的關聯關系，Kubernetes首先給每個Pod都貼上一個標簽（Label），給運行MySQL的Pod貼上name=mysql標簽，給運行PHP的Pod貼上name=php標簽，然后給相應的Service定義標簽選擇器（Label Selector），比如MySQL Service的標簽選擇器的選擇條件為name=mysql，意為該Service要作用于所有包含name=mysql Label的Pod。這樣一來，就巧妙解決了Service與Pod的關聯問題。

這里先簡單介紹Pod的概念。首先，Pod運行在一個被稱為節點（Node）的環境中，這個節點既可以是物理機，也可以是私有云或者公有云中的一個虛擬機，通常在一個節點上運行幾百個Pod；其次，在每個Pod中都運行著一個特殊的被稱為Pause的容器，其他容器則為業務容器，這些業務容器共享Pause容器的網絡棧和Volume掛載卷，因此它們之間的通信和數據交換更為高效，在設計時我們可以充分利用這一特性將一組密切相關的服務進程放入同一個Pod中；最后，需要注意的是，并不是每個Pod和它里面運行的容器都能被映射到一個Service上，只有提供服務（無論是對內還是對外）的那組Pod才會被映射為一個服務。

在集群管理方面，Kubernetes將集群中的機器劃分為一個Master和一些Node。在Master上運行著集群管理相關的一組進程kube-apiserver 、 kube-controller-manager和kube-scheduler，這些進程實現了整個集群的資源管理、Pod調度、彈性伸縮、安全控制、系統監控和糾錯等管理功能，并且都是自動完成的。Node作為集群中的工作節點，運行真正的應用程序，在Node上Kubernetes管理的最小運行單元是Pod。在Node上運行著Kubernetes的kubelet、kube-proxy服務進程，這些服務進程負責Pod的創建、啟動、監控、重啟、銷毀，以及實現軟件模式的負載均衡器。

最后，看看傳統的IT系統中服務擴容和服務升級這兩個難題，以及Kubernetes所提供的全新解決思路。服務的擴容涉及資源分配（選擇哪個節點進行擴容）、實例部署和啟動等環節，在一個復雜的業務系統中，這兩個難題基本上靠人工一步步操作才得以解決，費時費力又難以保證實施質量。

在Kubernetes集群中，只需為需要擴容的Service關聯的Pod創建一個RC（Replication Controller），服務擴容以至服務升級等令人頭疼的問題都迎刃而解。在一個RC定義文件中包括以下3個關鍵信息。

◎ 目標Pod的定義。

◎ 目標Pod需要運行的副本數量（Replicas）。

◎ 要監控的目標Pod的標簽。

在創建好RC（系統將自動創建好Pod）后，Kubernetes會通過在RC中定義的Label篩選出對應的Pod實例并實時監控其狀態和數量，如果實例數量少于定義的副本數量，則會根據在RC中定義的Pod模板創建一個新的Pod，然后將此Pod調度到合適的Node上啟動運行，直到Pod實例的數量達到預定目標。這個過程完全是自動化的，無須人工干預。有了RC，服務擴容就變成一個純粹的簡單數字游戲了，只需修改RC中的副本數量即可。后續的服務升級也將通過修改RC來自動完成。

以將在第2章中介紹的PHP+Redis留言板應用為例，只要為PHP留言板程序（frontend）創建一個有3個副本的RC+Service，為Redis讀寫分離集群創建兩個RC：寫節點（redis-master）創建一個單副本的RC+Service，讀節點（redis-slaver）創建一個有兩個副本的RC+Service，就可以快速完成整個集群的搭建過程，是不是很簡單？