如何輕鬆學習 Kubernetes？

做者 | 聲東 阿里巴巴技術專家

<關注阿里巴巴雲原生公衆號，回覆 排查 便可下載電子書>

導讀：《深刻淺出 Kubernetes》一書共聚集 12 篇技術文章，幫助你一次搞懂 6 個核心原理，吃透基礎理論，一次學會 6 個典型問題的華麗操做！

什麼是 Kubernetes？

---

咱們來看一下什麼是 Kubernetes。這部份內容我會從四個角度來跟你們分享一下個人見解。

1. 將來什麼樣

---

這是一張將來大部分公司後端 IT 基礎設施的架構圖。簡單來講，之後全部公司的 IT 基礎設施都會部署在雲上。用戶會基於 Kubernetes 把底層雲資源分割成具體的集羣單元，給不一樣的業務使用。而隨着業務微服務化的深刻，服務網格這樣的服務治理邏輯會變得跟下邊兩層同樣，成爲基礎設施的範疇。

目前，阿里基本上全部的業務都跑在雲上。而其中大約有一半的業務已經遷移到了本身定製 Kubernetes 集羣上。另外據我瞭解，阿里計劃今年完成 100% 的基於 Kubernetes 集羣的業務部署。

而服務網格這塊，在阿里的一些部門，像螞蟻金服，其實已經有線上業務在用了。你們能夠經過螞蟻一些同窗的分享來了解他們的實踐過程。

雖然這張圖裏的觀點可能有點絕對，可是目前這個趨勢是很是明顯的。因此將來幾年， Kubernetes 確定會變成像 Linux 同樣的，做爲集羣的操做系統無處不在。

2. Kubernetes 與操做系統

---

這是一張傳統的操做系統和 Kubernetes 的比較圖。你們都知道，做爲一個傳統的操做系統，像 Linux 或者 Windows，它們扮演的角色，就是底層硬件的 一個抽象層。它們向下管理計算機的硬件，像內存或 CPU，而後把底層硬件抽象成一些易用的接口，用這些接口，向上對應用層提供支持。

而 Kubernetes 呢，咱們也能夠把它理解爲一個操做系統。這個操做系統說白了也是一個抽象層，它向下管理的硬件，不是內存或者 CPU 這種硬件，而是多臺計算機組成的集羣，這些計算機自己就是普通的單機系統，有本身的操做系統和硬件。Kubernetes 把這些計算機當成一個資源池來 統一管理，向上對應用提供支撐。

這裏的應用比較特別，就是這些應用都是容器化的應用。若是對容器不太瞭解的同窗，能夠簡單把這些應用，理解爲一個應用安裝文件。安裝文件打包了全部的依賴庫，好比 libc 這些。這些應用不會依賴底層操做系統的庫文件來運行。

3. Kubernetes 與 Google 運維解密

---

上圖中，左邊是一個 Kubernetes 集羣，右邊是一本很是有名的書，就是 Google 運維解密這本書。相信不少人都看過這本書，並且有不少公司目前也在實踐這本書裏的方法。包括故障管理，運維排班等。

Kubernetes 和這本書的關係，咱們能夠把他們比做劍法和睦功的關係。不知道這裏有多少人看過笑傲江湖。笑傲江湖裏的華山派分兩個派別，氣宗和劍宗。氣宗注重氣功修煉，而劍宗更強調劍法的精妙。實際上氣宗和劍宗的分家，是由於華山派兩個弟子偷學一本葵花寶典，兩我的各記了一部分，最終由於觀點分歧分紅了兩派。

Kubernetes 實際上源自 Google 的集羣自動化管理和調度系統 Borg，也就是這本書裏講的運維方法所針對的對象。Borg 系統和書裏講的各類運維方法能夠看作是一件事情的兩個方面。若是一個公司只去學習他們的運維方法，好比開了 SRE 的職位，而不懂這套方法所管理的系統的話，那其實就是學習葵花寶典，可是隻學了一部分。

