作者 | 聲東 阿裡巴巴技術專家
<關注阿裡巴巴雲原生公衆号，回複 排查 即可下載下傳電子書>
導讀：《深入淺出 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 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的公衆号。”