[[281345]]

背景

PaaS

PaaS 技術(shù)，一句話概括就是：它提供了“應(yīng)用托管”的能力。

早期的主流做法基本上是租 AWS 或者 OpenStack 的虛擬機(jī)，然后把這些虛擬機(jī)當(dāng)作物理機(jī)一樣，用腳本或者手工的方式在上面部署應(yīng)用。這個(gè)過(guò)程中如何保證本地環(huán)境和云端環(huán)境的一致性是一個(gè)很大的課題，而提供云計(jì)算服務(wù)的公司的核心競(jìng)爭(zhēng)力就是比拼誰(shuí)做的更好。從某種意義上來(lái)說(shuō) PaaS 的出現(xiàn)，算是一個(gè)比較好的解決方案。

以 Cloud Foundry 為例，在虛擬機(jī)上部署上 Cloud Foundry 項(xiàng)目后，用戶可以很方便地把自己的應(yīng)用上云。以上帝視角來(lái)看這個(gè)過(guò)程：Cloud Foundry 最核心的是提供了一套應(yīng)用的打包和分發(fā)機(jī)制，它為不同的編程語(yǔ)言定義了不同的打包格式，它能把可執(zhí)行文件、啟動(dòng)參數(shù)等等一起打包成壓縮包然后上傳至 Cloud Foundry 存儲(chǔ)中心，最后由調(diào)度器選擇虛擬機(jī)，由虛擬機(jī)上的 Agent 下載并啟動(dòng)應(yīng)用。

分布式系統(tǒng)

隨著軟件的規(guī)模越來(lái)越大，業(yè)務(wù)模式越來(lái)越復(fù)雜，用戶量的上升、地區(qū)的分布、系統(tǒng)性能的苛刻要求都促成服務(wù)架構(gòu)從最初的單體變成 SOA 再到如今的微服務(wù)，未來(lái)還可能演變?yōu)?Service Mesh ，Serverless 等等。

如今，一個(gè)完整的后端系統(tǒng)不再是單體應(yīng)用架構(gòu)了，多年前的 DDD 概念重新回到大家的視線中。現(xiàn)在的系統(tǒng)被不同的職責(zé)和功能拆成多個(gè)服務(wù)，服務(wù)之間復(fù)雜的關(guān)系以及單機(jī)的單點(diǎn)性能瓶頸讓部署和運(yùn)維變得很復(fù)雜，所以部署和運(yùn)維大型分布式系統(tǒng)的需求急迫待解決。

容器技術(shù)

前面提到諸如 Cloud Foundry 的 PaaS，用戶必須為不同語(yǔ)言、不同框架區(qū)分不同的打包方式，這個(gè)打包過(guò)程是非常具有災(zāi)難性的。而現(xiàn)實(shí)往往更糟糕，當(dāng)在本地跑的好好的應(yīng)用，由于和遠(yuǎn)端環(huán)境的不一致，在打包后卻需要在云端各種調(diào)試，最終才能讓?xiě)?yīng)用“平穩(wěn)”運(yùn)行。

而 Docker 的出現(xiàn)改變了一切，它憑借鏡像解決了這個(gè)問(wèn)題。Docker 一不做二不休，干脆把完整的操作系統(tǒng)目錄也打包進(jìn)去，如此高的集成度，保證了云端和本地環(huán)境的高度一致，并且隨時(shí)隨地輕易地移植。

誰(shuí)也不知道就因?yàn)?ldquo;鏡像”這個(gè)簡(jiǎn)單的功能，Docker 完成了對(duì) PaaS 的降維打擊，占有了市場(chǎng)。此時(shí)，一些聰明的技術(shù)公司紛紛跟進(jìn) Docker，推出了自家的容器集群管理項(xiàng)目，并且稱之為 CaaS。

容器技術(shù)利用 Namespace 實(shí)現(xiàn)隔離，利用 Cgroups 實(shí)現(xiàn)限制;在 Docker 實(shí)現(xiàn)上，通過(guò)鏡像，為容器提供完整的系統(tǒng)執(zhí)行環(huán)境，并且通過(guò) UnionFS 實(shí)現(xiàn) Layer 的設(shè)計(jì)。