Borg 由於是 Google 內部的系統，因此咱們通常人是看不到的，而 Kubernetes 基本上繼承了 Borg 在集羣自動化管理方面很是核心的一些理念。因此若是你們看了這本書，以爲很厲害，或者在實踐這本書裏的方法，那你們必定要深刻理解下 Kubernetes。

4. 技術演進史

---

早期的時候，咱們作一個網站後端，可能只須要把全部的模塊放在一個可執行文件裏，就像上圖同樣，咱們有 UI、數據和業務三個模塊，這三個模塊被編譯成一個可執行文件，跑在一臺服務器上。

可是隨着業務量的大幅增加，咱們沒有辦法，經過升級服務器配置的方式來擴容。這時候咱們就必須去作微服務化了。

微服務化會把單體應用拆分紅低耦合的小應用。這些應用各自負責一塊業務，而後每一個應用的實例獨佔一臺服務器，它們之間經過網絡互相調用。

這裏最關鍵的是，咱們能夠經過增長實例個數，來對小應用作橫向擴容。這就解決了單臺服務器沒法擴容的問題。

微服務以後會出現一個問題，就是一個實例佔用一臺服務器的問題。這種部署方式，資源的浪費實際上是比較嚴重的。這時咱們天然會想到，把這些實例混部到底層服務器上。

可是混部會引入兩個新問題，一個是依賴庫兼容性問題。這些應用依賴的庫文件版本可能徹底不同，安裝到一個操做系統裏，必然會出問題。另外一個問題就是應用調度和集羣資源管理的問題。

好比一個新的應用被建立出來，咱們須要考慮這個應用被調度到哪臺服務器，調度上去以後資源夠不夠用這些問題。

這裏的依賴庫兼容性問題，是靠容器化來解決的，也就是每一個應用自帶依賴庫，只跟其餘應用共享內核。而調度和資源管理就是 Kubernetes 所解決的問題。

順便提一句，咱們可能會由於，集羣裏混部的應用太多，這些應用關係錯綜複雜，而沒有辦法去排查一些像請求響應慢這樣的問題。因此相似服務網格這類服務治理的技術，確定會成爲下一個趨勢。

怎麼學習 Kubernetes？

---

1. Kubernetes 學習難點

---

整體來講，Kubernetes 之因此門檻比較高，比較難學習，一個是由於它的技術棧很是深，包括了內核，虛擬化，容器，軟件定義網絡 SDN，存儲，安全，甚至可信計算等，絕對能夠稱得上全棧技術。

同時 Kubernetes 在雲環境的實現，確定會牽扯到很是多的雲產品，好比在阿里雲上，咱們的 Kubernetes 集羣用到了 ECS 雲服務器，VPC 虛擬網絡，負載均衡，安全組，日誌服務，雲監控，中間件產品像 ahas 和 arms，服務網格，彈性伸縮等等大量雲產品。

最後，由於 Kubernetes 是一個通用的計算平臺，因此它會被用到各類業務場景中去，好比數據庫。據我所知，像咱們的 PolarDB Box 一體機就是計劃基於 Kubernetes 搭建。另外還有邊緣計算，機器學習，流計算等等。

2. 瞭解、動手、思考

---

基於我我的的經驗，學習 Kubernetes，咱們須要從瞭解、動手、以及思考三個方面去把握。

瞭解其實很重要，特別是瞭解技術的演進史，以及技術的全景圖。

咱們須要知道各類技術的演進歷史，好比容器技術是怎麼從 chroot 這個命令發展而來的，以及技術演進背後要解決的問題是什麼，只有知道技術的演進史和發展的動力，咱們才能對將來技術方向有本身的判斷。

同時咱們須要瞭解技術全景，對 Kubernetes 來講，咱們須要瞭解整個雲原生技術棧，包括容器，CICD，微服務、服務網格這些，知道 Kubernetes 在整個技術棧裏所處的位置。

