在云原生技術(shù)發(fā)展的浪潮之中,，Kubernetes伴隨著容器技術(shù)的發(fā)展，成為了目前云時(shí)代的操作系統(tǒng),。Kubernetes作為容器編排領(lǐng)域的事實(shí)標(biāo)準(zhǔn)和云原生領(lǐng)域的關(guān)鍵項(xiàng)目,，已經(jīng)是云原生時(shí)代工程師最需要理解與實(shí)踐的核心技術(shù)。

但技術(shù)的發(fā)展從來(lái)都不是一蹴而就,，Kubernetes的誕生與完善也有其對(duì)應(yīng)的技術(shù)歷史背景,，了解其誕生與發(fā)展的過(guò)程，對(duì)于更加系統(tǒng)的理解其核心思想,、架構(gòu)設(shè)計(jì),、實(shí)現(xiàn)原理等內(nèi)容會(huì)大有幫助。因此,，本文從Kubernetes的誕生背景與Why Kubernetes兩個(gè)方面,，來(lái)完成對(duì)Kubernetes的概述。

如果要了解Kubernetes的誕生,，就繞不開整個(gè)云計(jì)算的發(fā)展歷程。了解了云計(jì)算的發(fā)展的過(guò)程,，就會(huì)明白,，Kubernetes是云計(jì)算發(fā)展到一定程度的必然產(chǎn)物。

（一）云計(jì)算發(fā)展歷程

云計(jì)算發(fā)展歷程的時(shí)間軸如下圖所示,，從物理機(jī)過(guò)渡到傳統(tǒng)的IaaS階段,，進(jìn)而發(fā)展為早期的PaaS，直至發(fā)展到如今的基于Kubernetes架構(gòu)的新興PaaS平臺(tái),。

用戶使用資源的形態(tài)也由早期的物理機(jī)過(guò)渡到虛擬機(jī),，再進(jìn)化到目前更輕量的Docker容器。本質(zhì)上云計(jì)算實(shí)現(xiàn)的關(guān)鍵突破就在于資源使用方式的改變,，其最初解決的核心的問(wèn)題就是應(yīng)用的托管即應(yīng)用部署與管理問(wèn)題,。

（二）早期物理機(jī)時(shí)代

云計(jì)算之前，開發(fā)者如需部署管理服務(wù),，需要根據(jù)需求,，進(jìn)行配置、管理與運(yùn)維物理機(jī),。整體上維護(hù)困難,，成本高昂,，重復(fù)勞動(dòng)，風(fēng)險(xiǎn)隨機(jī),。以至于當(dāng)年流傳著運(yùn)維的傳統(tǒng)藝能：上線拜祖,，如下圖所示：

在那個(gè)時(shí)代，應(yīng)用部署與管理面臨著以下諸多問(wèn)題：

• 硬件,、機(jī)房等維護(hù)成本高,。各個(gè)團(tuán)隊(duì)獨(dú)立搭建機(jī)群、運(yùn)維機(jī)器,。

• 應(yīng)用部署,、遷移、修復(fù)困難,。缺少統(tǒng)一的部署發(fā)布平臺(tái),；面對(duì)突發(fā)情況，缺少自動(dòng)化工具,，排查解決問(wèn)題依賴人工,，低效且成本巨大。

• 資源利用率低,。物理機(jī)的平均資源率不到10%,，有的甚至在5%左右，造成了資源的巨大浪費(fèi),。

• 應(yīng)用隔離性差,。多業(yè)務(wù)混部在一臺(tái)機(jī)器時(shí)，會(huì)產(chǎn)生干擾,。例如：當(dāng)某一應(yīng)用資源使用率突然提升,，會(huì)搶占其他應(yīng)用的可用資源。

（三）IaaS平臺(tái)

Infrastructure as a service (IaaS) 基礎(chǔ)設(shè)施即服務(wù),，用戶可以按需去申請(qǐng)基礎(chǔ)設(shè)施資源（包括：計(jì)算、存儲(chǔ),、網(wǎng)絡(luò)）,。

IaaS商業(yè)化道路上的一個(gè)標(biāo)志性事件：2006年AWS推出了EC2（亞馬遜彈性云端運(yùn)算），其基于Xen虛擬化技術(shù),，用戶可以在web界面上配置,、獲取虛擬機(jī)資源，部署應(yīng)用,。通過(guò)規(guī)?；瘉?lái)降低邊際成本。

• 虛擬化技術(shù)

IaaS的底層核心技術(shù)是虛擬化技術(shù),。虛擬化技術(shù)是一種資源關(guān)聯(lián)技術(shù),，是將計(jì)算機(jī)的各種實(shí)體資源,，如服務(wù)器、網(wǎng)絡(luò),、存儲(chǔ)等,，進(jìn)行抽象、整合,、管理與再分配的一種技術(shù),。最常用的一種方案是基于虛擬機(jī)（Hypervisor-based）的虛擬化實(shí)現(xiàn)。其通過(guò)一個(gè)軟件層的封裝,，提供和物理硬件相同的輸入輸出表現(xiàn),，實(shí)現(xiàn)了操作系統(tǒng)和計(jì)算機(jī)硬件的解耦，將OS和計(jì)算機(jī)從一對(duì)一轉(zhuǎn)變?yōu)槎鄬?duì)多（實(shí)際上是一對(duì)多）的關(guān)系,。該軟件層稱為虛擬機(jī)管理器（VMM/Hypervisor）,，它分為兩大類：裸金屬架構(gòu)、宿主機(jī)架構(gòu),。

