微服務部署 Docker 和 Kubernetes <十七> 譯

時間 2019-11-10

標籤微服部署 docker kubernetes 十七欄目 Docker 简体版

原文原文鏈接

Docker

幾年前，Docker 以優雅的解決方案來實現不變交付（immutable delivery）。Docker 容許咱們將應用程序與它須要的全部依賴包(os、jvm、其餘應用程序依賴項等)打包，以輕量級、分層、鏡像格式進行打包。使用這些鏡像運行實例，這些實例運行在 linux 容器內的應用程序，這些容器具備獨立 cpu、內存、網絡和磁盤使用。從某種意義上講，這些容器是應用程序虛擬化或過程虛擬化的形式。他們容許一個進程執行，認爲它是運行的惟一方法(例如，ps，您只看到您的應用程序在那裏)，而且它徹底訪問cpu、內存、磁盤、網絡和其餘資源，但現實中它沒有，它只能使用它分配的資源。例如，我能夠啓動一個Docker容器分配cpu，內存段，限制網絡io的使用程度。從 linux 容器外部，在主機上，應用程序看起來就像另外一個過程。沒有虛擬化設備驅動程序、操做系統或網絡棧以及特殊的虛擬機監控程序。這只是個過程。這也意味着咱們能夠得到更多的應用程序，運行在一個單一的硬件上，以提升密度，而無需額外操做系統和其餘部分 vm 的開銷，這將須要實現相似的隔離質量。前端

發生的事情也不是革命性的，已構建到linux內核中(而且有一段時間)的名爲cgroups、名稱空間和chroot 的特性用於建立應用程序虛擬化的外觀。linux容器已經運行了10年多了，並且在solaris和freebsd中，流程虛擬化甚至在此以前也存在。傳統上，使用這些底層 linux 原語，甚至像 LXC 這樣的高級抽象，充其量也是複雜的。Docker來了，並簡化了 api 和用戶體驗圍繞 linux 容器。Docker帶來了一個單一客戶端cli，它能夠輕鬆地根據基於在的鏡像格式來建立這些 linux 容器，如今已經向開放容器倡議(Oci)中的更大社區打開了這個格式。這種易用性和鏡像格式正在改變咱們打包和交付軟件的方式。linux

一旦你有了一個鏡像，那麼就會把許多 linux容器的大量圈圈變得微不足道。這些層是創建在基礎鏡像(例如rhel、debian或其餘linux操做系統)和應用程序文件之間的增量。分發新應用程序只會將新層分發到現有基礎層之上。這使得非圖像比繞着膨脹的雲機器圖像更容易。此外，若是在基鏡像中找到了漏洞(例如shell衝擊、Heartbleed等)，則能夠重建基鏡像，而沒必要嘗試修補每一個vm。這樣能夠輕鬆地運行容器：而後它們能夠從開發人員的桌面移動到dev、qa或生產，而沒必要手動但願全部正確的依賴項都位於正確的位置(此應用程序使用jvm 1.六、1.七、1.8？)。若是須要使用更改(新應用程序)從新部署或修復基鏡像，那麼就只需更改須要更改的圖像中的層。git

Kubernetes

谷歌以規模運行linux容器而聞名。事實上，在google運行的「一切」都運行在linux容器中，而且由他們的 Borg 集羣管理平臺管理。谷歌前工程師 Joe·Beda 表示，該公司每週啓動二十億次以上的容易行爲。谷歌甚至能夠利用它建立底層 linux 技術，從而使容器成爲可能。2006，他們開始着手研究「process containers」，最終變成了cgroups，並被合併到 linux 內核代碼庫中，並在2008發佈。隨着其規模和規模的運行容器規模，這並不奇怪，谷歌已經對圍繞容器構建的平臺產生了這樣的影響。例如，一些流行的集裝箱管理項目在 Kubernetes 以前受到了谷歌的影響。github

最初的 CloudFoundry 建立者(德里克·科裏森和瓦迪姆·斯皮瓦克)曾在谷歌工做，並花了幾年時間使用谷歌的 Borg 集羣管理解決方案。
ApacheMesos是爲一篇博士論文而建立的，它的建立者(本·辛德曼)曾在谷歌實習，並與谷歌工程師就容器集羣、調度和管理問題進行了屢次交談。
Kubernetes是一個開源的容器集羣管理平臺和社區，最初是由在Google構建Borg的工程師建立的。

早在2013年，當 Docker 撼動了科技行業時，谷歌就決定，是時候開放下一代繼任者博格(Borg)的開源軟件了，他們將其命名爲 Kubernetes 。現在，Kubernetes是一個龐大的、開放的、快速發展的社區，Google、RedHat、CoreOS和許多其餘人(包括許多獨立的我的)都作出了貢獻。Kubernetes爲在Linux容器內大規模運行微服務集羣帶來了不少功能。Google已經將十多年的經驗打包成Kubernetes，所以可以利用這些知識和功能來部署咱們本身的微服務是改變遊戲規則的。網絡規模的公司已經這樣作多年了，他們中的許多公司(Netflix、亞馬遜等)不得不手工製做許多庫伯尼特如今已經好的原型機。 Kubernetes有幾個簡單的原語，在咱們深刻研究示例以前，您應該理解它們。在本章中，咱們將向您介紹這些概念；在接下來的一章中，咱們將使用它們來管理一個微服務集羣。shell