除了這些基本的背景知識之外，學習 Kubernetes 技術，動手實踐是很是關鍵的。

從我和大量工程師一塊兒解決問題的經驗來講，不少人實際上是不會去深刻研究技術細節的。咱們常常開玩笑說工程師有兩種，一種是 search engineer，就是搜索工程師，一種是 research engineer，就是研究工程師。不少工程師遇到問題，google 一把，若是搜不到答案，就直接開工單了。這樣是很難深刻理解一個技術的。

最後就是怎麼去思考，怎麼去總結了。我我的的經驗是，咱們須要在理解技術細節以後，不斷的問本身，細節的背後，有沒有什麼更本質的東西。也就是咱們要把複雜的細節看簡單，而後找出普通的模式出來。

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

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

---

第一個例子是關於集羣控制器的。咱們在學習 Kubernetes 的時候會聽到幾個概念，像聲明式 API，Operator，面向終態設計等。這些概念本質上 都是在講一件事情，就是控制器模式。

咱們怎麼來理解 Kubernetes 的控制器呢？上面這張圖是一個經典的 Kubernetes 架構圖，這張圖裏有集羣管控節點和工做節點，管控節點上有中心數據庫，API Server，調度器及一些控制器。

中心數據庫是集羣的核心存儲系統，API Server 是集羣的管控入口，調度器負責把應用調度到資源充沛的節點上。而控制器是咱們這裏要說的重點。控制器的做用，咱們用一句話歸納，就是「讓夢想照進現實」。從這個意義上來說，我本身也常常扮演控制器的角色，我女兒若是說，爸爸我要吃冰激凌，那我女兒就是集羣的用戶，我就是負責把她這個願望實現的人，就是控制器。

除了管控節點之外，Kubernetes 集羣有不少工做節點，這些節點都部署了 Kubelet 和 Proxy 這兩個代理。Kubelet 負責管理工做節點，包括應用在節點上啓動和中止之類的工做。Proxy 負責把服務的定義落實成具體的 iptables 或者 ipvs 規則。這裏服務的概念，其實簡單來講，就是利用 iptables 或者 ipvs 來實現負載均衡。

若是咱們從控制器的角度來看第一張圖的話，咱們就會獲得第二張圖。也就是說，集羣實際上就包括一個數據庫，一個集羣入口，以及不少個控制器。這些組件，包括調度器，Kubelet 以及 Proxy，實際上都是不斷的去觀察集羣裏各類資源的定義，而後把這些定義落實成具體的配置，好比容器啓動或 iptables 配置。

從控制器的角度觀察 Kubernetes 的時候，咱們其實獲得了 Kubernetes 最根本的一個原理了。就是控制器模式。

其實控制器模式在咱們生活中無處不在的，這裏我拿冰箱作個例子。咱們在控制冰箱的時候，並不會直接去控制冰箱裏的製冷系統或者照明系統。咱們打開冰箱的時候，裏邊的燈會打開，咱們在設置了想要的溫度以後，就算咱們不在家，製冷系統也會一直保持這個溫度。這背後就是由於有控制器模式在起做用。

4. 爲何刪除不掉命名空間

---

第二個例子，咱們來看一個真實問題的排查過程。這個問題是一個命名空間不能被刪除的問題。問題稍微有點複雜，咱們一步一步來看。

命名空間是 Kubernetes 集羣的 一個收納盒機制，就像這裏的第一張圖片同樣。這個盒子就是命名空間，它裏邊收納了橡皮和鉛筆。

命名空間能夠被建立或者刪除。咱們常常會遇到不能刪除命名空間的問題。遇到這個問題，咱們若是徹底不知道怎麼排查。第一步咱們可能會想到，研究一下 API Server 是怎麼處理這個刪除操做的，由於 API Server 就是集羣的 管理入口。

