1.2 Kubernetes概述

盡管公開面世不過短短數年時間，Kubernetes業已成為容器編排領域事實上的標準，其近一兩年的發展狀態也在不斷地驗證著Urs H?lzle曾經的斷言：無論是公有云、私有云抑或混合云，Kubernetes都將作為一個為任何應用、任何環境提供的容器管理框架而無處不在。

1.2.1 Kubernetes簡史

Kubernetes（來自希臘語，意為“舵手”或“飛行員”）由Joe Beda、Brendan Burns和Craig McLuckie創立，而后Google的其他幾位工程師，包括Brian Grant和Tim Hockin等加盟共同研發，并由Google在2014年首次對外宣布。Kubernetes的開發和設計都深受Google內部系統Borg的影響，事實上，它的許多頂級貢獻者之前也是Borg系統的開發者。

Borg是Google內部使用的大規模集群管理系統，久負盛名。它建構于容器技術之上，目的是實現資源管理的自動化，以及跨多個數據中心的資源利用率最大化。2015年4月，Borg論文《Large-scale cluster management at Google with Borg》伴隨Kubernetes的高調宣傳被Google首次公開，人們終于有緣得窺其全貌。

事實上，正是由于誕生于容器世家Google，并站在Borg這個巨人的肩膀之上，充分受益于Borg過去十數年間積累的經驗和教訓，Kubernetes甫一面世就立即廣受關注和青睞，并迅速稱霸了容器編排技術領域。很多人將Kubernetes視為Borg系統的一個開源實現版本，在Google內部，Kubernetes的原始代號曾經是Serven of Nine，即星際迷航中友好的“Borg”角色，它標識中的舵輪有七個輪輻就是對該項目代號的致意，如圖1-3所示。

Kubernetes v1.0于2015年7月21日發布，緊隨其后，Google與Linux基金會合作組建了Cloud Native Computing Foundation（云原生計算基金會，簡稱為CNCF），并將Kubernetes作為種子技術予以提供。這之后，Kubernetes進入了版本快速迭代期，從此不斷地融入著新功能，如Federation、Network Policy API、RBAC、CRD和CSI，等等，并增加了對Windows系統的支持。

2017年可謂是容器生態發展史上具有里程碑意義的一年。這一年，AWS、Azure和Alibaba Cloud都相繼在其原有容器服務上新增了對Kubernetes的支持，而Docker官方也在2017年10月宣布同時支持Swarm和Kubernetes編排系統。這一年，RKT容器派系的CoreOS舍棄掉自己的調度工具Fleet，將其商用平臺Tectonic的重心轉移至Kubernetes。這一年，Mesos也于9月宣布了對Kubernetes的支持，其平臺用戶可以安裝、擴展和升級多個生產級的Kubernetes集群。這一年，Rancher Labs推出了其2.0版本的容器管理平臺并宣布all-in Kubernetes，放棄了其內置多年的容器編排系統Cattle。類似的故事依然在進行，并且必將在一個時期內持續上演。

1.2.2 Kubernetes特性

Kubernetes是一種用于在一組主機上運行和協同容器化應用程序的系統，旨在提供可預測性、可擴展性與高可用性的方法來完全管理容器化應用程序和服務的生命周期的平臺。用戶可以定義應用程序的運行方式，以及與其他應用程序或外部世界交互的途徑，并能實現服務的擴容和縮容，執行平滑滾動更新，以及在不同版本的應用程序之間調度流量以測試功能或回滾有問題的部署。Kubernetes提供了接口和可組合的平臺原語，使得用戶能夠以高度的靈活性和可靠性定義及管理應用程序。簡單總結起來，它具有以下幾個重要特性。

（1）自動裝箱

建構于容器之上，基于資源依賴及其他約束自動完成容器部署且不影響其可用性，并通過調度機制混合關鍵型應用和非關鍵型應用的工作負載于同一節點以提升資源利用率。

（2）自我修復（自愈）

支持容器故障后自動重啟、節點故障后重新調度容器，以及其他可用節點、健康狀態檢查失敗后關閉容器并重新創建等自我修復機制。

（3）水平擴展

