[[326892]]

什么是 Kubernetes?

我們來看一下什么是 Kubernetes。這部分內(nèi)容我會(huì)從四個(gè)角度來跟大家分享一下我的看法。

1. 未來什么樣

 

這是一張未來大部分公司后端 IT 基礎(chǔ)設(shè)施的架構(gòu)圖。簡單來說，以后所有公司的 IT 基礎(chǔ)設(shè)施都會(huì)部署在云上。用戶會(huì)基于 Kubernetes 把底層云資源分割成具體的集群單元，給不同的業(yè)務(wù)使用。而隨著業(yè)務(wù)微服務(wù)化的深入，服務(wù)網(wǎng)格這樣的服務(wù)治理邏輯會(huì)變得跟下邊兩層一樣，成為基礎(chǔ)設(shè)施的范疇。

目前，阿里基本上所有的業(yè)務(wù)都跑在云上。而其中大約有一半的業(yè)務(wù)已經(jīng)遷移到了自己定制 Kubernetes 集群上。另外據(jù)我了解，阿里計(jì)劃今年完成 100% 的基于 Kubernetes 集群的業(yè)務(wù)部署。

而服務(wù)網(wǎng)格這塊，在阿里的一些部門，像螞蟻金服，其實(shí)已經(jīng)有線上業(yè)務(wù)在用了。大家可以通過螞蟻一些同學(xué)的分享來了解他們的實(shí)踐過程。

雖然這張圖里的觀點(diǎn)可能有點(diǎn)絕對(duì)，但是目前這個(gè)趨勢(shì)是非常明顯的。所以未來幾年， Kubernetes 肯定會(huì)變成像 Linux 一樣的，作為集群的操作系統(tǒng)無處不在。

2. Kubernetes 與操作系統(tǒng)

 

這是一張傳統(tǒng)的操作系統(tǒng)和 Kubernetes 的比較圖。大家都知道，作為一個(gè)傳統(tǒng)的操作系統(tǒng)，像 Linux 或者 Windows，它們扮演的角色，就是底層硬件的 一個(gè)抽象層。它們向下管理計(jì)算機(jī)的硬件，像內(nèi)存或 CPU，然后把底層硬件抽象成一些易用的接口，用這些接口，向上對(duì)應(yīng)用層提供支持。

而 Kubernetes 呢，我們也可以把它理解為一個(gè)操作系統(tǒng)。這個(gè)操作系統(tǒng)說白了也是一個(gè)抽象層，它向下管理的硬件，不是內(nèi)存或者 CPU 這種硬件，而是多臺(tái)計(jì)算機(jī)組成的集群，這些計(jì)算機(jī)本身就是普通的單機(jī)系統(tǒng)，有自己的操作系統(tǒng)和硬件。Kubernetes 把這些計(jì)算機(jī)當(dāng)成一個(gè)資源池來 統(tǒng)一管理，向上對(duì)應(yīng)用提供支撐。

這里的應(yīng)用比較特別，就是這些應(yīng)用都是容器化的應(yīng)用。如果對(duì)容器不太了解的同學(xué)，可以簡單把這些應(yīng)用，理解為一個(gè)應(yīng)用安裝文件。安裝文件打包了所有的依賴庫，比如 libc 這些。這些應(yīng)用不會(huì)依賴底層操作系統(tǒng)的庫文件來運(yùn)行。

3. Kubernetes 與 Google 運(yùn)維解密

 

上圖中，左邊是一個(gè) Kubernetes 集群，右邊是一本非常有名的書，就是 Google 運(yùn)維解密這本書。相信很多人都看過這本書，而且有很多公司目前也在實(shí)踐這本書里的方法。包括故障管理，運(yùn)維排班等。

Kubernetes 和這本書的關(guān)系，我們可以把他們比作劍法和氣功的關(guān)系。不知道這里有多少人看過笑傲江湖。笑傲江湖里的華山派分兩個(gè)派別，氣宗和劍宗。氣宗注重氣功修煉，而劍宗更強(qiáng)調(diào)劍法的精妙。實(shí)際上氣宗和劍宗的分家，是因?yàn)槿A山派兩個(gè)弟子偷學(xué)一本葵花寶典，兩個(gè)人各記了一部分，最終因?yàn)橛^點(diǎn)分歧分成了兩派。