API Server 自己是一個應用，咱們能夠經過提高這個應用的日誌級別，來深刻理解它的操做流程。在這個問題裏，咱們會發現，API Server 收到刪除命令，可是就沒有其餘信息了。

這裏咱們須要稍微理解下命名空間的刪除過程，用戶在刪除命名空間的時候，其實命名空間並不會被直接刪除掉，而會被改爲「刪除中」的狀態。這個時候命名空間控制器就會看到這個狀態。

爲了理解命名空間控制器的行爲，咱們一樣能夠把控制器的日誌級別提升來查看詳細的日誌。這個時候呢，咱們會發現，控制器正在嘗試去獲取全部的 API 分組。

到這裏咱們須要去理解兩個事情。一個是爲何刪除命名空間，控制器會去獲取 API 分組。第二個是 API 分組究竟是什麼。

咱們先看第二個問題，API 分組究竟是什麼。簡單來講，API 分組就是集羣 API 的分類機制，好比網絡相關的 API 就在 networking 這個組裏。而經過網絡 API 分組建立出來的資源就屬於這個組。

那爲何命名空間控制器會去獲取 API 分組呢？是由於在刪除命名空間的時候，控制器須要刪除命名空間裏的全部資源。這個操做不像咱們刪除文件夾同樣，會把裏邊的文件都一塊兒刪掉。

命名空間收納了資源，其實是這些資源用相似索引的機制，指向了這個命名空間。集羣只有遍歷全部的 API 分組，找出指向這個命名空間的全部資源，才能逐個把它們刪除掉。

而遍歷 API 組這個操做呢，會使得集羣的 API Server 和它的擴展進行通訊。這是由於 API Server 的擴展，也能夠實現一部分 API 分組。因此想知道被刪除的命名空間裏是否是有包括這個擴展定義的資源，API Server 就必須和擴展通訊。

到這一步以後，問題實際上變成 API Server 和他的擴展之間通訊的問題。也就是刪除資源的問題就變成了網絡問題。

阿里雲的 Kubernetes 集羣，是在 VPC 網絡，也就是虛擬局域網上建立的。默認狀況下， VPC 的只認識 VPC 網段的地址，而集羣裏邊的容器，通常會使用和 VPC 不一樣的網段。好比 VPC 使用 172 網段，那容器可能就使用 192 網段。

咱們經過在 VPC 的路由表裏，增長容器網段的路由項，可讓容器使用 VPC 網絡進行通訊。

在右下角這張圖，咱們有兩個集羣節點，他們的地址是 172 網段，那咱們給路由表裏增長 192 網段的路由項，就可讓 VPC 把發給容器的數據轉發到正確的節點上，再由節點發給具體的容器。

而這裏的路由項，是在節點加入集羣的時候，由路由控制器來添加的。路由控制器在發現有新節點加入集羣以後，會馬上作出反應，給路由表裏增長一條路由項。

添加路由項這個操做，實際上是對 VPC 的一次操做。這個操做是須要使用必定的受權的，這是由於這個操做跟線下一臺機器訪問雲上資源是差很少的，確定須要受權。

這裏路由控制器使用的受權，是以 RAM 角色的方式綁定到路由控制器所在的集羣節點上的。而這個 RAM 角色，正常會有一系列的受權規則。

最後，咱們經過檢查，發現用戶修改了受權規則，因此致使了這個問題。

<關注阿里巴巴雲原生公衆號，回覆 排查 便可下載電子書>

課程推薦

---

爲了更多開發者可以享受到 Serverless 帶來的紅利，這一次，咱們集結了 10+ 位阿里巴巴 Serverless 領域技術專家，打造出最適合開發者入門的 Serverless 公開課，讓你即學即用，輕鬆擁抱雲計算的新範式——Serverless。

點擊便可免費觀看課程：https://developer.aliyun.com/learning/roadmap/serverless

「 阿里巴巴雲原生關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，作最懂雲原生開發者的公衆號。」