裸金屬架構(gòu)：VMM直接安裝和運(yùn)行在物理機(jī)上,；VMM自帶虛擬內(nèi)核的管理和使用底層的硬件資源。業(yè)界的Xen,、VMWare ESX都是裸金屬架構(gòu),。

宿主機(jī)架構(gòu)：物理機(jī)上首先會(huì)裝一個(gè)操作系統(tǒng)，VMM安裝和運(yùn)行在操作系統(tǒng)上,；在VMM再去裝其他虛擬機(jī)操作系統(tǒng),，依賴與操作系統(tǒng)對(duì)硬件設(shè)備的支持與資源的管理。這種架構(gòu)的好處是,，VMM會(huì)變得非常簡(jiǎn)單,，因?yàn)榭梢曰诓僮飨到y(tǒng)去管理系統(tǒng)資源，VMM只需要做額外的虛擬化工作,。Oracle VirtualBox,，VMWare Workstation、KVM都是這種架構(gòu),，宿主機(jī)架構(gòu)是目前虛擬化技術(shù)的主流架構(gòu),。

下圖中，對(duì)比了物理機(jī)架構(gòu)與宿主機(jī)虛擬化架構(gòu)的區(qū)別,。

虛擬化架構(gòu)有如下的優(yōu)勢(shì)：

• 封裝應(yīng)用技術(shù)棧,。虛擬化鏡像中可以預(yù)裝一些通用的軟件與庫(kù)，來(lái)減少應(yīng)用對(duì)通用軟件與庫(kù)的依賴,。

• 提高底層資源的隔離性,。硬件層面做了隔離，虛擬機(jī)之間互不干擾,。

• 動(dòng)態(tài)調(diào)整機(jī)器,、資源配置,。虛擬化的配置可以動(dòng)態(tài)升降配，用戶可以按自己的需求調(diào)整,。

• 提高資源利用率,。資源使用率從平均不到10%提高到了15%左右。

• OpenStack

當(dāng)物理機(jī)轉(zhuǎn)變?yōu)樘摂M機(jī)之后,，如何對(duì)多臺(tái)虛擬機(jī)的資源進(jìn)行管理與調(diào)度,，成為了一個(gè)新的問(wèn)題。

OpenStack給出了解決方案,，它是一個(gè)開源的分布式的平臺(tái),，能夠統(tǒng)一管理多個(gè)服務(wù)器，按用戶需求進(jìn)行分配與調(diào)度虛擬機(jī),。其本質(zhì)上是一組分配,、管理虛擬機(jī)的自動(dòng)化工具腳本。

目前,，OpenStack已經(jīng)發(fā)展成了IaaS的主流解決方案,，即：OpenStack as IaaS。目前主流IaaS云服務(wù)廠商底層都是利用OpenStack技術(shù),。

IaaS平臺(tái)一定程度上提升了物理機(jī)的資源利用率,，由物理機(jī)時(shí)代的低于10%，提升到了15%,。但虛擬機(jī)對(duì)資源利用率的提升仍存在一定的局限性,，其相對(duì)笨重，啟動(dòng)慢,，自身消耗大（其完整運(yùn)行了一套操作系統(tǒng)）,，自身加載就要消耗幾百兆的內(nèi)存資源。此外,，虛擬機(jī)可以預(yù)裝一些軟件,，一定程度簡(jiǎn)化了應(yīng)用程序的依賴安裝。但應(yīng)用程序的部署與打包,，仍然需要開發(fā)人員各自解決,，仍未高效的完成應(yīng)用部署與分發(fā)。

（四）PaaS平臺(tái)

Platform-as-a-Service (PaaS)平臺(tái)即服務(wù),。PaaS提供了包括服務(wù)器、存儲(chǔ)空間和網(wǎng)絡(luò)等基礎(chǔ)結(jié)構(gòu),，但它并未包括中間件,、開發(fā)工具、數(shù)據(jù)庫(kù)管理系統(tǒng)等,。PaaS旨在支持應(yīng)用程序的完整生命周期：生成,、部署,、管理和更新，提供應(yīng)用的托管能力,。

在IaaS階段,，服務(wù)廠商只提供虛擬機(jī)，虛擬機(jī)之上的軟件棧都由用戶管理,，包括操作系統(tǒng),、持久化層、中間層,、用戶程序,。在IaaS層面用戶只是減少了關(guān)心底層硬件，而PaaS層面希望能夠進(jìn)一步解放用戶,，讓用戶真正只需關(guān)注應(yīng)用本身,。

• PaaS主要功能

目前一個(gè)成熟的PaaS平臺(tái)應(yīng)具備的主要功能，如下圖所示：

早期PaaS平臺(tái),，更多關(guān)注運(yùn)行時(shí)環(huán)境與依賴服務(wù),，而目前的PaaS平臺(tái)新增大量的支持服務(wù)，包括：認(rèn)證授權(quán),、系統(tǒng)日志,、應(yīng)用監(jiān)控等，以上都是應(yīng)用開發(fā)的常見(jiàn)需求,。原則上：共用內(nèi)容就應(yīng)該抽象出統(tǒng)一通用的組件,，由框架和平臺(tái)來(lái)實(shí)現(xiàn)。讓用戶只關(guān)心邏輯或應(yīng)用本身,，避免重復(fù)造輪子,。

• PaaS早期代表Cloud Foundry

