簡介 P2

Kubernetes 能自動調(diào)度、配置、監(jiān)管和故障處理，使開發(fā)者可以自主部署應(yīng)用，并且控制部署的頻率，完全脫離運維團隊的幫助。 Kubernetes 同時能讓運維團隊監(jiān)控整個系統(tǒng)，并且在硬件故障時重新調(diào)度應(yīng)用。 P2

Kubernetes 抽象了數(shù)據(jù)中心的硬件基礎(chǔ)設(shè)施，使得對外暴露的只是一個巨大的資源池。 在部署多組件應(yīng)用時， Kubernetes 會為每個組件都選擇一個合適的服務(wù)器，部署之后它能夠保證每個組件可以輕易地發(fā)現(xiàn)其他組件，并彼此之間實現(xiàn)通信。 P2

Kubernetes 系統(tǒng)的需求 P2

近年來，應(yīng)用程序的開發(fā)部署的變化原因： P2

• 大型單體應(yīng)用被拆解為更多的小型微服務(wù)
• 應(yīng)用運行所依賴的基礎(chǔ)架構(gòu)的變化

從單體應(yīng)用到微服務(wù) P2

單體應(yīng)用由很多個組件組成，這些組件緊密地耦合在一起，并且在同一個操作系統(tǒng)進程中運行，所以在開發(fā)、部署、管理的時候必須以同一個實體進行。 P2

單體應(yīng)用通常需要一臺能為整個應(yīng)用提供足夠資源的高性能服務(wù)器，有兩種方法可以應(yīng)對不斷增長的系統(tǒng)負(fù)荷： P3

• 垂直擴展：提升單機性能 —— 增加 CPU 、內(nèi)存或其他系統(tǒng)資源
  • 優(yōu)點：不需要應(yīng)用程序做任何變化
  • 缺點：成本很快會越來越高，并且通常會有瓶頸
• 水平擴展：增加服務(wù)器數(shù)量
  • 優(yōu)點：能線性擴充系統(tǒng)性能
  • 缺點：需要在架構(gòu)層面支持水平擴展，部分組件難于甚至不太可能去做水平擴展（像關(guān)系型數(shù)據(jù)庫）

所思

垂直擴展總會達(dá)到單機性能的極限，所以終極解決方案是水平擴展，同時也可以通過垂直擴展進行輔助。

仔細(xì)回想一下，發(fā)現(xiàn)我們平時也是這樣處理的。由于歷史原因，我們項目核心功能的大部分代碼在同一個應(yīng)用中，導(dǎo)致啟動就會占用大量資源，單機處理能力較差。在經(jīng)歷各種配置下壓測后，選擇了合適的配置，然后就直接水平擴展，并且逐漸將一些壓力大的接口拆成微服務(wù)提供接口或者直接處理各種請求。

如果單體應(yīng)用的任何一個部分不能擴展，整個應(yīng)用就不能擴展，除非我們想辦法把它拆分開。 P3

將應(yīng)用拆解為多個微服務(wù) P3

服務(wù)之間可以通過類似 HTTP 這樣的同步協(xié)議通信，也可以通過像 AMQP 這樣的異步協(xié)議通信，并且微服務(wù)也可以選用最適合的開發(fā)語言來實現(xiàn)。 P3

圖 1.1 單體應(yīng)用中的組件與獨立的微服務(wù)

每個微服務(wù)都是獨立的，可以獨立開發(fā)和部署。只要 API 不變或者向前兼容，改動一個微服務(wù)，并不會要求對其他微服務(wù)進行改動或者重新部署。 P3

微服務(wù)的擴容 P3

單體系統(tǒng)必須要對整個系統(tǒng)擴容，而微服務(wù)只需針對單個服務(wù)擴容。因此，我們可以選擇僅擴容那些需要更多資源的服務(wù)而保持其他的服務(wù)仍然維持在原來的規(guī)模。當(dāng)單體應(yīng)用因為其中一部分無法擴容而整體被限制擴容時，可以把應(yīng)用拆分成多個微服務(wù)，將能擴容的服務(wù)進行水平擴展，不能進行擴容的組件進行垂直擴展。 P4

圖 1.2 每個微服務(wù)能被單獨擴容

部署微服務(wù) P4