Docker 容器是完全使用沙箱機(jī)制，相互之間不會(huì)有任何接口。通過(guò) Docker，實(shí)現(xiàn)進(jìn)程、網(wǎng)絡(luò)、掛載點(diǎn)和文件隔離，更好地利用宿主機(jī)資源。Docker 強(qiáng)大到不需要關(guān)心宿主機(jī)的依賴，所有的一切都可以在鏡像構(gòu)建時(shí)完成，這也是 Docker 目前成為容器技術(shù)標(biāo)準(zhǔn)的原因。所以我們能看到在 Kubernetes 中默認(rèn)使用 Docker 作為容器(也支持 rkt)。

Kubernetes

鋪墊了這么多，終于說(shuō)到本文的主角了。說(shuō) Kubernetes 之前，不得不提 Compose、Swarm、Machine 三劍客，其實(shí)在 Kubernetes 還未一統(tǒng)江湖之前，它們已經(jīng)能實(shí)現(xiàn)大部分容器編排的能力了。但是在真正的大型系統(tǒng)上，它們卻遠(yuǎn)遠(yuǎn)不如 Mesosphere 公司出品的大型集群管理系統(tǒng)，更別說(shuō)之后的 Kubernetes 了。

在容器化和微服務(wù)時(shí)代，服務(wù)越來(lái)越多，容器個(gè)數(shù)也越來(lái)越多。Docker 如它 Logo 所示一樣，一只只鯨魚(yú)在大海里自由地游蕩，而 Kubernetes 就像一個(gè)掌舵的船長(zhǎng)，帶著它們，有序的管理它們，這個(gè)過(guò)程其實(shí)就是容器編排。

Kubernetes 起源于 Google，很多設(shè)計(jì)都是源自于 Borg，是一個(gè)開(kāi)源的，用于管理云平臺(tái)中多個(gè)主機(jī)上的容器化的應(yīng)用，Kubernetes 的目標(biāo)是讓部署容器化的應(yīng)用簡(jiǎn)單并且高效，并且提供了應(yīng)用部署，規(guī)劃，更新，維護(hù)的一種機(jī)制。

小結(jié)

至此，讀者了解了 Kubernetes 的前世今生，由 PaaS 的火熱，引爆了容器技術(shù)的戰(zhàn)爭(zhēng)，而贏得這場(chǎng)戰(zhàn)爭(zhēng)中最關(guān)鍵的即是擁有強(qiáng)大的容器編排的能力，而 Kubernetes 無(wú)疑是這場(chǎng)戰(zhàn)爭(zhēng)的勝利者。

設(shè)計(jì)理念

這一部分，我們會(huì)圍繞 Kubernetes 的四個(gè)設(shè)計(jì)理念看看這些做法能給我們帶來(lái)什么。

聲明式 VS 命令式

聲明式和命令式是截然不同的兩種編程方式，在命令式 API 中，我們可以直接發(fā)出服務(wù)器要執(zhí)行的命令，例如： “運(yùn)行容器”、“停止容器”等;在聲明式 API 中，我們聲明系統(tǒng)要執(zhí)行的操作，系統(tǒng)將不斷向該狀態(tài)驅(qū)動(dòng)。

我們常用的 SQL 就是一種聲明式語(yǔ)言，告訴數(shù)據(jù)庫(kù)想要的結(jié)果集，數(shù)據(jù)庫(kù)會(huì)幫我們?cè)O(shè)計(jì)獲取這個(gè)結(jié)果集的執(zhí)行路徑，并返回結(jié)果集。眾所周知，使用 SQL 語(yǔ)言獲取數(shù)據(jù)，要比自行編寫(xiě)處理過(guò)程去獲取數(shù)據(jù)容易的多。

apiVersion: extensions/v1beta1 
kind: Deployment 
metadata: 
 name: etcd-operator 
spec: 
 replicas: 1 
 template: 
 metadata: 
 labels: 
 name: etcd-operator 
 spec: 
 containers: 
 - name: etcd-operator 
 image: quay.io/coreos/etcd-operator:v0.2.1 
 env: 
 - name: MY_POD_NAMESPACE 
 valueFrom: 
 fieldRef: 
 fieldPath: metadata.namespace 
 - name: MY_POD_NAME 
 valueFrom: 
 fieldRef: 
 fieldPath: metadata.name 

我們來(lái)看看相同設(shè)計(jì)的 YAML，利用它，我們可以告訴 Kubernetes 最終想要的是什么，然后 Kubernetes 會(huì)完成目標(biāo)。

