圖文并茂!一文掌握Kubernetes核心內(nèi)容

導(dǎo)語(yǔ)?|? 在云原生技術(shù)發(fā)展的浪潮之中，Kubernetes作為容器編排領(lǐng)域的事實(shí)標(biāo)準(zhǔn)和云原生領(lǐng)域的關(guān)鍵項(xiàng)目，其誕生與完善有著對(duì)應(yīng)的技術(shù)歷史背景，了解這個(gè)過(guò)程，對(duì)于系統(tǒng)的理解Kubernetes的核心思想、架構(gòu)設(shè)計(jì)、實(shí)現(xiàn)原理等會(huì)很有幫助。

在云原生技術(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誕生背景

如果要了解Kubernetes的誕生，就繞不開(kāi)整個(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ì)算之前，開(kāi)發(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%左右。

• OpenS tack

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

OpenStack給出了解決方案，它是一個(gè)開(kāi)源的分布式的平臺(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)用程序的部署與打包，仍然需要開(kāi)發(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)，但它并未包括中間件、開(kāi)發(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)用開(kāi)發(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開(kāi)發(fā)，是第一款開(kāi)源PaaS平臺(tái)（2011年）。支持多種框架、語(yǔ)言、運(yùn)行時(shí)環(huán)境、云平臺(tái)及應(yīng)用服務(wù)，使開(kāi)發(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ì)完善和開(kāi)放，2012年底dotClound瀕臨倒閉，創(chuàng)始人決定把內(nèi)部的打包平臺(tái)開(kāi)源出去。因此，2013年3月dotCloud公司在github平臺(tái)上開(kāi)源了其內(nèi)部的容器項(xiàng)目Docker。Github開(kāi)源之后，受到了業(yè)界的熱烈追捧，從而Docker大火。公司后來(lái)也改名為Docker。

Docker的成功，主要是通過(guò)鏡像完美解決了開(kāi)發(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)正式開(kāi)始。

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è)開(kāi)源集群管理器，最初是由Berkeley分校開(kāi)發(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è)，開(kāi)始一統(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)行了闡述。

二、Why?Kubernetes

Kubernetes源于希臘語(yǔ)，意為“舵手”。k8s縮寫是因?yàn)閗和s之間有八個(gè)字符的原因。它是google在2015開(kāi)源的容器調(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ì)象。

• 開(kāi)放插件 。支持系統(tǒng)資源插件化（比如計(jì)算、存儲(chǔ)、網(wǎng)絡(luò)）；同時(shí)也支持用戶自定義CRD和開(kāi)發(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)。舉例如下：命令式命令行：

      
        kubectl run nginx –image nginx
      
    

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

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

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

      
        kubectl apply –f nginx.yaml
      
    

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ì)象的模板。

• 開(kāi)放插件

Kubernetes的設(shè)計(jì)初衷就是支持可插拔的架構(gòu)，解決PaaS平臺(tái)使用不方便、不易擴(kuò)展等問(wèn)題。為了便于系統(tǒng)的擴(kuò)展，Kubernetes中開(kāi)放了以下接口可對(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ò)資源?？缰鳈C(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ā)布和部署公開(kāi)的存儲(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)度器）。

三、小結(jié)

根據(jù)以上兩個(gè)章節(jié)的闡述，對(duì)于文章開(kāi)頭的經(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，將開(kāi)發(fā)、運(yùn)維人員從繁重的應(yīng)用部署與管理工作中解放出來(lái)。到目前為止，Kubernetes已經(jīng)成為了容器編排的事實(shí)標(biāo)準(zhǔn)，是新一代的基于容器技術(shù)的PaaS平臺(tái)的重要底層框架。

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

參考資料：

1. Kuberne tes 文檔

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

3.深入剖 析 Kubernetes-張磊

4. Docker與k8s 的前世今生

5.https://dra vene ss.me/understanding-kubernetes/

?作者簡(jiǎn)介

尹飛

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

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

---

推薦閱讀

• Go語(yǔ)言愛(ài)好者周刊：第 160 期 — 竟然這么多人不理解 map 的 make 含義
  

福利
我為大家整理了一份 從入門到進(jìn)階的Go學(xué)習(xí)資料禮包 ，包含學(xué)習(xí)建議：入門看什么，進(jìn)階看什么。 關(guān)注公眾號(hào) 「polarisxu」，回復(fù)? ebook ?獲??；還可以回復(fù)「進(jìn)群」，和數(shù)萬(wàn) Gopher 交流學(xué)習(xí)。