當(dāng)組件數(shù)量增加時，部署相關(guān)的決定就變得越來越困難。因為不僅組件部署的組合數(shù)在增加，而且組件間依賴的組合數(shù)也在以更大的因素增加，并且配置工作變得冗雜易錯，同時因為跨了多個進程和機器，調(diào)試代碼和定位異常調(diào)用變得困難。 P4

環(huán)境需求的差異 P5

因為組件之間依賴的差異性，應(yīng)用程序需要同一個庫的不同版本是不可避免的。當(dāng)多個應(yīng)用在同一個主機上運行就有可能會有依賴沖突。 P5

圖 1.3 多個應(yīng)用在同一主機上運行可能會有依賴沖突

為應(yīng)用程序提供一個一致的環(huán)境 P5

開發(fā)和運維團隊需要解決的一個最大的問題是程序運行環(huán)境的差異性： P5

• 開發(fā)環(huán)境和生產(chǎn)環(huán)境之間
• 各個生產(chǎn)機器之間
• 生產(chǎn)機器環(huán)境隨時間的推移而變化

為了減少會在生產(chǎn)環(huán)境才暴露的問題，最理想的做法就是讓應(yīng)用在開發(fā)和生產(chǎn)階段可以運行在完全一樣的環(huán)境下，它們有完全一樣的操作系統(tǒng)、庫、系統(tǒng)配置、網(wǎng)絡(luò)環(huán)境和其他所有條件。這個環(huán)境不會隨著時間的推移而變化，并且在一臺服務(wù)器上部署新的應(yīng)用時，不會影響機器上已有的應(yīng)用。 P6

邁向持續(xù)交付： DevOps 和無運維 P6

在過去，開發(fā)團隊的任務(wù)是創(chuàng)建應(yīng)用并交付給運維團隊，然后運維團隊部署應(yīng)用并使它運行。 P6

而現(xiàn)在，讓一個團隊參與應(yīng)用的開發(fā)、部署、運維的整個生命周期更好。這意味著開發(fā)者、 QA 和運維團隊彼此之間的合作需要貫穿整個流程。這種實踐被稱為 DevOps 。 P6

帶來的優(yōu)點 P6

• 開發(fā)者更多地在生產(chǎn)環(huán)境中運行應(yīng)用，能更好地理解用戶的需求和問題、運維團隊維護應(yīng)用所面臨的困難
• 開發(fā)者更趨向于盡快發(fā)布上線，能進行快速迭代
• 簡化部署流程，開發(fā)者自己部署應(yīng)用上線

讓開發(fā)者和系統(tǒng)管理員做他們最擅長的 P6

Kubernetes 通過對實際硬件做抽象，然后將自身暴露成一個平臺，用于部署和運行應(yīng)用程序。它允許開發(fā)者自己配置和部署應(yīng)用程序，而不需要系統(tǒng)管理員的任何幫助，讓系統(tǒng)管理員聚焦于保持底層基礎(chǔ)設(shè)施運轉(zhuǎn)正常的同時，不需要關(guān)注實際運行在平臺上的應(yīng)用程序。 P7

介紹容器技術(shù) P7

Kubernetes 使用 Linux 容器技術(shù)來提供應(yīng)用的隔離，需要先通過熟悉容器的基本知識來更深入地理解 Kubernetes 。 P7

什么是容器 P7

用 Linux 容器技術(shù)隔離組件 P7

容器允許你在同一臺機器上運行多個服務(wù)，不僅提供不同的環(huán)境給每個服務(wù)，而且將它們相互隔離。容器類似虛擬機，但開銷小很多。 P7

一個容器里運行但進程實際上運行在宿主機的操作系統(tǒng)上，但容器里的進程仍然是和宿主機的其他進程隔離的。對容器內(nèi)的進程本身而言，就好像是在機器和操作系統(tǒng)上運行的唯一一個進程。 P7

比較虛擬機和容器 P8

容器更加輕量級，它允許在相同的硬件上運行更多數(shù)量的組件。一個容器僅僅是運行在宿主機上被隔離的單個進程，僅消耗應(yīng)用容器消耗的資源，不會有其他進程的開銷。虛擬機則需要運行自己的一組系統(tǒng)進程，會產(chǎn)生除了組件進程消耗以外的額外計算資源損耗。 P8