PaaS在成熟之前也經(jīng)歷了幾個(gè)階段，而PaaS早期的代表就不得不提Cloud Foundry,。Cloud Foundry由VMWare開發(fā),，是第一款開源PaaS平臺(tái)（2011年）。支持多種框架,、語(yǔ)言,、運(yùn)行時(shí)環(huán)境、云平臺(tái)及應(yīng)用服務(wù),，使開發(fā)人員能夠快速進(jìn)行應(yīng)用的部署,，無(wú)需擔(dān)心任何基礎(chǔ)架構(gòu)的問(wèn)題。

它主要功能包括以下：

• 應(yīng)用打包,、分發(fā)部署

• 以容器的方式運(yùn)行應(yīng)用

• 均衡負(fù)載

• 服務(wù)監(jiān)控,、異常重啟

Cloud Foundry的出現(xiàn)，其描繪了PaaS平臺(tái)的初步形態(tài)，推動(dòng)了PaaS的發(fā)展,，具有劃時(shí)代的意義,。

但其最終并未成為PaaS主流，是因?yàn)槠浯嬖谝粋€(gè)核心不足：它只對(duì)應(yīng)用和配置進(jìn)行了打包,，而沒(méi)有打包整體依賴（所謂的整體依賴包括：中間環(huán)境,、操作系統(tǒng)文件）。所以它的包在跨平臺(tái)運(yùn)行時(shí),，會(huì)出現(xiàn)運(yùn)行失敗的現(xiàn)象,。這個(gè)問(wèn)題非常致命。

而且,，早期Cloud Foundry主要是針對(duì)單一Web應(yīng)用的管理,，對(duì)分布式應(yīng)用所需的各項(xiàng)能力均未涉及，例如：服務(wù)發(fā)現(xiàn),、彈性擴(kuò)縮等,。

（五）Docker

Docker公司的前身是dotCloud，它是2010年成立,，提供Paas服務(wù)的平臺(tái),。但當(dāng)時(shí)Cloud Foundry做的相對(duì)完善和開放，2012年底dotClound瀕臨倒閉,，創(chuàng)始人決定把內(nèi)部的打包平臺(tái)開源出去,。因此，2013年3月dotCloud公司在github平臺(tái)上開源了其內(nèi)部的容器項(xiàng)目Docker,。Github開源之后,，受到了業(yè)界的熱烈追捧，從而Docker大火,。公司后來(lái)也改名為Docker,。

Docker的成功，主要是通過(guò)鏡像完美解決了開發(fā),、測(cè)試,、生產(chǎn)環(huán)境不一致的問(wèn)題。它的口號(hào)是：Build,、Shipand Run any App,、Anywhere，即一處構(gòu)建,，到處運(yùn)行,。

Docker的核心技術(shù)有三個(gè)：NameSpaces做視圖隔離、Cgroups做資源限制,，UnionFS聯(lián)合文件系統(tǒng),，統(tǒng)一mount,。通俗理解：NameSpaces、Cgroups通給進(jìn)程設(shè)置屬性,，實(shí)現(xiàn)進(jìn)程的隔離與限制，UnionFS給進(jìn)程構(gòu)造文件系統(tǒng),。這三項(xiàng)技術(shù)均有l(wèi)inux內(nèi)核提供,，Docker本身并沒(méi)有創(chuàng)造新的技術(shù)。

但是Docker創(chuàng)造性的通過(guò)鏡像整體打包了應(yīng)用的依賴環(huán)境,，包括：操作系統(tǒng)文件,、中間依賴層、APP,。

• 整體打包之后,，鏡像變大，又該如何優(yōu)化,？

Docker通過(guò)鏡像分層復(fù)用的方式進(jìn)行了優(yōu)化,。共用只讀層，節(jié)省存儲(chǔ)空間,，提高鏡像推送,、拉取效率，鏡像的操作是增量式,。

• 當(dāng)分層之后,，在宿主機(jī)上如何合并多個(gè)層？

利用UnionFS實(shí)現(xiàn)合并,，多個(gè)只讀層加一個(gè)可寫層mount成一個(gè)目錄,。并且上面的層會(huì)覆蓋下面的層，當(dāng)對(duì)底層的只讀層修改時(shí)會(huì)采用寫時(shí)復(fù)制策略（copy-on-write）,。寫時(shí)復(fù)制的含義：當(dāng)另一個(gè)層第一次需要寫入該文件時(shí)（在構(gòu)建鏡像或運(yùn)行容器時(shí)）,，該文件會(huì)被復(fù)制到該讀寫層并被修改。該機(jī)制大大減少了容器的啟動(dòng)時(shí)間（啟動(dòng)時(shí)新建的可寫層只有很少的文件寫入）,，但容器運(yùn)行后每次第一次修改的文件都需要先將整個(gè)文件復(fù)制到container layer中,。

如下圖所示，Docker相比于虛擬機(jī)操作系統(tǒng)級(jí)的資源隔離,，實(shí)現(xiàn)了進(jìn)程級(jí)資源隔離,，極大提升了資源利用率。具備以下特點(diǎn)：

• 進(jìn)程級(jí)隔離,，更輕量

• 更低消耗系統(tǒng)資源

• 更快速啟動(dòng)

• 更快交付與部署

（六）容器編排

當(dāng)Docker解決了應(yīng)用打包的問(wèn)題后,，PaaS上應(yīng)用大規(guī)模部署與管理的問(wèn)題愈發(fā)突出。此時(shí),，業(yè)內(nèi)明白：容器本身沒(méi)有“價(jià)值”,，有價(jià)值的是容器編排。