聲明式 API 使系統(tǒng)更加健壯，在分布式系統(tǒng)中，任何組件都可能隨時(shí)出現(xiàn)故障。當(dāng)組件恢復(fù)時(shí)，需要弄清楚要做什么，使用命令式 API 時(shí)，處理起來(lái)就很棘手。但是使用聲明式 API ，組件只需查看 API 服務(wù)器的當(dāng)前狀態(tài)，即可確定它需要執(zhí)行的操作。

顯式的 API

Kubernetes 是透明的，它沒(méi)有隱藏的內(nèi)部 API。換句話說(shuō) Kubernetes 系統(tǒng)內(nèi)部用來(lái)交互的 API 和我們用來(lái)與 Kubernetes 交互的 API 相同。

這樣做的好處是，當(dāng) Kubernetes 默認(rèn)的組件無(wú)法滿足我們的需求時(shí)，我們可以利用已有的 API 實(shí)現(xiàn)我們自定義的特性。

無(wú)侵入性

感謝 Docker 容器技術(shù)的流行，使得 Kubernetes 為大家提供了無(wú)縫的使用方式。在容器化的時(shí)代，我們的應(yīng)用達(dá)到鏡像后，不需要改動(dòng)就可以遨游在 Kubernetes 集群中。

Kubernetes 還提供存儲(chǔ) Secret、Configuration 等包含但不局限于密碼、證書(shū)、容器鏡像信息、應(yīng)用啟動(dòng)參數(shù)能力。如此，Kubernetes 以一種友好的方式將這些東西注入 Pod，減少了大家的工作量，而無(wú)需重寫(xiě)或者很大幅度改變?cè)械膽?yīng)用代碼。

有狀態(tài)的移植

在有狀態(tài)的存儲(chǔ)場(chǎng)景下，Kubernetes 如何做到對(duì)于服務(wù)和存儲(chǔ)的分離呢?假設(shè)一個(gè)大型分布式系統(tǒng)使用了多家云廠商的存儲(chǔ)方案，如何做到開(kāi)發(fā)者無(wú)感于底層的存儲(chǔ)技術(shù)體系，并且做到方便的移植?

為了實(shí)現(xiàn)這一目標(biāo)，Kubernetes 引入了 PersistentVolumeClaim(PVC)和 PersistentVolume(PV)API 對(duì)象。這些對(duì)象將存儲(chǔ)實(shí)現(xiàn)與存儲(chǔ)使用分離。

PersistentVolumeClaim 對(duì)象用作用戶以與實(shí)現(xiàn)無(wú)關(guān)的方式請(qǐng)求存儲(chǔ)的方法，通過(guò)它來(lái)抹除對(duì)底層 PersistentVolume 的差異性。這樣就使 Kubernetes 擁有了跨集群的移植能力。

架構(gòu)

首先要提及的是 Kubernetes 使用很具代表性的 C/S 架構(gòu)方式，Client 可以使用 kubectl 命令行或者 RESTful 接口與 Kubernetes 集群進(jìn)行交互。下面這張圖是從宏觀上看 Kubernetes 的整體架構(gòu)，每一個(gè) Kubernetes 集群都由 Master 節(jié)點(diǎn) 和 很多的 Node 節(jié)點(diǎn)組成。

Master

Master 是 Kubernetes 集群的管理節(jié)點(diǎn)，負(fù)責(zé)管理集群，提供集群的資源數(shù)據(jù)訪問(wèn)入口。擁有 Etcd 存儲(chǔ)服務(wù)，運(yùn)行 API Server 進(jìn)程，Controller Manager 服務(wù)進(jìn)程及 Scheduler 服務(wù)進(jìn)程，關(guān)聯(lián)工作節(jié)點(diǎn) Node。

Kubernetes API Server 提供 HTTP Rest 接口的關(guān)鍵服務(wù)進(jìn)程，是 Kubernetes 里所有資源的增、刪、改、查等操作的唯一入口。也是集群控制的入口進(jìn)程; Kubernetes Controller Manager 是 Kubernetes 所有資源對(duì)象的自動(dòng)化控制中心，它驅(qū)使集群向著我們所需要的最終目的狀態(tài); Kubernetes Schedule 是負(fù)責(zé) Pod 調(diào)度的進(jìn)程。

Node