因為虛擬機有額外開銷，所以沒有足夠的資源給每個應(yīng)用開一個專用的虛擬機，最終會將多個應(yīng)用程序分組塞進每個虛擬機。而容器能夠（也應(yīng)該）讓每個應(yīng)用有一個容器，最終可以讓同一臺裸機上運行更多的應(yīng)用程序。 P8

圖 1.4 使用虛擬機來隔離一組應(yīng)用程序和使用容器隔離單個應(yīng)用程序

運行在虛擬機里的應(yīng)用程序會執(zhí)行虛擬機操作系統(tǒng)的系統(tǒng)調(diào)用，然后虛擬機內(nèi)核會通過管理程序在宿主機上的物理 CPU 來執(zhí)行 x86 指令。而運行在容器內(nèi)部的應(yīng)用程序執(zhí)行的系統(tǒng)調(diào)用都會由宿主機上的同一個內(nèi)核執(zhí)行，此內(nèi)核是唯一一個在宿主機操作系統(tǒng)上執(zhí)行 x86 指令的內(nèi)核， CPU 也不需要做任何虛擬機所做的虛擬化。 P8

圖 1.5 虛擬機和容器中的應(yīng)用程序?qū)?CPU 的不同使用方式

虛擬機提供完全隔離的環(huán)境，因為每個虛擬機運行在自己的 Linux 內(nèi)核上，而容器都調(diào)用同一個內(nèi)核，存在安全隱患。 P9

每個虛擬機運行它自己的一組系統(tǒng)服務(wù)，而容器則不會，因為它們都運行在同一個操作系統(tǒng)上。因此運行一個容器不用像虛擬機那樣要開機，它的進程可以很快被啟動。 P10

容器實現(xiàn)隔離機制介紹 P10

• Linux 命名空間：使每個進程只看到它自己的系統(tǒng)視圖（文件、進程、網(wǎng)絡(luò)接口、主機名等）
• Linux 控制組 (cgroups) ：限制了進程能使用的資源量（ CPU 、內(nèi)存、網(wǎng)絡(luò)帶寬等）

用 Linux 命名空間隔離進程 P10

默認(rèn)情況下，每個 Linux 系統(tǒng)最初僅有一個命名空間，所有系統(tǒng)資源（文件系統(tǒng)、用戶 ID 、網(wǎng)絡(luò)接口等）屬于這一個命名空間。你能創(chuàng)建額外等命名空間，以及在它們之間組織資源。對于一個進程，可以在其中一個命名空間中運行它，進程將只能看到同一個命名空間下的資源。 P10

存在多種類型的多個命名空間，所以一個進程不僅只屬于某一個命名空間，而屬于每個類型的一個命名空間。 P10

限制進程的可用資源 P11

cgroups 是一個 Linux 內(nèi)核功能，它被用來限制一個進程或者一組進程的資源使用。一個進程的資源（ CPU 、內(nèi)存、網(wǎng)絡(luò)帶寬等）使用量不能超過被分配的量。 P11

Docker 容器平臺介紹 P11

Docker 的概念 P11

Docker 是一個打包、分發(fā)和運行應(yīng)用程序的平臺，它允許將應(yīng)用程序和應(yīng)用程序所依賴的整個環(huán)境打包在一起。 P11

三個主要概念組成了這種情形： P12

• 鏡像： Docker 鏡像里包含了打包的應(yīng)用程序及其所依賴的環(huán)境
• 鏡像倉庫： Docker 鏡像倉庫用于存放 Docker 鏡像，以及促進不同人和不同電腦之間共享這些鏡像
• 容器： Docker 容器通常是一個 Linux 容器，基于 Docker 鏡像被創(chuàng)建。一個運行中的容器是一個運行在 Docker 主機上的進程，但它和主機，以及所有運行在主機上的其他進程都是隔離的。這個進程也是資源受限的，僅能訪問和使用分配給它的資源（CPU 、內(nèi)存等）

構(gòu)建、分發(fā)和運行 Docker 鏡像 P12

開發(fā)人員首先構(gòu)建一個鏡像，然后把鏡像推到鏡像倉庫中，任何可以訪問鏡像倉庫的人都可以使用該鏡像。然后，他們可以將鏡像拉取到任何運行著 Docker 的機器上并運行鏡像。 Docker 會基于鏡像創(chuàng)建一個獨立的容器，并運行鏡像中指定的可執(zhí)行二進制文件。 P12