容器編排(Orchestration)：對(duì)Docker及容器進(jìn)行更高級(jí)更靈活的管理，按照用戶的意愿和整個(gè)系統(tǒng)的規(guī)則,，完全自動(dòng)化的處理好容器之間的各種關(guān)系（對(duì)象之間的關(guān)系遠(yuǎn)重要于對(duì)象本身）,。

容器技術(shù)做為底層基礎(chǔ)技術(shù)，只能用來(lái)創(chuàng)建和啟動(dòng)容器的小工具,，最終只能充當(dāng)平臺(tái)項(xiàng)目的“幕后英雄”,。用戶最終部署的還是他們的網(wǎng)站、服務(wù),、數(shù)據(jù)庫(kù),，甚至是云計(jì)算業(yè)務(wù)。這就需要一個(gè)真正的PaaS平臺(tái),，讓用戶把自己的容器應(yīng)用部署在此之上,。

在以上的歷史背景之下，2014年左右,，Docker,、Mesos、Google相繼發(fā)布自己的PaaS平臺(tái),，容器編排之爭(zhēng)正式開始,。

Docker發(fā)布了Swarm平臺(tái)，Swarm擅長(zhǎng)跟Docker生態(tài)無(wú)縫集成,，docker用戶可以低成本過(guò)渡,。其最大亮點(diǎn)是使用Docker項(xiàng)目原有的容器管理API來(lái)完成集群管理。例如：?jiǎn)螜C(jī)Docker項(xiàng)目: docker run “我的容器”,。集群Docker項(xiàng)目：docker run-H“我的Swarm集群API地址” “我的容器”,。

Mesos平臺(tái)，擅長(zhǎng)大規(guī)模集群的調(diào)度與管理,。它是Apache基金會(huì)下的一個(gè)開源集群管理器,，最初是由Berkeley分校開發(fā)的。它為應(yīng)用程序提供了跨集群的資源管理和調(diào)度API,。之后轉(zhuǎn)向支持PaaS業(yè)務(wù),，推出了Marathon項(xiàng)目。它是一個(gè)高度成熟的PaaS項(xiàng)目,，旨在讓用戶便捷管理一個(gè)數(shù)萬(wàn)級(jí)別的物理機(jī)集群,，可使用容器在這個(gè)集群里自由部署應(yīng)用。

Google推出的是Kubernetes平臺(tái),，整個(gè)系統(tǒng)的前身是Borg系統(tǒng),，Kubernetes平臺(tái)是Google在容器化基礎(chǔ)設(shè)施領(lǐng)域十多年來(lái)實(shí)踐經(jīng)驗(yàn)的沉淀與升華。

經(jīng)過(guò)近3年的角逐,，容器編排之爭(zhēng)的勝利者是Kubernetes,。

• 2017年9月,，Mesos宣布支持Kubernetes。

• 2017年10月,，Docker官方支持Kubernetes,。

• 2018年3月，Kubernetes正式從CNCF畢業(yè),，開始一統(tǒng)江湖,。（所謂畢業(yè)是指這個(gè)產(chǎn)品可以直接使用在生產(chǎn)環(huán)境）

• 目前，Kubernetes已經(jīng)成為容器編排領(lǐng)域的事實(shí)標(biāo)準(zhǔn),。

Kubernetes，讀者一定會(huì)有一個(gè)疑問(wèn)：為什么最后是Kubernetes,？

每個(gè)人對(duì)這個(gè)問(wèn)題,，都有一些自己的理解，本文從技術(shù)方面對(duì)該問(wèn)題進(jìn)行了闡述,。

Kubernetes源于希臘語(yǔ)，意為“舵手”,。k8s縮寫是因?yàn)閗和s之間有八個(gè)字符的原因,。它是google在2015開源的容器調(diào)度編排的平臺(tái)。它是建立在Google大規(guī)模運(yùn)行生產(chǎn)工作負(fù)載（Borg系統(tǒng)）十幾年經(jīng)驗(yàn)的基礎(chǔ)上,， 結(jié)合了社區(qū)中最優(yōu)秀的想法和實(shí)踐,，已經(jīng)成為了目前容器編排的事實(shí)標(biāo)準(zhǔn)。

其實(shí)看到Docker和Kubernetes的Logo,，就可以很快明白Kubernetes的作用,。Docker的Logo是一條鯨魚船，運(yùn)載著許多封裝好的集裝箱(container),，代表著一次打包到處運(yùn)行的意圖,。而Kubernetes的Logo就是這條船的方向舵！

對(duì)于Why Kubernetes,？很多人都有自己的理解,，接下來(lái)筆者從技術(shù)的角度，闡述一下自己的觀點(diǎn),。Kubernetes技術(shù)上的成功,，個(gè)人認(rèn)為核心在于三個(gè)關(guān)鍵點(diǎn)：

• 成熟的技術(shù)前身

• 優(yōu)秀的框架架構(gòu)

• 良好的核心設(shè)計(jì)

（一）Kubernetes前身

Kubernetes的基礎(chǔ)特性，并不是幾個(gè)工程師突然“拍腦袋”想出來(lái)的東西,，而是 Google 公司在容器化基礎(chǔ)設(shè)施領(lǐng)域多年來(lái)實(shí)踐經(jīng)驗(yàn)的沉淀與升華,。這個(gè)實(shí)踐與升華的過(guò)程，就是Kubernetes的前身是Borg系統(tǒng),。