Kubernetes 實(shí)際上源自 Google 的集群自動(dòng)化管理和調(diào)度系統(tǒng) Borg，也就是這本書里講的運(yùn)維方法所針對(duì)的對(duì)象。Borg 系統(tǒng)和書里講的各種運(yùn)維方法可以看做是一件事情的兩個(gè)方面。如果一個(gè)公司只去學(xué)習(xí)他們的運(yùn)維方法，比如開了 SRE 的職位，而不懂這套方法所管理的系統(tǒng)的話，那其實(shí)就是學(xué)習(xí)葵花寶典，但是只學(xué)了一部分。

Borg 因?yàn)槭?Google 內(nèi)部的系統(tǒng)，所以我們一般人是看不到的，而 Kubernetes 基本上繼承了 Borg 在集群自動(dòng)化管理方面非常核心的一些理念。所以如果大家看了這本書，覺得很厲害，或者在實(shí)踐這本書里的方法，那大家一定要深入理解下 Kubernetes。

4. 技術(shù)演進(jìn)史

 

早期的時(shí)候，我們做一個(gè)網(wǎng)站后端，可能只需要把所有的模塊放在一個(gè)可執(zhí)行文件里，就像上圖一樣，我們有 UI、數(shù)據(jù)和業(yè)務(wù)三個(gè)模塊，這三個(gè)模塊被編譯成一個(gè)可執(zhí)行文件，跑在一臺(tái)服務(wù)器上。

但是隨著業(yè)務(wù)量的大幅增長，我們沒有辦法，通過升級(jí)服務(wù)器配置的方式來擴(kuò)容。這時(shí)候我們就必須去做微服務(wù)化了。

微服務(wù)化會(huì)把單體應(yīng)用拆分成低耦合的小應(yīng)用。這些應(yīng)用各自負(fù)責(zé)一塊業(yè)務(wù)，然后每個(gè)應(yīng)用的實(shí)例獨(dú)占一臺(tái)服務(wù)器，它們之間通過網(wǎng)絡(luò)互相調(diào)用。

這里最關(guān)鍵的是，我們可以通過增加實(shí)例個(gè)數(shù)，來對(duì)小應(yīng)用做橫向擴(kuò)容。這就解決了單臺(tái)服務(wù)器無法擴(kuò)容的問題。

微服務(wù)之后會(huì)出現(xiàn)一個(gè)問題，就是一個(gè)實(shí)例占用一臺(tái)服務(wù)器的問題。這種部署方式，資源的浪費(fèi)其實(shí)是比較嚴(yán)重的。這時(shí)我們自然會(huì)想到，把這些實(shí)例混部到底層服務(wù)器上。

但是混部會(huì)引入兩個(gè)新問題，一個(gè)是依賴庫兼容性問題。這些應(yīng)用依賴的庫文件版本可能完全不一樣，安裝到一個(gè)操作系統(tǒng)里，必然會(huì)出問題。另一個(gè)問題就是應(yīng)用調(diào)度和集群資源管理的問題。

比如一個(gè)新的應(yīng)用被創(chuàng)建出來，我們需要考慮這個(gè)應(yīng)用被調(diào)度到哪臺(tái)服務(wù)器，調(diào)度上去之后資源夠不夠用這些問題。

這里的依賴庫兼容性問題，是靠容器化來解決的，也就是每個(gè)應(yīng)用自帶依賴庫，只跟其他應(yīng)用共享內(nèi)核。而調(diào)度和資源管理就是 Kubernetes 所解決的問題。

順便提一句，我們可能會(huì)因?yàn)椋豪锘觳康膽?yīng)用太多，這些應(yīng)用關(guān)系錯(cuò)綜復(fù)雜，而沒有辦法去排查一些像請(qǐng)求響應(yīng)慢這樣的問題。所以類似服務(wù)網(wǎng)格這類服務(wù)治理的技術(shù)，肯定會(huì)成為下一個(gè)趨勢(shì)。

 

怎么學(xué)習(xí) Kubernetes?

1. Kubernetes 學(xué)習(xí)難點(diǎn)

 