Node 是 Kubernetes 集群架構(gòu)中運(yùn)行 Pod 的服務(wù)節(jié)點(diǎn)。Node 是 Kubernetes 集群操作的單元，用來(lái)承載被分配 Pod 的運(yùn)行，是 Pod 運(yùn)行的宿主機(jī)。關(guān)聯(lián) Master 管理節(jié)點(diǎn)，擁有名稱和 IP、系統(tǒng)資源信息。運(yùn)行 Docker Runtime、kubelet 和 kube-proxy。

kubelet 負(fù)責(zé)對(duì) Pod 對(duì)于的容器的創(chuàng)建、啟停等任務(wù)，發(fā)送宿主機(jī)當(dāng)前狀態(tài); kube-proxy 實(shí)現(xiàn) Kubernetes Service 的通信與負(fù)載均衡機(jī)制的重要組件; Docker Runtime 負(fù)責(zé)本機(jī)容器的創(chuàng)建和管理工作。

實(shí)現(xiàn)原理

為了盡可能地讓讀者能明白 Kubernetes 是如何運(yùn)作的，這里不會(huì)涉及到具體的細(xì)節(jié)實(shí)現(xiàn)，如有讀者感興趣可以自行參閱官網(wǎng)文檔。這里以一個(gè)簡(jiǎn)單的應(yīng)用部署示例來(lái)闡述一些概念和原理。

創(chuàng)建 Kubernetes 集群

介紹架構(gòu)的時(shí)候我們知道，Kubernetes 集群由 Master 和 Node 組成。

Master 管理集群的所有行為例如：應(yīng)用調(diào)度、改變應(yīng)用的狀態(tài)，擴(kuò)縮容，更新/降級(jí)應(yīng)用等。

Node 可以是是一個(gè)虛擬機(jī)或者物理機(jī)，它是應(yīng)用的“邏輯主機(jī)”，每一個(gè) Node 擁有一個(gè) Kubelet，Kubelet 負(fù)責(zé)管理 Node 節(jié)點(diǎn)與 Master 節(jié)點(diǎn)的交互，同時(shí) Node 還需要有容器操作的能力，比如 Docker 或者 rkt。理論上來(lái)說(shuō)，一個(gè) Kubernetes 為了應(yīng)對(duì)生產(chǎn)環(huán)境的流量，最少部署3個(gè) Node 節(jié)點(diǎn)。

當(dāng)我們需要在 Kubernetes 上部署應(yīng)用時(shí)，我們告訴 Master 節(jié)點(diǎn)，Master 會(huì)調(diào)度容器跑在合適的 Node 節(jié)點(diǎn)上。

我們可以使用 Minikube 在本地搭一個(gè)單 Node 的 Kubernetes 集群。

部署應(yīng)用

當(dāng)創(chuàng)建好一個(gè) Kubernetes 集群后，就可以把容器化的應(yīng)用跑在上面了。我們需要?jiǎng)?chuàng)建一個(gè) Deployment，它會(huì)告訴 Kubernetes Master 如何去創(chuàng)建應(yīng)用，也可以來(lái)更新應(yīng)用。

當(dāng)應(yīng)用實(shí)例創(chuàng)建后，Deployment 會(huì)不斷地觀察這些實(shí)例，如果 Node 上的 Pod 掛了，Deployment 會(huì)自動(dòng)創(chuàng)建新的實(shí)例并且替換它。相比傳統(tǒng)腳本運(yùn)維的方式，這種方式更加優(yōu)雅。

我們能通過(guò) kubectl 命令或者 YAML 文件來(lái)創(chuàng)建 Deployment，在創(chuàng)建的時(shí)候需要指定應(yīng)用鏡像和要跑的實(shí)例個(gè)數(shù)，之后 Kubernetes 會(huì)自動(dòng)幫我們處理。

查看 Pods 和 Nodes

下面來(lái)介紹下 Pod 和 Node：

當(dāng)我們創(chuàng)建好 Deployment 的時(shí)候，Kubernetes 會(huì)自動(dòng)創(chuàng)建 Pod 來(lái)承載應(yīng)用實(shí)例。Pod 是一個(gè)抽象的概念，像一個(gè)“邏輯主機(jī)”，它代表一組應(yīng)用容器的集合，這些應(yīng)用容器共享資源，包括存儲(chǔ)，網(wǎng)絡(luò)和相同的內(nèi)部集群 IP。