支持通過簡單命令或UI手動水平擴展，以及基于CPU等資源負載率的自動水平擴展機制。

（4）服務發現和負載均衡

Kubernetes通過其附加組件之一的KubeDNS（或CoreDNS）為系統內置了服務發現功能，它會為每個Service配置DNS名稱，并允許集群內的客戶端直接使用此名稱發出訪問請求，而Service則通過iptables或ipvs內建了負載均衡機制。

（5）自動發布和回滾

Kubernetes支持“灰度”更新應用程序或其配置信息，它會監控更新過程中應用程序的健康狀態，以確保它不會在同一時刻殺掉所有實例，而此過程中一旦有故障發生，就會立即自動執行回滾操作。

（6）密鑰和配置管理

Kubernetes的ConfigMap實現了配置數據與Docker鏡像解耦，需要時，僅對配置做出變更而無須重新構建Docker鏡像，這為應用開發部署帶來了很大的靈活性。此外，對于應用所依賴的一些敏感數據，如用戶名和密碼、令牌、密鑰等信息，Kubernetes專門提供了Secret對象為其解耦，既便利了應用的快速開發和交付，又提供了一定程度上的安全保障。

（7）存儲編排

Kubernetes支持Pod對象按需自動掛載不同類型的存儲系統，這包括節點本地存儲、公有云服務商的云存儲（如AWS和GCP等），以及網絡存儲系統（例如，NFS、iSCSI、GlusterFS、Ceph、Cinder和Flocker等）。

（8）批量處理執行

除了服務型應用，Kubernetes還支持批處理作業及CI（持續集成），如果需要，一樣可以實現容器故障后恢復。

1.2.3 Kubernetes概念和術語

Kubernetes使用共享網絡將多個物理機或虛擬機匯集到一個集群中，在各服務器之間進行通信，該集群是配置Kubernetes的所有組件、功能和工作負載的物理平臺。集群中一臺服務器（或高可用部署中的一組服務器）用作Master，負責管理整個集群，余下的其他機器用作Worker Node（早期版本中也稱為Minion），它們是使用本地和外部資源接收和運行工作負載的服務器，如圖1-4所示。集群中的這些主機可以是物理服務器，也可以是虛擬機（包括IaaS云端的VPS）。

（1）Master

Master是集群的網關和中樞，負責諸如為用戶和客戶端暴露API、跟蹤其他服務器的健康狀態、以最優方式調度工作負載，以及編排其他組件之間的通信等任務，它是用戶或客戶端與集群之間的核心聯絡點，并負責Kubernetes系統的大多數集中式管控邏輯。單個Master節點即可完成其所有的功能，但出于冗余及負載均衡等目的，生產環境中通常需要協同部署多個此類主機。Master節點類似于蜂群中的蜂王。

（2）Node

Node是Kubernetes集群的工作節點，負責接收來自Master的工作指令并根據指令相應地創建或銷毀Pod對象，以及調整網絡規則以合理地路由和轉發流量等。理論上講，Node可以是任何形式的計算設備，不過Master會統一將其抽象為Node對象進行管理。Node類似于蜂群中的工蜂，生產環境中，它們通常數量眾多。

Kubernetes將所有Node的資源集結于一處形成一臺更加強大的“服務器”，如圖1-5所示，在用戶將應用部署于其上時，Master會使用調度算法將其自動指派至某個特定的Node運行。在Node加入集群或從集群中移除時，Master也會按需重新編排影響到的Pod（容器）。于是，用戶無須關心其應用究竟運行于何處。

從抽象的視角來講，Kubernetes還有著眾多的組件來支撐其內部的業務邏輯，包括運行應用、應用編排、服務暴露、應用恢復等，它們在Kubernetes中被抽象為Pod、Service、Controller等資源類型，下面列出了幾個較為常用的資源抽象。

（1）Pod

Kubernetes并不直接運行容器，而是使用一個抽象的資源對象來封裝一個或者多個容器，這個抽象即為Pod，它也是Kubernetes的最小調度單元。同一Pod中的容器共享網絡名稱空間和存儲資源，這些容器可經由本地回環節口lo直接通信，但彼此之間又在Mount、User及PID等名稱空間上保持了隔離。盡管Pod中可以包含多個容器，但是作為最小調度單元，它應該盡可能地保持“小”，即通常只應該包含一個主容器，以及必要的輔助型容器（sidecar），如圖1-6所示。