總體來說，Kubernetes 之所以門檻比較高，比較難學(xué)習(xí)，一個(gè)是因?yàn)樗募夹g(shù)棧非常深，包括了內(nèi)核，虛擬化，容器，軟件定義網(wǎng)絡(luò) SDN，存儲(chǔ)，安全，甚至可信計(jì)算等，絕對(duì)可以稱得上全棧技術(shù)。

同時(shí) Kubernetes 在云環(huán)境的實(shí)現(xiàn)，肯定會(huì)牽扯到非常多的云產(chǎn)品，比如在阿里云上，我們的 Kubernetes 集群用到了 ECS 云服務(wù)器，VPC 虛擬網(wǎng)絡(luò)，負(fù)載均衡，安全組，日志服務(wù)，云監(jiān)控，中間件產(chǎn)品像 ahas 和 arms，服務(wù)網(wǎng)格，彈性伸縮等等大量云產(chǎn)品。

最后，因?yàn)?Kubernetes 是一個(gè)通用的計(jì)算平臺(tái)，所以它會(huì)被用到各種業(yè)務(wù)場景中去，比如數(shù)據(jù)庫。據(jù)我所知，像我們的 PolarDB Box 一體機(jī)就是計(jì)劃基于 Kubernetes 搭建。另外還有邊緣計(jì)算，機(jī)器學(xué)習(xí)，流計(jì)算等等。

2. 了解、動(dòng)手、思考

 

基于我個(gè)人的經(jīng)驗(yàn)，學(xué)習(xí) Kubernetes，我們需要從了解、動(dòng)手、以及思考三個(gè)方面去把握。

了解其實(shí)很重要，特別是了解技術(shù)的演進(jìn)史，以及技術(shù)的全景圖。

我們需要知道各種技術(shù)的演進(jìn)歷史，比如容器技術(shù)是怎么從 chroot 這個(gè)命令發(fā)展而來的，以及技術(shù)演進(jìn)背后要解決的問題是什么，只有知道技術(shù)的演進(jìn)史和發(fā)展的動(dòng)力，我們才能對(duì)未來技術(shù)方向有自己的判斷。

同時(shí)我們需要了解技術(shù)全景，對(duì) Kubernetes 來說，我們需要了解整個(gè)云原生技術(shù)棧，包括容器，CICD，微服務(wù)、服務(wù)網(wǎng)格這些，知道 Kubernetes 在整個(gè)技術(shù)棧里所處的位置。

除了這些基本的背景知識(shí)以外，學(xué)習(xí) Kubernetes 技術(shù)，動(dòng)手實(shí)踐是非常關(guān)鍵的。

從我和大量工程師一起解決問題的經(jīng)驗(yàn)來說，很多人其實(shí)是不會(huì)去深入研究技術(shù)細(xì)節(jié)的。我們經(jīng)常開玩笑說工程師有兩種，一種是 search engineer，就是搜索工程師，一種是 research engineer，就是研究工程師。很多工程師遇到問題，google 一把，如果搜不到答案，就直接開工單了。這樣是很難深入理解一個(gè)技術(shù)的。

最后就是怎么去思考，怎么去總結(jié)了。我個(gè)人的經(jīng)驗(yàn)是，我們需要在理解技術(shù)細(xì)節(jié)之后，不斷的問自己，細(xì)節(jié)的背后，有沒有什么更本質(zhì)的東西。也就是我們要把復(fù)雜的細(xì)節(jié)看簡單，然后找出普通的模式出來。

下邊我用兩個(gè)例子來具體解釋一下上邊的方法。

3. 用冰箱來理解集群控制器

 

第一個(gè)例子是關(guān)于集群控制器的。我們?cè)趯W(xué)習(xí) Kubernetes 的時(shí)候會(huì)聽到幾個(gè)概念，像聲明式 API，Operator，面向終態(tài)設(shè)計(jì)等。這些概念本質(zhì)上 都是在講一件事情，就是控制器模式。

我們?cè)趺磥砝斫?Kubernetes 的控制器呢?上面這張圖是一個(gè)經(jīng)典的 Kubernetes 架構(gòu)圖，這張圖里有集群管控節(jié)點(diǎn)和工作節(jié)點(diǎn)，管控節(jié)點(diǎn)上有中心數(shù)據(jù)庫，API Server，調(diào)度器及一些控制器。