圖 1.6 Docker 鏡像、鏡像倉庫和容器

對比虛擬機和 Docker 容器 P12

圖 1.7 在 3 個虛擬機上運行 6 個應(yīng)用及用 Docker 容器運行它們

可以發(fā)現(xiàn)應(yīng)用 A 和應(yīng)用 B 無論是運行在虛擬機上還是作為兩個分離容器運行時都可以訪問相同的二進制和庫。 P13

應(yīng)用 A 和應(yīng)用 B 能訪問相同的文件是因為它們的容器是基于相同基礎(chǔ)層的鏡像被創(chuàng)建的，原理將在鏡像層中會介紹。

鏡像層 P14

Docker 鏡像由多層構(gòu)成，不同鏡像可能包含完全相同的層，因為這些 Docker 鏡像都是基于另一個鏡像之上構(gòu)建的，不同的鏡像都能使用相同的父鏡像作為它們的基礎(chǔ)鏡像。 P14

鏡像層不僅使分發(fā)高效，也有助于減少鏡像的存儲空間。 每一層僅被存一次，當(dāng)基于相同基礎(chǔ)層的鏡像被創(chuàng)建成兩個容器時，它們就能夠讀相同的文件。但是如果其中一個容器寫入某些文件，另外一個是無法看見文件變更的。因此，即使它們共享文件，仍然彼此隔離。 P14

容器鏡像層是只讀的。容器運行時，一個新的可寫層在鏡像層之上被創(chuàng)建。容器中進程寫入位于底層的一個文件時，此文件的一個拷貝在頂層被創(chuàng)建，進程寫的是此拷貝。 P14

容器鏡像可移植性的限制 P14

• 如果一個容器化的應(yīng)用需要一個特定的內(nèi)核版本，那么它可能不能在每臺機器上都工作
• 如果一臺機器上運行了一個不匹配的 Linux 內(nèi)核版本，或者沒有相同內(nèi)核模塊可用，那么此應(yīng)用就不能在其上運行
• 一個在特定硬件架構(gòu)之上編譯的容器化應(yīng)用，只能在有相同硬件架構(gòu)的機器上運行（例如：不能將一個 x86 架構(gòu)編譯的應(yīng)用容器化后，又期望它能運行在 ARM 架構(gòu)的機器上）

rkt —— 一個 Docker 的替代方案 P14

Docker 本身并不提供進程隔離，實際上容器是在 Linux 內(nèi)核之上使用諸如 Linux 命名空間和 cgroups 之類的內(nèi)核特性完成的， Docker 僅簡化了這些特性的使用。 P14

rkt （發(fā)音為 "rock-it"） 是另外一個 Linux 容器引擎，強調(diào)安全性、可構(gòu)建性并遵從開放標(biāo)準(zhǔn)，目前已經(jīng)停止維護。 P14

這里提到 rkt 的原因是，不應(yīng)該錯誤地認(rèn)為 Kubernetes 是一個專門為 Docker 容器設(shè)計的容器編排系統(tǒng)。實際上， Kubernetes 的核心遠(yuǎn)不止編排容器。容器恰好是在不同集群結(jié)點上運行應(yīng)用的最佳方式。 P15

Kubernetes 介紹 P15

深入淺出地了解 Kubernetes P15

Kubernetes 是一個軟件系統(tǒng)，它允許你在其上很容易地部署和管理容器化的應(yīng)用。它依賴于 Linux 容器的特性來運行異構(gòu)應(yīng)用，而無須知道這些應(yīng)用的內(nèi)部詳情，也不需要手動將這些應(yīng)用部署到每臺機器。因為這些應(yīng)用運行在容器里，它們不會影響運行在同一臺服務(wù)器上的其他應(yīng)用。 P15

Kubernetes 使你在數(shù)以千計的電腦節(jié)點上運行軟件時就像所有的節(jié)點是單個大節(jié)點已有。它將底層基礎(chǔ)設(shè)施抽象，這樣做同時簡化了應(yīng)用的開發(fā)、部署，以及對開發(fā)和運維團隊對管理。 P15

通過 Kubernetes 部署應(yīng)用程序時，你對集群包含多少節(jié)點都是一樣的。集群規(guī)模不會造成什么差異性，額外的集群節(jié)點只是代表一些額外的可用來部署應(yīng)用的資源。 P16