（2）資源標簽

標簽（Label）是將資源進行分類的標識符，資源標簽其實就是一個鍵值型（key/values）數據。標簽旨在指定對象（如Pod等）辨識性的屬性，這些屬性僅對用戶存在特定的意義，對Kubernetes集群來說并不直接表達核心系統語義。標簽可以在對象創建時附加其上，并能夠在創建后的任意時間進行添加和修改。一個對象可以擁有多個標簽，一個標簽也可以附加于多個對象（通常是同一類對象）之上，如圖1-7所示。

（3）標簽選擇器

標簽選擇器（Selector）全稱為“Label Selector”，它是一種根據Label來過濾符合條件的資源對象的機制。例如，將附有標簽“role: backend”的所有Pod對象挑選出來歸為一組就是標簽選擇器的一種應用，如圖1-8所示。用戶通常使用標簽對資源對象進行分類，而后使用標簽選擇器挑選出它們，例如將其創建為某Service的端點。

（4）Pod控制器

盡管Pod是Kubernetes的最小調度單元，但用戶通常并不會直接部署及管理Pod對象，而是要借助于另一類抽象——控制器（Controller）對其進行管理。用于工作負載的控制器是一種管理Pod生命周期的資源抽象，它們是Kubernetes上的一類對象，而非單個資源對象，包括ReplicationController、ReplicaSet、Deployment、StatefulSet、Job等。以圖1-9中所示的Deployment控制器為例，它負責確保指定的Pod對象的副本數量精確符合定義，否則“多退少補”。使用控制器之后就不再需要手動管理Pod對象了，用戶只需要聲明應用的期望狀態，控制器就會自動對其進行進程管理。

（5）服務資源（Service）

Service是建立在一組Pod對象之上的資源抽象，它通過標簽選擇器選定一組Pod對象，并為這組Pod對象定義一個統一的固定訪問入口（通常是一個IP地址），若Kubernetes集群存在DNS附件，它就會在Service創建時為其自動配置一個DNS名稱以便客戶端進行服務發現。到達Service IP的請求將被負載均衡至其后的端點——各個Pod對象之上，因此Service從本質上來講是一個四層代理服務。另外，Service還可以將集群外部流量引入到集群中來。

（6）存儲卷

存儲卷（Volume）是獨立于容器文件系統之外的存儲空間，常用于擴展容器的存儲空間并為它提供持久存儲能力。Kubernetes集群上的存儲卷大體可分為臨時卷、本地卷和網絡卷。臨時卷和本地卷都位于Node本地，一旦Pod被調度至其他Node，此種類型的存儲卷將無法訪問到，因此臨時卷和本地卷通常用于數據緩存，持久化的數據則需要放置于持久卷（persistent volume）之上。

（7）Name和Namespace

名稱（Name）是Kubernetes集群中資源對象的標識符，它們的作用域通常是名稱空間（Namespace），因此名稱空間是名稱的額外的限定機制。在同一個名稱空間中，同一類型資源對象的名稱必須具有唯一性。名稱空間通常用于實現租戶或項目的資源隔離，從而形成邏輯分組，如圖1-10所示。創建的Pod和Service等資源對象都屬于名稱空間級別，未指定時，它們都屬于默認的名稱空間“default”。

（8）Annotation

Annotation（注解）是另一種附加在對象之上的鍵值類型的數據，但它擁有更大的數據容量。Annotation常用于將各種非標識型元數據（metadata）附加到對象上，但它不能用于標識和選擇對象，通常也不會被Kubernetes直接使用，其主要目的是方便工具或用戶的閱讀及查找等。

（9）Ingress

Kubernetes將Pod對象和外部網絡環境進行了隔離，Pod和Service等對象間的通信都使用其內部專用地址進行，如若需要開放某些Pod對象提供給外部用戶訪問，則需要為其請求流量打開一個通往Kubernetes集群內部的通道，除了Service之外，Ingress也是這類通道的實現方式之一。