Borg系統(tǒng)一直以來(lái)都被譽(yù)為Google內(nèi)部最強(qiáng)大的“秘密武器”,，是Google整個(gè)基礎(chǔ)設(shè)施的核心依賴,。很多應(yīng)用框架已經(jīng)運(yùn)行在Borg上多年，其中包括了內(nèi)部的MapReduce,、GFS,、BigTable、Megastore等,，上層應(yīng)用程序更是有這些耳熟能詳?shù)漠a(chǎn)品：Gmail,、Google Docs、Google Search等,。

其架構(gòu)圖如下所示：

架構(gòu)分析：

• 集群分為Master節(jié)點(diǎn)與Worker節(jié)點(diǎn),。

• Master節(jié)點(diǎn)由多臺(tái)機(jī)器構(gòu)成，一主多備,。

• BorgMaster由主進(jìn)程和scheduler進(jìn)程組成,，主進(jìn)程處理clientRpc請(qǐng)求，scheduler負(fù)責(zé)調(diào)度tasks,。

• Borglet是Worker節(jié)點(diǎn)上的代理進(jìn)程,，用于啟停tasks。

根據(jù)2015年4月google發(fā)布的Large-scale clustermanagement at Google with Borg,，與其2020年7月發(fā)布的Borg: the nextgeneration,，兩篇論文中的數(shù)據(jù)表明：Borg系統(tǒng)通過(guò)對(duì)在線任務(wù)與離線任務(wù)進(jìn)行混合部署，可以節(jié)約20%-30%的資源,，極大提高了資源利用率,。下表是2011年與2019年的Borg集群，與2015年AWS,、Facebool,、Twitter數(shù)據(jù)中心資源利用率的對(duì)比圖。

對(duì)于成熟高效的Borg系統(tǒng),，繼承者Kubernetes從中獲得了寶貴的經(jīng)驗(yàn)：

• Pods,。Pod是Kubernetes中調(diào)度的單位。它是一個(gè)或多個(gè)容器在其中運(yùn)行的資源封裝,。保證屬于同一 Pod的容器可以一起調(diào)度到同一臺(tái)計(jì)算機(jī)上,，并且可以通過(guò)本地卷共享狀態(tài)。Borg有一個(gè)類似的抽象,，稱為alloc（“資源分配”的縮寫）,。

• Service。Kubernetes使用服務(wù)抽象支持命名和負(fù)載均衡：帶名字的服務(wù),，會(huì)映射到由標(biāo)簽選擇器定義的一組動(dòng)態(tài)Pod集,。集群中的任何容器都可以使用服務(wù)名訪問(wèn)服務(wù)。

• Labels,。通過(guò)使用標(biāo)簽組織Pod,，Kubernetes比Borg支持更靈活的集合,，標(biāo)簽是用戶附加到Pod（實(shí)際上是系統(tǒng)中的任何對(duì)象）的任意鍵值對(duì)。

• Ip-per-Pod,。Borg容器只能共享主機(jī)網(wǎng)絡(luò),，必須將端口作為調(diào)度的資源。在Kubernetes中IP是以Pod為單位分配的,，一個(gè)Pod內(nèi)部的所有容器共享一個(gè)網(wǎng)絡(luò)堆棧,。

（二）Kubernetes架構(gòu)

• 整體架構(gòu)

Kubernets整體架構(gòu)，如下所示：

整個(gè)系統(tǒng)由控制面(Master)與數(shù)據(jù)面(Worker Node)組成,。Master核心組件：

• API Server,。集群控制的唯一入口，它是各個(gè)組件通信的中心樞紐,。

• controller-mananger,。負(fù)責(zé)編排，用于調(diào)節(jié)系統(tǒng)狀態(tài),。內(nèi)置了多種控制器（DeploymentController、- ServiceController,、NodeController,、HPAController等）是Kubernetes維護(hù)業(yè)務(wù)和集群狀態(tài)的最核心組件。

• scheduler,。集群的調(diào)度器,，它負(fù)責(zé)在Kubernetes集群中為Pod資源對(duì)象找到合適節(jié)點(diǎn)并使其在該節(jié)點(diǎn)上運(yùn)行。

• etcd,。用于存儲(chǔ)Kubernetes集群的數(shù)據(jù)與狀態(tài)信息,。

Kubernetes架構(gòu)具備高可用：一方面Master節(jié)點(diǎn)高可用；另一方面所部署的業(yè)務(wù)也是高可用的,。系統(tǒng)高可用的核心在于冗余部署,，當(dāng)某一個(gè)節(jié)點(diǎn)或程序出現(xiàn)異常時(shí)，其他節(jié)點(diǎn)或程序能分擔(dān)或替換工作,。Master節(jié)點(diǎn)高可用,，主要由以下幾個(gè)方面的設(shè)計(jì)實(shí)現(xiàn)：

• Master由多臺(tái)服務(wù)器構(gòu)成。

• API Server多實(shí)例同時(shí)工作,，負(fù)載均衡,。

• etcd多節(jié)點(diǎn)，一主多從,。

• controller-manager與scheduler搶主實(shí)現(xiàn),。

Work Node節(jié)點(diǎn)由以下組件組成：

• kubelet：負(fù)責(zé)Pod對(duì)應(yīng)容器的創(chuàng)建、啟停等任務(wù),，是部署在Node上的一個(gè)agent,。

