Kubernetes起源于Google的Borg系統(tǒng)。Borg是在2003年開發(fā)的一個(gè)大規(guī)模集群管理系統(tǒng)。它支撐Google數(shù)千個(gè)應(yīng)用程序（十萬(wàn)個(gè)應(yīng)用程序）。

運(yùn)行時(shí)，Kubernetes指定了CRI，網(wǎng)絡(luò)指定了CNI，存儲(chǔ)指定了CSI，各種設(shè)備通過(guò)device plugin 接入?？傊拖褚粋€(gè)鋼筋混凝土的框架，至于最終的房間的設(shè)計(jì)都是交給第三方根據(jù)自己的業(yè)務(wù)場(chǎng)景去實(shí)現(xiàn)的。

Yaml是一種數(shù)據(jù)組織格式，非常強(qiáng)大。與JSON通過(guò)大括號(hào)的方法分級(jí)相比，Yaml采用了縮進(jìn)的方式組織數(shù)據(jù)。Yaml文件支持三種數(shù)據(jù)結(jié)構(gòu)，分別是散列表、數(shù)組及復(fù)合結(jié)構(gòu)。

聲明式API是相對(duì)于命令式API來(lái)說(shuō)的。所謂的聲明式API是指只需要告訴機(jī)器最終結(jié)果，不用關(guān)心實(shí)現(xiàn)過(guò)程和細(xì)節(jié)，而命令式API則是一種面向過(guò)程的操作，需要告訴機(jī)器每一步應(yīng)如何執(zhí)行，才能達(dá)到最終目標(biāo)。

聲明式API是Kubernetes最重要的設(shè)計(jì)思想，通過(guò)Yaml或者json文件定義最終的資源形態(tài)，剩下的交給 Kubernetes去完成。Kubernetes獲取用戶提交的資源聲明后，通過(guò)多個(gè)組件相互協(xié)作，最終滿足用戶定義的資源需求。

Kubernetes是容器管理系統(tǒng)，但是它并不是將單個(gè)容器當(dāng)作管理單位的。容器的設(shè)計(jì)哲學(xué)是希望在一個(gè)容器里面只運(yùn)行一個(gè)進(jìn)程，那么針對(duì)這個(gè)進(jìn)程的監(jiān)控程序該如何部署，以及和這個(gè)進(jìn)程強(qiáng)耦合的sidecar程序?qū)⑷绾稳ゲ渴饎t變得復(fù)雜起來(lái)。Kubernetes創(chuàng)新地將多個(gè)容器組合到一起，產(chǎn)生一個(gè)新的資源管理單位，叫作Pod。Pod是Kubernetes調(diào)度和管理的最小單位，每個(gè)Pod都是由若干個(gè)容器組成，Pod共享網(wǎng)絡(luò)命名空間和存儲(chǔ)。

就是通過(guò)Pod的設(shè)計(jì)方式將多個(gè)緊密關(guān)聯(lián)的容器共享網(wǎng)絡(luò)、存儲(chǔ)等資源，通過(guò)對(duì)Pod生命周期的管理，完成對(duì)一組容器的生命周期管理。

Service 和Endpoint

容器的地址不是固定的。如果集群內(nèi)部的容器相互調(diào)用或者是被集群外部訪問(wèn)調(diào)用， Kubernetes提供了一種負(fù)載均衡和服務(wù)發(fā)現(xiàn)機(jī)制。Service是Kubernetes提供的一種負(fù)載均衡器，每個(gè)服務(wù)都有一個(gè)虛IP（headless Service除外），這個(gè)虛IP是固定不變的，實(shí)現(xiàn)方式可以是iptables或者ipvs，這個(gè)IP并非是綁定到某一個(gè)網(wǎng)卡上面，所以ping是不同的。

Kubernetes物理資源抽象

Kubernetes 將管理的物理資源抽象成指定的類型和對(duì)應(yīng)的計(jì)量單位，如 CPU （millicores）、內(nèi)存（B）、磁盤和GPU等。其中，CPU和內(nèi)存是Kubernetes原生支持的，其他資源擴(kuò)展可以通過(guò)device plugin方式加入。這些資源可以分為兩種，一種是可壓縮資源，譬如CPU，當(dāng)Pod使用超過(guò)設(shè)置的limits值時(shí)，Pod中進(jìn)程使用CPU會(huì)被限制，但不會(huì)被kill；另一種是將不可壓縮資源當(dāng)作資源，譬如內(nèi)存。當(dāng)資源不足時(shí)，先kill掉優(yōu)先級(jí)低的Pod。在實(shí)際使用過(guò)程中，通過(guò)OOM分?jǐn)?shù)值來(lái)實(shí)現(xiàn)，OOM分?jǐn)?shù)值為0～1000。當(dāng)然，磁盤也屬于不可壓縮的資源。

Kubernetes組件分析

