簡介 P2

Kubernetes 能自動調(diào)度柬祠、配置、監(jiān)管和故障處理负芋，使開發(fā)者可以自主部署應(yīng)用漫蛔，并且控制部署的頻率，完全脫離運維團(tuán)隊的幫助。 Kubernetes 同時能讓運維團(tuán)隊監(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)進(jìn)程中運行，所以在開發(fā)捺信、部署酌媒、管理的時候必須以同一個實體進(jìn)行。 P2

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

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

所思

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

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

如果單體應(yīng)用的任何一個部分不能擴(kuò)展，整個應(yīng)用就不能擴(kuò)展衔瓮，除非我們想辦法把它拆分開浊猾。 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ù)進(jìn)行改動或者重新部署。 P3

微服務(wù)的擴(kuò)容 P3

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

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

部署微服務(wù) P4

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

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

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

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

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

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

• 開發(fā)環(huán)境和生產(chǎn)環(huán)境之間
• 各個生產(chǎn)機(jī)器之間
• 生產(chǎn)機(jī)器環(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)用時砚亭，不會影響機(jī)器上已有的應(yīng)用。 P6

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

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

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

帶來的優(yōu)點 P6

• 開發(fā)者更多地在生產(chǎn)環(huán)境中運行應(yīng)用沐寺，能更好地理解用戶的需求和問題、運維團(tuán)隊維護(hù)應(yīng)用所面臨的困難
• 開發(fā)者更趨向于盡快發(fā)布上線盖奈，能進(jìn)行快速迭代
• 簡化部署流程混坞，開發(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

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

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

比較虛擬機(jī)和容器 P8

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

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

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

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

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

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

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

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

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

用 Linux 命名空間隔離進(jìn)程 P10

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

存在多種類型的多個命名空間平夜，所以一個進(jìn)程不僅只屬于某一個命名空間蝶棋，而屬于每個類型的一個命名空間。 P10

限制進(jìn)程的可用資源 P11

cgroups 是一個 Linux 內(nèi)核功能吃溅，它被用來限制一個進(jìn)程或者一組進(jìn)程的資源使用。一個進(jìn)程的資源（ 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 鏡像，以及促進(jìn)不同人和不同電腦之間共享這些鏡像
• 容器： Docker 容器通常是一個 Linux 容器庐冯，基于 Docker 鏡像被創(chuàng)建孽亲。一個運行中的容器是一個運行在 Docker 主機(jī)上的進(jìn)程，但它和主機(jī)展父，以及所有運行在主機(jī)上的其他進(jìn)程都是隔離的墨林。這個進(jìn)程也是資源受限的，僅能訪問和使用分配給它的資源（CPU 犯祠、內(nèi)存等）

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

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

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

對比虛擬機(jī)和 Docker 容器 P12

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

可以發(fā)現(xiàn)應(yīng)用 A 和應(yīng)用 B 無論是運行在虛擬機(jī)上還是作為兩個分離容器運行時都可以訪問相同的二進(jìn)制和庫。 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)建呢诬。容器中進(jìn)程寫入位于底層的一個文件時涌哲，此文件的一個拷貝在頂層被創(chuàng)建胖缤，進(jìn)程寫的是此拷貝。 P14

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

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

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

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

rkt （發(fā)音為 "rock-it"） 是另外一個 Linux 容器引擎，強(qiáng)調(diào)安全性吗铐、可構(gòu)建性并遵從開放標(biāo)準(zhǔn)东亦，目前已經(jīng)停止維護(hù)。 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)用部署到每臺機(jī)器减江。因為這些應(yīng)用運行在容器里染突，它們不會影響運行在同一臺服務(wù)器上的其他應(yīng)用。 P15

Kubernetes 使你在數(shù)以千計的電腦節(jié)點上運行軟件時就像所有的節(jié)點是單個大節(jié)點已有辈灼。它將底層基礎(chǔ)設(shè)施抽象份企，這樣做同時簡化了應(yīng)用的開發(fā)、部署巡莹，以及對開發(fā)和運維團(tuán)隊對管理司志。 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)、擴(kuò)容愧膀、負(fù)載均衡拦键、自恢復(fù)，甚至集群的 leader 選舉檩淋。 P16

幫助運維團(tuán)隊獲取更高的資源利用率 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)用的機(jī)器鼓拧。運行、監(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)用打包進(jìn)一個或多個容器鏡像
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)的進(jìn)程捏鱼，并且能自動將故障節(jié)點上運行的所有容器遷移到新節(jié)點運行。 P18

擴(kuò)展副本數(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é)點
• 自動擴(kuò)容： 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)、擴(kuò)容帆赢、負(fù)載均衡驶睦、自恢復(fù)，甚至集群的 leader 選舉
  • Kubernetes 可以自動檢測一個應(yīng)用的新版本是否有問題匿醒，如果有問題則立即停止其滾動更新

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