• kube-proxy：實(shí)現(xiàn)Service通信與負(fù)載均衡機(jī)制,。

• 容器運(yùn)行時(shí)(如Docker)：負(fù)責(zé)本機(jī)的容器創(chuàng)建和管理。

• API Server中心樞紐

Kubernetes中API Server的核心功能是提供Kubernetes各類資源對(duì)象（如Pod,、RC,、Service等）的增、刪,、改,、查及Watch等HTTP REST接口，成為集群內(nèi)各個(gè)功能模塊之間數(shù)據(jù)交互和通信的中心樞紐,，是整個(gè)系統(tǒng)的數(shù)據(jù)總線和數(shù)據(jù)中心,。除此之外，它還是集群管理的API入口,，提供了完備的集群安全機(jī)制,。API Server是由多實(shí)例同時(shí)工作，各個(gè)組件通過(guò)負(fù)載均衡連到具體的API Server實(shí)例上,。

如下所示,，各組件與API Server通信時(shí)，采用List-Watch機(jī)制,，通過(guò)API server獲取etcd配置與狀態(tài)信息,，進(jìn)而觸發(fā)行為。以下圖為例是kubectl創(chuàng)建一個(gè)deployment時(shí),，各個(gè)組件與API Server的流程交互,。

Api Server的作用：

• 集群控制、訪問(wèn)的唯一入口,，統(tǒng)一的認(rèn)證,、流量控制、鑒權(quán)等,。

• ectd數(shù)據(jù)的緩存層,，請(qǐng)求不會(huì)輕易穿透到etcd。

• 集群中各個(gè)模塊的中心樞紐,，各個(gè)模塊之間解耦,。

• 便于模塊插件的擴(kuò)展（其他模塊List、Watch,、Update ApiServer即可實(shí)現(xiàn)擴(kuò)展功能）,。

（三）Kubernetes核心設(shè)計(jì)

Kubernetes取的巨大的成功，與它良好的核心設(shè)計(jì)緊密相關(guān),。筆者認(rèn)為Kubernetes有三大核心設(shè)計(jì)：

• 編排抽象,。容器平臺(tái)核心點(diǎn)不在于創(chuàng)建和調(diào)度容器，而是在上層架構(gòu)抽象出各種對(duì)象,，便于去統(tǒng)一管理,。Kubernetes創(chuàng)造性的抽象出了各個(gè)編排的關(guān)系,，例如親密關(guān)系(Pod對(duì)象)、訪問(wèn)關(guān)系（Service對(duì)象）等,。

• 聲明式API,。聲明式API是整個(gè)系統(tǒng)自動(dòng)化的核心要點(diǎn)，kubernetes提供了以聲明式API的方式將抽象對(duì)外暴露,，同時(shí)也便于了用戶管理對(duì)象,。

• 開放插件。支持系統(tǒng)資源插件化（比如計(jì)算,、存儲(chǔ),、網(wǎng)絡(luò)）；同時(shí)也支持用戶自定義CRD和開發(fā)Operator,。

• Pod對(duì)象

Kubernetes在對(duì)象抽象方面,，核心創(chuàng)新在于Pod對(duì)象的設(shè)計(jì)。容器設(shè)計(jì)本身是一種“單進(jìn)程”模型,。該表述不是指容器里只能啟動(dòng)一個(gè)進(jìn)程,，而是指容器無(wú)法管理多個(gè)進(jìn)程。只有容器內(nèi)PID=1的進(jìn)程生命周期才受到容器管理（該進(jìn)程退出后,，容器也會(huì)退出）,，其他進(jìn)程都是PID=1的進(jìn)程的子進(jìn)程。根據(jù)容器設(shè)計(jì)模式,，傳統(tǒng)架構(gòu)中多個(gè)緊密配合的業(yè)務(wù)進(jìn)程（例如業(yè)務(wù)進(jìn)程與日志收集進(jìn)程，業(yè)務(wù)進(jìn)程與業(yè)務(wù)網(wǎng)絡(luò)代理進(jìn)程）應(yīng)該部署成多個(gè)容器,。但這些容器之間存在親密的關(guān)系,，需要一起調(diào)度和直接共享某些資源（網(wǎng)絡(luò)和存儲(chǔ)）。

Kubernetes抽象出一個(gè)Pod對(duì)象,，是一組（一個(gè)或多個(gè)）容器,， 這些容器共享存儲(chǔ)、網(wǎng)絡(luò)等,， 這些容器是相對(duì)緊密的耦合在一起的,。Pod是Kubernetes內(nèi)創(chuàng)建和管理的最小可調(diào)度單元，調(diào)度過(guò)程是按Pod整體所需資源一起進(jìn)行調(diào)度的,。Pod本身只是邏輯上的概念,，在容器管理這層并不認(rèn)識(shí)Pod對(duì)象。

Pod的實(shí)現(xiàn)需要使用一個(gè)中間容器（Infra容器）,，在這個(gè)Pod中,，Infra容器永遠(yuǎn)是第一個(gè)被創(chuàng)建的容器，用戶定義的其他容器通過(guò)Join Network Namespace的方式與Infra容器關(guān)聯(lián)在一起,。抽象一個(gè)中間容器的原因在于各個(gè)業(yè)務(wù)容器是對(duì)等的,，其啟動(dòng)沒(méi)有嚴(yán)格的先后順序,，需借助中間容器實(shí)現(xiàn)共享網(wǎng)絡(luò)和存儲(chǔ)的目的。