Kubernetes 的核心功能 P16

圖 1.8 Kubernetes 暴露整個數(shù)據(jù)中心作為單個開發(fā)平臺

上圖展示了一副最簡單的 Kubernetes 系統(tǒng)圖。整個系統(tǒng)由一個主節(jié)點和若干個工作節(jié)點組成。開發(fā)者把一個應(yīng)用列表提交到主節(jié)點， Kubernetes 會將它們部署到集群的工作節(jié)點。組件被部署在哪個節(jié)點對于開發(fā)者和系統(tǒng)管理員來說都不用關(guān)心。 P16

開發(fā)者能制定一些應(yīng)用必須一起運行， Kubernetes 將會在一個工作節(jié)點上部署它們。其他的將被分散部署到集群中，但是不管部署在哪兒，它們都能以相同的方式互相通信。 P16

幫助開發(fā)者聚焦核心應(yīng)用功能 P16

Kubernetes 可以被當(dāng)作集群的一個操作系統(tǒng)來看待。開發(fā)者可以依賴 Kubernetes 提供一些和基礎(chǔ)相關(guān)的服務(wù)，包括服務(wù)發(fā)現(xiàn)、擴容、負(fù)載均衡、自恢復(fù)，甚至集群的 leader 選舉。 P16

幫助運維團隊獲取更高的資源利用率 P16

Kubernetes 能在任何時間遷移應(yīng)用并通過混合和匹配應(yīng)用來獲得比手動調(diào)度高很多的資源利用率。 P16

Kubernetes 集群架構(gòu) P17

在硬件級別，一個 Kubernetes 集群由很多節(jié)點組成，這些節(jié)點被分成以下兩種類型： P17

• 主節(jié)點：承載著 Kubernetes 控制和管理整個集群系統(tǒng)的控制面板
• 工作節(jié)點：運行用戶實際部署的應(yīng)用

圖 1.9 組成一個 Kubernetes 集群的組件

控制面板 P17

控制面板用于控制集群并使它工作，控制面板的組件持有并控制集群狀態(tài)。它包含多個組件，組件可以運行在單個主節(jié)點上或者通過副本分別部署在多個主節(jié)點以確保高可用性。 P17

• Kubernetes API 服務(wù)器：你和其他控制面板組件都要和它通信
• Scheduler ：調(diào)度你的應(yīng)用（為應(yīng)用的每個可部署組件分配一個工作節(jié)點）
• Controller Manager ：執(zhí)行集群級別的功能，如復(fù)制組件、持續(xù)跟蹤工作節(jié)點、處理節(jié)點失敗等
• etcd ：一個可靠的分布式數(shù)據(jù)存儲，能持久化存儲集群配置

工作節(jié)點 P17

工作節(jié)點是運行容器化應(yīng)用的機器。運行、監(jiān)控和管理應(yīng)用服務(wù)的任務(wù)是由以下組件完成的： P17

• Docker, rkt 或其他的容器類型
• Kubelet ：與 API 服務(wù)器通信，并管理它所在節(jié)點的容器
• Kubernetes Services Proxy (kube-proxy) ：負(fù)責(zé)組件之間的負(fù)載均衡網(wǎng)絡(luò)流量

在 Kubernetes 中運行應(yīng)用 P18

在 Kubernetes 中運行應(yīng)用的步驟： P18

1. 將應(yīng)用打包進一個或多個容器鏡像
2. 將那些鏡像推送到鏡像倉庫
3. 將應(yīng)用的描述發(fā)布到 Kubernetes API 服務(wù)器

應(yīng)用的描述包括但不限于以下幾點： P18

• 容器鏡像或者包含應(yīng)用程序組件的容器鏡像
• 這些組件如何相互關(guān)聯(lián)
• 哪些組件需要同時運行在同一個節(jié)點上
• 哪些組件不需要同時運行
• 哪些組件為內(nèi)部或外部客戶提供服務(wù)且應(yīng)該通過單個 IP 地址暴露，并使其他組件可以發(fā)現(xiàn)

描述信息怎樣成為一個運行的容器 P18