Pods

pod 是由一個或多個 Docker 容器組成的一組(就像一羣鯨魚？)。然而，一個典型的 pod 部署一般是一對一的帶有一個 Docker 容器.。若是您有SideCar、ADVINE或適配器部署，這些部署必須始終與應用程序位於同一位置，那麼將它們分組的方法是使用 Pod。此抽象也是保證容器關聯的一種方法(即，Docker容器A將始終部署在同一主機上的Docker容器B旁邊)。後端

Kubernetes 負責組織、安排和管理 Pod。當咱們提到運行在 Kubernetes 內部的應用程序時，它是在一個 Pod 內的Docker容器內運行的。一個 Pod 有它本身的 IP 地址，而且 Pod 內的全部容器都共享這個IP(這不一樣於普通的 Docker ，每一個容器都有一個IP地址)。當 volumes 被安裝到 Pod 時，它們也在運行在Pod 中的單個容器之間共享。api

關於 Pod 還有最後一件事要知道：它們是可替換的。這意味着它們能夠在任什麼時候候消失(要麼是由於服務崩潰，要麼是集羣殺死了它)。他們不像一個虛擬機，你關心和培育。Pod 在任什麼時候候均可以被摧毀。這符合咱們在微服務世界中的預期，即事情會失敗(而且會發生)，所以強烈鼓勵咱們在編寫微服務時考慮到這一前提。這是一個重要的區別，由於咱們將在下面幾節中討論其餘一些概念。微信

Labels

標籤是簡單的鍵/值對，咱們能夠將其分配給釋放=穩定或層=後端之類的 Pod。Pod(和其餘資源，但咱們將重點放在 Pod )能夠有多個標籤，分組和分類在鬆散耦合的方式，這變得至關明顯，尤爲當你使用Kubernetes。這並不奇怪，谷歌已經肯定了這樣簡單的結構，咱們能夠創建強大的集羣規模。在咱們標記了 Pod 以後，咱們可使用標籤選擇器來找出哪些 Pod 屬於哪一組。例如，若是咱們有一些豆莢標籤層=後端和其餘標籤層=前端，使用標籤選擇器表達式的層！=前端。咱們能夠選擇全部沒有標記爲「前端」的Pod。標籤選擇器用於下面兩個概念：複製控制器和服務。網絡

Replication Controllers

當談到在規模上運行微服務時，咱們可能會討論任何給定微服務的多個實例。Kubernetes有一個名爲ReplyingController的概念，即給定的一組微服務的副本數進行控制。例如，假設咱們想要管理標記爲tier=後端和Release=穩定的 Pod 的數量。咱們可使用適當的標籤選擇器建立一個複製控制器，而後可以用ReplicationController上的副本值控制集羣中的那些 Pod 的數量。若是咱們將副本計數設置爲10，那麼 Kubernetes 將協調它的當前狀態，以反映爲給定的 ReplyingController 運行的10個 Pod。若是如今只有五我的在跑，Kubernetes 就會再運行五個。若是有20個運行，Kubernetes將殺死10(其中10殺死是不肯定的，就你的應用程序而言)。Kubernetes將作它所須要的任何事情來收斂到所需的10個副本的狀態。您能夠想象使用ReplicationController很是容易地控制集羣的大小。咱們將在下一章中看到Rep許可控制器的例子。jvm

Services

咱們應該理解的最後一個 Kubernetes 的概念是Kubernetes 服務。ReplicationController能夠控制咱們所擁有的服務的表明的數量。咱們也看到 Pod 能夠被殺死(或者他們本身墜毀，或被殺，多是做爲一個恢復控制器的規模縮小事件的一部分)。所以，當咱們試圖與一組 Pod 通訊時，咱們不該該依賴它們的直接IP地址(每一個 Pod 都有本身的IP地址)，由於 Pod 能夠來來去去。咱們須要的是一種方法來分組 Pod，以發現他們在哪裏，如何與他們溝通，並可能對他們負載平衡。這正是 Kubernetes 服務機構的職責所在。它容許咱們使用標籤選擇器對咱們的 Pod 進行分組，並用單個虛擬(集羣)IP對它們進行抽象，而後咱們能夠用它來發現它們並與它們交互。咱們將在下一章中展現具體的例子。

有了這些簡單的概念、pods、標籤、ReplicationControllers和服務，咱們就能夠像 Google 已經學會的(或者不學會的)管理和擴展咱們的微服務。爲複雜的問題找出簡單的解決方案須要不少年和許多失敗，所以咱們強烈鼓勵您學習這些概念，並體驗使用Kubernetes管理容器爲您的微服務帶來的力量。

下章咱們看看怎麼使用！

原文：