中心數(shù)據(jù)庫是集群的核心存儲(chǔ)系統(tǒng)，API Server 是集群的管控入口，調(diào)度器負(fù)責(zé)把應(yīng)用調(diào)度到資源充沛的節(jié)點(diǎn)上。而控制器是我們這里要說的重點(diǎn)?？刂破鞯淖饔?，我們用一句話概括，就是“讓夢(mèng)想照進(jìn)現(xiàn)實(shí)”。從這個(gè)意義上來講，我自己也經(jīng)常扮演控制器的角色，我女兒如果說，爸爸我要吃冰激凌，那我女兒就是集群的用戶，我就是負(fù)責(zé)把她這個(gè)愿望實(shí)現(xiàn)的人，就是控制器。

除了管控節(jié)點(diǎn)以外，Kubernetes 集群有很多工作節(jié)點(diǎn)，這些節(jié)點(diǎn)都部署了 Kubelet 和 Proxy 這兩個(gè)代理。Kubelet 負(fù)責(zé)管理工作節(jié)點(diǎn)，包括應(yīng)用在節(jié)點(diǎn)上啟動(dòng)和停止之類的工作。Proxy 負(fù)責(zé)把服務(wù)的定義落實(shí)成具體的 iptables 或者 ipvs 規(guī)則。這里服務(wù)的概念，其實(shí)簡單來說，就是利用 iptables 或者 ipvs 來實(shí)現(xiàn)負(fù)載均衡。

如果我們從控制器的角度來看第一張圖的話，我們就會(huì)得到第二張圖。也就是說，集群實(shí)際上就包括一個(gè)數(shù)據(jù)庫，一個(gè)集群入口，以及很多個(gè)控制器。這些組件，包括調(diào)度器，Kubelet 以及 Proxy，實(shí)際上都是不斷的去觀察集群里各種資源的定義，然后把這些定義落實(shí)成具體的配置，比如容器啟動(dòng)或 iptables 配置。

從控制器的角度觀察 Kubernetes 的時(shí)候，我們其實(shí)得到了 Kubernetes 最根本的一個(gè)原理了。就是控制器模式。

其實(shí)控制器模式在我們生活中無處不在的，這里我拿冰箱做個(gè)例子。我們?cè)诳刂票涞臅r(shí)候，并不會(huì)直接去控制冰箱里的制冷系統(tǒng)或者照明系統(tǒng)。我們打開冰箱的時(shí)候，里邊的燈會(huì)打開，我們?cè)谠O(shè)置了想要的溫度之后，就算我們不在家，制冷系統(tǒng)也會(huì)一直保持這個(gè)溫度。這背后就是因?yàn)橛锌刂破髂Ｊ皆谄鹱饔谩?/p>

4. 為什么刪除不掉命名空間

 

第二個(gè)例子，我們來看一個(gè)真實(shí)問題的排查過程。這個(gè)問題是一個(gè)命名空間不能被刪除的問題。問題稍微有點(diǎn)復(fù)雜，我們一步一步來看。

命名空間是 Kubernetes 集群的 一個(gè)收納盒機(jī)制，就像這里的第一張圖片一樣。這個(gè)盒子就是命名空間，它里邊收納了橡皮和鉛筆。

命名空間可以被創(chuàng)建或者刪除。我們經(jīng)常會(huì)遇到不能刪除命名空間的問題。遇到這個(gè)問題，我們?nèi)绻耆恢涝趺磁挪?。第一步我們可能?huì)想到，研究一下 API Server 是怎么處理這個(gè)刪除操作的，因?yàn)?API Server 就是集群的 管理入口。

API Server 本身是一個(gè)應(yīng)用，我們可以通過提升這個(gè)應(yīng)用的日志級(jí)別，來深入理解它的操作流程。在這個(gè)問題里，我們會(huì)發(fā)現(xiàn)，API Server 收到刪除命令，但是就沒有其他信息了。

這里我們需要稍微理解下命名空間的刪除過程，用戶在刪除命名空間的時(shí)候，其實(shí)命名空間并不會(huì)被直接刪除掉，而會(huì)被改成“刪除中”的狀態(tài)。這個(gè)時(shí)候命名空間控制器就會(huì)看到這個(gè)狀態(tài)。