任何一個(gè) Pod 都需要跑在一個(gè) Node 節(jié)點(diǎn)上。Node 是一個(gè)“虛擬機(jī)器”，它可以是虛擬機(jī)也可以是物理機(jī)，一個(gè) Node 可以有多個(gè) Pods，Kubernetes 會(huì)自動(dòng)調(diào)度 Pod 到合適的 Node 上。

Service 與 LabelSelector

Pods 終有一死，也就是說(shuō) Pods 也有自己的生命周期，當(dāng)一個(gè) Pod 掛了的時(shí)候，ReplicaSet 會(huì)創(chuàng)建新的，并且調(diào)度到合適的 Node 節(jié)點(diǎn)上。考慮下訪問(wèn)的問(wèn)題，Pod 替換伴隨著 IP 的變化，對(duì)于訪問(wèn)者來(lái)說(shuō)，變化的 IP 是合理的;并且當(dāng)有多個(gè) Pod 節(jié)點(diǎn)時(shí)，如何 SLB 訪問(wèn)也是個(gè)問(wèn)題，Service 就是為了解決這些問(wèn)題的。

Service 是一個(gè)抽象的概念，它定義了一組邏輯 Pods，并且提供訪問(wèn)它們的策略。和其他對(duì)象一樣，Service 也能通過(guò) kubectl 或者 YAML 創(chuàng)建。Service 定義的 Pod 可以寫(xiě)在 LabelSelector 選項(xiàng)中(下文會(huì)介紹)，也存在不指定 Pods 的情況，這種比較復(fù)雜，感興趣的讀者可以自行查閱資料。

Service 有以下幾種類型：

• ClusterIP(默認(rèn))：在集群中內(nèi)部IP上暴露服務(wù)，此類型使Service只能從群集中訪問(wèn);
• NodePort：通過(guò)每個(gè) Node 上的 IP 和靜態(tài)端口(NodePort)暴露服務(wù)。NodePort 服務(wù)會(huì)路由到 ClusterIP 服務(wù)，這個(gè) ClusterIP 服務(wù)會(huì)自動(dòng)創(chuàng)建。通過(guò)請(qǐng)求 :，可以從集群的外部訪問(wèn)一個(gè) NodePort 服務(wù);
• LoadBalancer：使用云提供商的負(fù)載均衡器，可以向外部暴露服務(wù)。外部的負(fù)載均衡器可以路由到 NodePort 服務(wù)和 ClusterIP 服務(wù);
• ExternalName：通過(guò)返回 CNAME 和它的值，(適用于外部 DNS 的場(chǎng)景)

Labels 和 Selectors 能夠讓 Kubernetes 擁有邏輯運(yùn)算的能力，有點(diǎn)像 SQL。舉個(gè)例子：可以查找 app=hello_word 的所有對(duì)象，也可以查找 app in (a,b,c) abc的所有對(duì)象。

Labels是一個(gè)綁定在對(duì)象上的 K/V 結(jié)構(gòu)，它可以在創(chuàng)建或者之后的時(shí)候的定義，在任何時(shí)候都可以改變。

擴(kuò)容應(yīng)用

前文提到我們可以使用 Deployment 增加實(shí)例個(gè)數(shù)，下圖是原始的集群狀態(tài)：

我們可以隨意的更改 replicas (實(shí)例個(gè)數(shù))來(lái)擴(kuò)容，當(dāng)我們更改了 Deployment 中的 replicas 值時(shí)，Kubernetes 會(huì)自動(dòng)幫我們達(dá)到想要的目標(biāo)實(shí)例個(gè)數(shù)，如下圖

更新應(yīng)用

更新應(yīng)用和擴(kuò)容類似，我們可以更改 Deployment 中的容器鏡像，然后 Kubernetes 會(huì)幫住我們應(yīng)用更新(藍(lán)綠、金絲雀等方式)，通過(guò)此功能，我們還可以實(shí)現(xiàn)切換應(yīng)用環(huán)境、回滾、不停機(jī) CI/CD。下面是部署的過(guò)程，需要注意的是我們可以指定新創(chuàng)建的 Pod 最大個(gè)數(shù)和不可用 Pod 最大個(gè)數(shù)：

總結(jié)

到了最后，大家對(duì) Kubernetes 有個(gè)大概的了解了，但 Kubernetes 遠(yuǎn)遠(yuǎn)不止本文所介紹的這些內(nèi)容。在云原生概念逐漸清晰的今天，Kubernetes 作為 CNCF 中一個(gè)接地氣的落地項(xiàng)目，其重要性不言而喻。