其中,，Node,、Pod與容器三者關(guān)系，如下圖所示,。Node表示一臺(tái)機(jī)器,，可調(diào)度多個(gè)Pod，而一個(gè)Pod內(nèi)又能包含多個(gè)容器,。

至此,，再來(lái)通過(guò)Kubernetes中各個(gè)對(duì)象的關(guān)聯(lián)關(guān)系來(lái)更為深刻的理解Pod的意義。下圖可以看出,，Pod其實(shí)是整個(gè)編排過(guò)程中操作的核心,，很多對(duì)象直接或間接的同Pod相關(guān)聯(lián)。

• Service對(duì)象

Kubernetes編排抽象的另一個(gè)核心對(duì)象是Service對(duì)象,，它統(tǒng)一的解決了集群內(nèi)服務(wù)發(fā)現(xiàn)與負(fù)載均衡,。Service是對(duì)一組提供相同功能的Pod的抽象，為其提供了一個(gè)統(tǒng)一的入口,。Service通過(guò)標(biāo)簽選擇服務(wù)后端,，匹配標(biāo)簽的Pod IP和端口列表組成endpoints，由kube-proxy負(fù)責(zé)將請(qǐng)求負(fù)載到相關(guān)的endpoints,。

下圖是kube-proxy通過(guò)iptables模式來(lái)實(shí)現(xiàn)Service的過(guò)程,，Service對(duì)象有一個(gè)虛擬clusterIP，集群內(nèi)請(qǐng)求訪問(wèn)clusterIP時(shí),，會(huì)由iptables規(guī)則負(fù)載均衡到后端endpoints,。

• 聲明式API

Declarative（聲明式設(shè)計(jì)）指的是一種軟件設(shè)計(jì)理念和編程方式，描述了目標(biāo)狀態(tài),，由工具自行判斷當(dāng)前狀態(tài)并執(zhí)行相關(guān)操作至目標(biāo)狀態(tài),。聲明式強(qiáng)調(diào)What，目標(biāo)是什么,。而Imperative(命令式)需要用戶描述一系列詳細(xì)指令來(lái)達(dá)到期望的目標(biāo)狀態(tài),。命令式強(qiáng)調(diào)How，具體如何做,。

下圖描繪了一個(gè)場(chǎng)景：目標(biāo)副本數(shù)為3,。對(duì)于聲明式而言，用戶設(shè)定目標(biāo)為3,，系統(tǒng)獲取當(dāng)前副本數(shù)為2,，系統(tǒng)判定當(dāng)前值與目標(biāo)值的差為1，便自行加1，最終實(shí)現(xiàn)副本數(shù)為3的目標(biāo)狀態(tài),。而對(duì)于命令式,，需用戶判斷當(dāng)前副本數(shù)為2，用戶給出指令副本+1,，系統(tǒng)接收用戶指令,，執(zhí)行副本數(shù)+1操作，最終系統(tǒng)副本數(shù)為3,。

kubernetes的一大核心設(shè)計(jì)就是采用了聲明式API,，利用該設(shè)計(jì)思想有效的實(shí)現(xiàn)了系統(tǒng)的自動(dòng)化運(yùn)行。Kubernetes聲明式API指定了集群期望的運(yùn)行狀態(tài),，集群控制器會(huì)通過(guò)List&Watch機(jī)制來(lái)獲取當(dāng)前狀態(tài),，并根據(jù)當(dāng)前狀態(tài)自動(dòng)執(zhí)行相應(yīng)的操作至目標(biāo)狀態(tài)。

Kubernetes中,，用戶通過(guò)提交定義好的API對(duì)象來(lái)聲明期望狀態(tài),，系統(tǒng)允許有多個(gè)API寫端，以PATCH方式對(duì)API對(duì)象進(jìn)行修改,。Kubectl工具支持三種對(duì)象管理方式：命令式命令行,、命令式對(duì)象配置(yaml)、聲明式對(duì)象配置(yaml),。舉例如下：命令式命令行：

命令式對(duì)象配置：

kubectl create –f nginx.yamlkubectl replace –f nginx.yaml

以上先kubectl create再kubectl replace的操作,，與命令式命令行不存在本質(zhì)區(qū)別。只是把具體命令寫入yaml配置文件中而已,。聲明式對(duì)象配置：

Kubernetes推薦使用：聲明式對(duì)象配置(YAML),。kubectl replace執(zhí)行過(guò)程是通過(guò)新的YAML文件中的API對(duì)象來(lái)替換原有的API對(duì)象，而Kubectl apply執(zhí)行了一個(gè)對(duì)原有API對(duì)象的PATCH操作,。除此之外,，YAML配置文件用于Kubernetes對(duì)象的定義，還會(huì)有以下收益：

• 便捷性：不必添加大量的參數(shù)到命令行中執(zhí)行命令,。

• 靈活性：YAML可以創(chuàng)建比命令行更加復(fù)雜的結(jié)構(gòu)。

• 可維護(hù)性：YAML文件可以通過(guò)源頭控制,，跟蹤每次操作,；并且對(duì)象配置可以存儲(chǔ)在源控制系統(tǒng)中（比如Git）；對(duì)象配置同時(shí)也提供了用于創(chuàng)建對(duì)象的模板,。

• 開放插件