Kubernetes 的節(jié)點(diǎn)包含兩種角色：Master 節(jié)點(diǎn)和 Node 節(jié)點(diǎn)。Master 節(jié)點(diǎn)上面部署apiserver、scheduler、controllermanager(replication controller、node controller等）, Node節(jié)點(diǎn)上面部署kubelet和proxy。當(dāng)然也可以將它們部署到一起，只是生產(chǎn)環(huán)境通常不建議這樣做。Kubernetes整體架構(gòu)如圖10-1所示。

Kubernetes API 接口主要分為組、版本和資源三層，接口層次如圖10-2所示。對(duì)于“/apis/batch/v1/jobs”接口，batch是組，v1是版本，jobs是資源。Kubernetes的核心資源都放在“/api”接口下，擴(kuò)展的接口放在“/apis”下。

Apiserver啟動(dòng)后會(huì)將每個(gè)版本的接口都注冊(cè)到一個(gè)核心的路由分發(fā)器（Mux）中。當(dāng)客戶端請(qǐng)求到達(dá)Apiserver后，首先經(jīng)過(guò)Authentication認(rèn)證和Authorization授權(quán)。認(rèn)證支持Basic、Token及證書認(rèn)證等。授權(quán)目前默認(rèn)使用的是RBAC。經(jīng)過(guò)路由分發(fā)到指定的接口，為了兼容多個(gè)資源版本，請(qǐng)求的不同版本的資源類型會(huì)統(tǒng)一轉(zhuǎn)化為一個(gè)內(nèi)部資源類型，然后進(jìn)入Admission準(zhǔn)入控制和Validation資源校驗(yàn)，在準(zhǔn)入控制采用插件機(jī)制，用戶可以定義自己的注入控制器驗(yàn)證，并更改資源配置。資源校驗(yàn)主要是驗(yàn)證參數(shù)是否合法，必傳參數(shù)是否齊備等。最后再轉(zhuǎn)化到用戶最初的資源版本，并保存到Etcd中。Apiserver請(qǐng)求處理流程圖如圖10-3所示。

其他容器管理平臺(tái)

除了Kubernetes，還有其他一些容器管理平臺(tái)，比如OpenShift、Rancher等管理平臺(tái)。在之前的版本中，它們都獨(dú)立開發(fā)了一套容器管理方案，但2018年后，無(wú)論是OpenShift，還是Rancher，都已經(jīng)全面轉(zhuǎn)向Kubernetes，把重點(diǎn)放到了Devops及Kubernetes集群管理等方面，容器的管理則全部交給Kubernetes。

Kubernetes的生態(tài)圈

第一個(gè)出場(chǎng)的就是Prometheus，結(jié)合cAdvisor和各種exporter采集器，Prometheus可以監(jiān)控容器、主機(jī)及Kubernetes性能指標(biāo)，并做到自動(dòng)發(fā)現(xiàn)（不需要為每一個(gè)容器配置監(jiān)控項(xiàng)），而且支持性能指標(biāo)告警。

Prometheus 是一套開源的系統(tǒng)監(jiān)控報(bào)警框架。它提供了多維度數(shù)據(jù)模型，每個(gè)數(shù)據(jù)指標(biāo)都可以關(guān)聯(lián)很多 label，這個(gè)和Kubernetes 的 label 思想一致，松耦合、高度自由定制數(shù)據(jù)維度。舉例來(lái)說(shuō)，每個(gè)容器的CPU指標(biāo)都可以關(guān)聯(lián)容器、Pod、容器所在主機(jī)、namespace等多個(gè)維度，那么在查詢的時(shí)候可以根據(jù)這些 label自由關(guān)聯(lián)，并且支持promsql，允許用戶以類 sql 的方式查詢指標(biāo)。Prometheus 不僅提供了高效的本地時(shí)序數(shù)據(jù)存儲(chǔ)，還可以支撐各種遠(yuǎn)端時(shí)序數(shù)據(jù)庫(kù)，如OpenTSDB、InfluxDB等，極大地?cái)U(kuò)展了Prometheus的數(shù)據(jù)存儲(chǔ)能力。

Prometheus采用拉?。≒ULL）的方式采集數(shù)據(jù)，這與采用上報(bào)（PUSH）的采集方式不同，拉取方式有以下幾個(gè)特點(diǎn)：第一是拉取方式對(duì)于客戶端沒(méi)有感知，客戶端只需要不斷采集數(shù)據(jù)，既不用關(guān)心數(shù)據(jù)后續(xù)的處理，也不需要維護(hù)數(shù)據(jù)狀態(tài)（哪些數(shù)據(jù)已經(jīng)上報(bào)，哪些數(shù)據(jù)上報(bào)失敗需要重試，還有哪些還未上報(bào)），可以做到更加簡(jiǎn)單。第二是增強(qiáng)了數(shù)據(jù)匯聚服務(wù)的可控性，數(shù)據(jù)的匯聚節(jié)點(diǎn)可以根據(jù)當(dāng)前系統(tǒng)情況，調(diào)整匯聚的周期和數(shù)據(jù)量，避免大量客戶端一起上報(bào)數(shù)據(jù)，壓垮匯聚節(jié)點(diǎn)。

Filebeat

Filebeat 是一款由 Go 語(yǔ)言編寫的具有高并發(fā)能力的日志采集插件。Filebeat 的工作原理如圖11-5所示：其中，Harvester負(fù)責(zé)逐行讀取文件，每個(gè)文件都對(duì)應(yīng)一個(gè)Harvester，然后Harvester 將采集的數(shù)據(jù)發(fā)送到 Spooler，經(jīng)過(guò) Spooler 整合后發(fā)送到不同的后端，如Elasticsearch或者Kafka等。