當(dāng) API 服務(wù)器處理應(yīng)用的描述時，調(diào)度器調(diào)度指定的容器組到可用的工作節(jié)點上，調(diào)度是基于每組所需的計算資源，以及調(diào)度時每個節(jié)點未分配的資源。然后，那些節(jié)點上的 Kubelet 指示容器運行時（例如 Docker）拉取所需的鏡像并運行容器。 P18

圖 1.10 Kubernetes 體系結(jié)構(gòu)的基本概述和它之上運行的應(yīng)用程序

上圖可以幫助更好地理解如何在 Kubernetes 中部署應(yīng)用程序。應(yīng)用描述符列出了四個容器，并將它們分為三組（這些集合被稱為 pod ）。前兩個 pod 只包含一個容器，而最后一個包含兩個容器。這意味著兩個容器都需要協(xié)作運行，不應(yīng)該相互隔離。在每個 pod 旁邊，還可以看到一個數(shù)字，表示需要并行運行的每個 pod 的副本數(shù)量。在向 Kubernetes 提交描述符之后，它將把每個 pod 的指定副本數(shù)量調(diào)度到可用的工作節(jié)點上。節(jié)點上的 Kubelets將告知 Docker 從鏡像倉庫中拉取容器鏡像并運行容器。 P18

保持容器運行 P18

一旦應(yīng)用程序運行起來， Kubernetes 就會不斷地確認(rèn)應(yīng)用程序的部署狀態(tài)始終與你提供的描述相匹配。它會自動重啟崩潰或停止響應(yīng)的進程，并且能自動將故障節(jié)點上運行的所有容器遷移到新節(jié)點運行。 P18

擴展副本數(shù)量 P19

Kubernetes 可以根據(jù)指示增加附加的副本或者停止多余的副本，并且能根據(jù)實時指標(biāo)（如 CPU 負(fù)載、內(nèi)存消耗、每秒查詢或應(yīng)用程序公開的任何其他指標(biāo)）自動調(diào)整副本數(shù)。 P19

命中移動目標(biāo) P19

可以告訴 Kubernetes 哪些容器提供相同的服務(wù)，而 Kubernetes 將通過一個靜態(tài) IP 地址暴露所有容器，并將該地址暴露給集群中運行的所有應(yīng)用程序。這是通過環(huán)境變量完成的，但是客戶端也可以通過良好的 DNS 查找服務(wù) IP 。 kube-proxy 將確保到服務(wù)的連接可在提供服務(wù)的所有容器中實現(xiàn)負(fù)載均衡。服務(wù)的 IP 地址保持不變，因此客戶端始終可以連接到它的容器，即使它們在集群中移動。 P19

使用 Kubernetes 的好處 P20

• 簡化應(yīng)用程序部署：開發(fā)人員可以自己開始部署應(yīng)用程序，基本不需要了解組成集群的服務(wù)器
• 更好地利用硬件： Kubernetes 根據(jù)應(yīng)用程序的資源需求描述和每個節(jié)點上的可用資源選擇最合適的節(jié)點來運行應(yīng)用程序
• 健康檢查和自修復(fù)： Kubernetes 監(jiān)控應(yīng)用程序組件和它們運行的節(jié)點，并在節(jié)點出現(xiàn)故障時自動將它們重新調(diào)度到其他節(jié)點
• 自動擴容： Kubernetes 可以監(jiān)視每個應(yīng)用程序使用的資源，并不斷調(diào)整每個應(yīng)用程序的運行實例數(shù)量
• 簡化應(yīng)用開發(fā)
  • 開發(fā)環(huán)境和生產(chǎn)環(huán)境一樣有助于快速發(fā)現(xiàn) bug
  • 開發(fā)人員不需要實現(xiàn)他們通常會實現(xiàn)的特性，如：服務(wù)發(fā)現(xiàn)、擴容、負(fù)載均衡、自恢復(fù)，甚至集群的 leader 選舉
  • Kubernetes 可以自動檢測一個應(yīng)用的新版本是否有問題，如果有問題則立即停止其滾動更新

最后再吐槽一下七牛容器云團隊的翻譯可能有些部分不太好，第一章經(jīng)常出現(xiàn)翻譯不通順、有誤的情況，最后一部分還把單詞 DEVELOPMENT 看錯成了 DEPLOYMENT ，幸虧期間不停對照英文電子版修改書上的錯誤。