Kubernetes的設(shè)計(jì)初衷就是支持可插拔的架構(gòu),，解決PaaS平臺(tái)使用不方便、不易擴(kuò)展等問(wèn)題,。為了便于系統(tǒng)的擴(kuò)展,，Kubernetes中開放了以下接口可對(duì)系統(tǒng)資源（計(jì)算、網(wǎng)絡(luò)、存儲(chǔ)）插件進(jìn)行擴(kuò)展,，可分別對(duì)接不同的后端來(lái)實(shí)現(xiàn)自己的業(yè)務(wù)邏輯,。

CRI（Container Runtime Interface）：容器運(yùn)行時(shí)接口，提供計(jì)算資源,。CRI接口設(shè)計(jì)的一個(gè)重要原則是只關(guān)注接口本身,，而不關(guān)心具體實(shí)現(xiàn)，kubelet就只需要跟這個(gè)接口打交道,。而作為具體的容器項(xiàng)目,，比如Docker、rkt,、containerd,、kata container它們就只需要自己提供一個(gè)該接口的實(shí)現(xiàn)，然后對(duì)kubelet暴露出gRPC服務(wù)即可,。簡(jiǎn)單來(lái)說(shuō),，CRI主要作用就是實(shí)現(xiàn)了kubelet和容器運(yùn)行時(shí)之間的解耦。

CNI（Container Network Interface）：容器網(wǎng)絡(luò)接口,，提供網(wǎng)絡(luò)資源,。跨主機(jī)容器間的網(wǎng)絡(luò)互通已經(jīng)成為基本要求,，K8S網(wǎng)絡(luò)模型要求所有容器都可以直接使用IP地址與其他容器通信,，而無(wú)需使用NAT；所有宿主機(jī)都可以直接使用IP地址與所有容器通信,，而無(wú)需使用NAT,。反之亦然。容器自己的IP地址,，和別人（宿主機(jī)或者容器）看到的地址是完全一樣的,。K8S提供了一個(gè)插件規(guī)范，稱為容器網(wǎng)絡(luò)接口(CNI),，只要滿足K8S的基本需求,，第三方廠商可以隨意使用自己的網(wǎng)絡(luò)棧，通過(guò)使用overlay網(wǎng)絡(luò)來(lái)支持多子網(wǎng)或者一些個(gè)性化使用場(chǎng)景,，所以出現(xiàn)很多優(yōu)秀的CNI插件被添加到Kubernetes集群中,。

CSI（Container Storage Interface）：容器存儲(chǔ)接口，提供存儲(chǔ)資源,。K8S將存儲(chǔ)體系抽象出了外部存儲(chǔ)組件接口,，第三方存儲(chǔ)廠商可以發(fā)布和部署公開的存儲(chǔ)插件，而無(wú)需接觸Kubernetes核心代碼,，同時(shí)為Kubernetes用戶提供了更多的存儲(chǔ)選項(xiàng),。例如：AWS,、NFS、Ceph,。

Kubernetes除了對(duì)系統(tǒng)資源可插件擴(kuò)展外,，也可以自定義CRD（Custom Resource Definition）來(lái)擴(kuò)展API對(duì)象，同時(shí)也支持編寫Operator對(duì)CRD進(jìn)行控制,。例如：對(duì)于一些有狀態(tài)應(yīng)用（etcd）,，可以定義新的CRD對(duì)象，并編寫特定的Operator（本質(zhì)上是新的controller）去實(shí)現(xiàn)控制邏輯,。

Kubernetes的調(diào)度器Scheduler也是可以擴(kuò)展的,，可以部署自定義的調(diào)度器，在整個(gè)集群中還可以同時(shí)運(yùn)行多個(gè)調(diào)度器實(shí)例,，通過(guò) pod.Spec.schedulerName 來(lái)選擇具體指定調(diào)度器（默認(rèn)使用內(nèi)置的調(diào)度器）,。

根據(jù)以上兩個(gè)章節(jié)的闡述,，對(duì)于文章開頭的經(jīng)典問(wèn)題：如何才能有效的部署與管理應(yīng)用,？到Kubernets大放異彩的今天，已經(jīng)給出了答案：

• 應(yīng)用部署與管理的問(wèn)題,，利用Docker+Kubernetes的方式已經(jīng)完美解決,。

• Kubernetes的強(qiáng)大功能還進(jìn)一步提供了：均衡負(fù)載、服務(wù)發(fā)現(xiàn),、彈性擴(kuò)縮,、自動(dòng)修復(fù)等分布式應(yīng)用管理的能力。

感謝Kubernetes,，將開發(fā),、運(yùn)維人員從繁重的應(yīng)用部署與管理工作中解放出來(lái)。到目前為止,，Kubernetes已經(jīng)成為了容器編排的事實(shí)標(biāo)準(zhǔn),，是新一代的基于容器技術(shù)的PaaS平臺(tái)的重要底層框架。

Kubernetes的成熟,，拉開了轟轟烈烈的云原生技術(shù)發(fā)展的大幕,！

參考資料：

1.Kubernetes 文檔

2.Kubernetes權(quán)威指南 第五版

3.深入剖析 Kubernetes-張磊

4.Docker與k8s的前世今生

5.https://draveness.me/understanding-kubernetes/

尹飛

騰訊后臺(tái)開發(fā)工程師

騰訊后臺(tái)開發(fā)工程師，專注于后臺(tái)游戲開發(fā),，擅長(zhǎng)分布式開發(fā),，有豐富的C++、Lua,、Go語(yǔ)言使用經(jīng)驗(yàn),。