為了理解命名空間控制器的行為，我們同樣可以把控制器的日志級(jí)別提高來查看詳細(xì)的日志。這個(gè)時(shí)候呢，我們會(huì)發(fā)現(xiàn)，控制器正在嘗試去獲取所有的 API 分組。

到這里我們需要去理解兩個(gè)事情。一個(gè)是為什么刪除命名空間，控制器會(huì)去獲取 API 分組。第二個(gè)是 API 分組到底是什么。

我們先看第二個(gè)問題，API 分組到底是什么。簡單來說，API 分組就是集群 API 的分類機(jī)制，比如網(wǎng)絡(luò)相關(guān)的 API 就在 networking 這個(gè)組里。而通過網(wǎng)絡(luò) API 分組創(chuàng)建出來的資源就屬于這個(gè)組。

那為什么命名空間控制器會(huì)去獲取 API 分組呢?是因?yàn)樵趧h除命名空間的時(shí)候，控制器需要?jiǎng)h除命名空間里的所有資源。這個(gè)操作不像我們刪除文件夾一樣，會(huì)把里邊的文件都一起刪掉。

命名空間收納了資源，實(shí)際上是這些資源用類似索引的機(jī)制，指向了這個(gè)命名空間。集群只有遍歷所有的 API 分組，找出指向這個(gè)命名空間的所有資源，才能逐個(gè)把它們刪除掉。

而遍歷 API 組這個(gè)操作呢，會(huì)使得集群的 API Server 和它的擴(kuò)展進(jìn)行通信。這是因?yàn)?API Server 的擴(kuò)展，也可以實(shí)現(xiàn)一部分 API 分組。所以想知道被刪除的命名空間里是不是有包括這個(gè)擴(kuò)展定義的資源，API Server 就必須和擴(kuò)展通信。

到這一步之后，問題實(shí)際上變成 API Server 和他的擴(kuò)展之間通信的問題。也就是刪除資源的問題就變成了網(wǎng)絡(luò)問題。

阿里云的 Kubernetes 集群，是在 VPC 網(wǎng)絡(luò)，也就是虛擬局域網(wǎng)上創(chuàng)建的。默認(rèn)情況下， VPC 的只認(rèn)識(shí) VPC 網(wǎng)段的地址，而集群里邊的容器，一般會(huì)使用和 VPC 不同的網(wǎng)段。比如 VPC 使用 172 網(wǎng)段，那容器可能就使用 192 網(wǎng)段。

我們通過在 VPC 的路由表里，增加容器網(wǎng)段的路由項(xiàng)，可以讓容器使用 VPC 網(wǎng)絡(luò)進(jìn)行通信。

在右下角這張圖，我們有兩個(gè)集群節(jié)點(diǎn)，他們的地址是 172 網(wǎng)段，那我們給路由表里增加 192 網(wǎng)段的路由項(xiàng)，就可以讓 VPC 把發(fā)給容器的數(shù)據(jù)轉(zhuǎn)發(fā)到正確的節(jié)點(diǎn)上，再由節(jié)點(diǎn)發(fā)給具體的容器。

而這里的路由項(xiàng)，是在節(jié)點(diǎn)加入集群的時(shí)候，由路由控制器來添加的。路由控制器在發(fā)現(xiàn)有新節(jié)點(diǎn)加入集群之后，會(huì)立刻做出反應(yīng)，給路由表里增加一條路由項(xiàng)。

添加路由項(xiàng)這個(gè)操作，其實(shí)是對(duì) VPC 的一次操作。這個(gè)操作是需要使用一定的授權(quán)的，這是因?yàn)檫@個(gè)操作跟線下一臺(tái)機(jī)器訪問云上資源是差不多的，肯定需要授權(quán)。

這里路由控制器使用的授權(quán)，是以 RAM 角色的方式綁定到路由控制器所在的集群節(jié)點(diǎn)上的。而這個(gè) RAM 角色，正常會(huì)有一系列的授權(quán)規(guī)則。

最后，我們通過檢查，發(fā)現(xiàn)用戶修改了授權(quán)規(guī)則，所以導(dǎo)致了這個(gè)問題。