![1.png](https://ucc.alicdn.com/pic/developer-ecology/7465068afb7f446a97c94cdbe5355110.png)

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

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

# 什麼是 Kubernetes？

我們來看一下什麼是 Kubernetes。這部分內容我會從四個角度來跟大家分享一下我的看法。

## 1. 未來什麼樣

![2.png](https://ucc.alicdn.com/pic/developer-ecology/fbcb10aacd86499bb3ca210d65159e9a.png)

這是一張未來大部分公司後端 IT 基礎設施的架構圖。簡單來說，以後所有公司的 IT 基礎設施都會部署在雲上。使用者會基於 Kubernetes 把底層雲資源分割成具體的叢集單元，給不同的業務使用。而隨著業務微服務化的深入，服務網格這樣的服務治理邏輯會變得跟下邊兩層一樣，成為基礎設施的範疇。

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

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

雖然這張圖裡的觀點可能有點絕對，但是目前這個趨勢是非常明顯的。所以未來幾年，  Kubernetes 肯定會變成像 Linux 一樣的，作為叢集的作業系統無處不在。

## 2. Kubernetes 與作業系統

![3.png](https://ucc.alicdn.com/pic/developer-ecology/3123201fa88f4cdda39b330442361b1e.png)

這是一張傳統的作業系統和 Kubernetes 的比較圖。大家都知道，作為一個傳統的作業系統，像 Linux 或者 Windows，它們扮演的角色，就是底層硬體的 一個抽象層。它們向下管理計算機的硬體，像記憶體或 CPU，然後把底層硬體抽象成一些易用的介面，用這些介面，向上對應用層提供支援。

而 Kubernetes 呢，我們也可以把它理解為一個作業系統。這個作業系統說白了也是一個抽象層，它向下管理的硬體，不是記憶體或者 CPU 這種硬體，而是多臺計算機組成的叢集，這些計算機本身就是普通的單機系統，有自己的作業系統和硬體。Kubernetes  把這些計算機當成一個資源池來 統一管理，向上對應用提供支撐。

這裡的應用比較特別，就是這些應用都是容器化的應用。如果對容器不太瞭解的同學，可以簡單把這些應用，理解為一個應用安裝檔案。安裝檔案打包了所有的依賴庫，比如  libc 這些。這些應用不會依賴底層作業系統的庫檔案來執行。

## 3. Kubernetes 與 Google 運維解密

![4.png](https://ucc.alicdn.com/pic/developer-ecology/7ccaa79b323847dd823acd6c200d741a.png)

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

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

Kubernetes 實際上源自 Google 的叢集自動化管理和排程系統 Borg，也就是這本書裡講的運維方法所針對的物件。Borg 系統和書裡講的各種運維方法可以看做是一件事情的兩個方面。如果一個公司只去學習他們的運維方法，比如開了 SRE 的職位，而不懂這套方法所管理的系統的話，那其實就是學習葵花寶典，但是隻學了一部分。

Borg 因為是 Google 內部的系統，所以我們一般人是看不到的，而 Kubernetes 基本上繼承了 Borg 在叢集自動化管理方面非常核心的一些理念。所以如果大家看了這本書，覺得很厲害，或者在實踐這本書裡的方法，那大家一定要深入理解下  Kubernetes。

## 4. 技術演進史

![5.png](https://ucc.alicdn.com/pic/developer-ecology/09ec1bfce0354e8fa3715da0ff644dba.png)

早期的時候，我們做一個網站後端，可能只需要把所有的模組放在一個可執行檔案裡，就像上圖一樣，我們有 UI、資料和業務三個模組，這三個模組被編譯成一個可執行檔案，跑在一臺伺服器上。

但是隨著業務量的大幅增長，我們沒有辦法，透過升級伺服器配置的方式來擴容。這時候我們就必須去做微服務化了。

微服務化會把單體應用拆分成低耦合的小應用。這些應用各自負責一塊業務，然後每個應用的例項獨佔一臺伺服器，它們之間透過網路互相呼叫。

這裡最關鍵的是，我們可以透過增加例項個數，來對小應用做橫向擴容。這就解決了單臺伺服器無法擴容的問題。

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

但是混部會引入兩個新問題，一個是依賴庫相容性問題。這些應用依賴的庫檔案版本可能完全不一樣，安裝到一個作業系統裡，必然會出問題。另一個問題就是應用排程和叢集資源管理的問題。

比如一個新的應用被建立出來，我們需要考慮這個應用被排程到哪臺伺服器，排程上去之後資源夠不夠用這些問題。

這裡的依賴庫相容性問題，是靠容器化來解決的，也就是每個應用自帶依賴庫，只跟其他應用共享核心。而排程和資源管理就是 Kubernetes 所解決的問題。

順便提一句，我們可能會因為，叢集裡混部的應用太多，這些應用關係錯綜複雜，而沒有辦法去排查一些像請求響應慢這樣的問題。所以類似服務網格這類服務治理的技術，肯定會成為下一個趨勢。

# 怎麼學習 Kubernetes？

## 1. Kubernetes 學習難點

![6.png](https://ucc.alicdn.com/pic/developer-ecology/e5dc7558fc8b4f599c49f953347f35d6.png)

總體來說，Kubernetes 之所以門檻比較高，比較難學習，一個是因為它的技術棧非常深，包括了核心，虛擬化，容器，軟體定義網路 SDN，儲存，安全，甚至可信計算等，絕對可以稱得上全棧技術。

同時 Kubernetes 在雲環境的實現，肯定會牽扯到非常多的雲產品，比如在阿里雲上，我們的 Kubernetes 叢集用到了 ECS 雲伺服器，VPC 虛擬網路，負載均衡，安全組，日誌服務，雲監控，中介軟體產品像 ahas 和 arms，服務網格，彈性伸縮等等大量雲產品。

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

## 2. 瞭解、動手、思考

![7.png](https://ucc.alicdn.com/pic/developer-ecology/b750c3bf0955468699988149956d6a26.png)

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

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

我們需要知道各種技術的演進歷史，比如容器技術是怎麼從 chroot 這個命令發展而來的，以及技術演進背後要解決的問題是什麼，只有知道技術的演進史和發展的動力，我們才能對未來技術方向有自己的判斷。

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

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

從我和大量工程師一起解決問題的經驗來說，很多人其實是不會去深入研究技術細節的。我們經常開玩笑說工程師有兩種，一種是 search engineer，就是搜尋工程師，一種是 research engineer，就是研究工程師。很多工程師遇到問題，google 一把，如果搜不到答案，就直接開工單了。這樣是很難深入理解一個技術的。

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

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

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

![8.png](https://ucc.alicdn.com/pic/developer-ecology/d0469b88cbb049518e1f47db017460dc.png)

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

我們怎麼來理解 Kubernetes 的控制器呢？上面這張圖是一個經典的 Kubernetes 架構圖，這張圖裡有叢集管控節點和工作節點，管控節點上有中心資料庫，API Server，排程器及一些控制器。

中心資料庫是叢集的核心儲存系統，API Server 是叢集的管控入口，排程器負責把應用排程到資源充沛的節點上。而控制器是我們這裡要說的重點。控制器的作用，我們用一句話概括，就是“讓夢想照進現實”。從這個意義上來講，我自己也經常扮演控制器的角色，我女兒如果說，爸爸我要吃冰淇淋，那我女兒就是叢集的使用者，我就是負責把她這個願望實現的人，就是控制器。

除了管控節點以外，Kubernetes 叢集有很多工作節點，這些節點都部署了 Kubelet 和 Proxy 這兩個代理。Kubelet 負責管理工作節點，包括應用在節點上啟動和停止之類的工作。Proxy 負責把服務的定義落實成具體的 iptables 或者 ipvs 規則。這裡服務的概念，其實簡單來說，就是利用 iptables 或者 ipvs 來實現負載均衡。

如果我們從控制器的角度來看第一張圖的話，我們就會得到第二張圖。也就是說，叢集實際上就包括一個資料庫，一個叢集入口，以及很多個控制器。這些元件，包括排程器，Kubelet 以及 Proxy，實際上都是不斷的去觀察叢集裡各種資源的定義，然後把這些定義落實成具體的配置，比如容器啟動或 iptables 配置。

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

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

## 4. 為什麼刪除不掉名稱空間

![9.png](https://ucc.alicdn.com/pic/developer-ecology/256f32c9068b45ff9b6bf832c0ccdb79.png)

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

名稱空間是 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 角色，正常會有一系列的授權規則。

最後，我們透過檢查，發現使用者修改了授權規則，所以導致了這個問題。

> “[阿里巴巴雲原生](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247490334&idx=1&sn=6d8a3badc5d4cf5334ac160152e4c912&chksm=fae510d1cd9299c7383d9dd8dfb3d655c7676f221f9953da644a367d71c68b106bd3e212a016&token=1321663756&lang=zh_CN#rd)關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的公眾號。”

如何輕鬆學習 Kubernetes？

相關文章