寫給你們看的「不負責任」 K8s 入門文檔

做者 | 鄧青琳（輕零）  阿里巴巴技術專家

導讀：本文轉載自阿里巴巴技術專家鄧青琳(輕零)在內部的分享，他從阿里雲控制檯團隊轉崗到 ECI 研發團隊（Serverless Kubernetes 背後的實現基石），從零開始瞭解 K8s，並從業務發展的視角整理了 K8s 是如何出現的，又是如何工做的。

前言

2019 年下半年，我作了一次轉崗，開始接觸到 Kubernetes，雖然對 K8s 的認識還很是的不全面，可是很是想分享一下本身的一些收穫，但願經過本文可以幫助你們對 K8s 有一個入門的瞭解。文中有不對的地方，還請各位老司機們幫助指點糾正。

其實介紹 K8s 的文章，網上一搜一大把，並且 Kubernetes 官方文檔也寫的很是友好，因此直接上來說 K8s，我以爲我是遠遠不如網上的一些文章講的好的。所以我想換一個角度，經過一個業務發展的故事角度，來說 K8s 是怎麼出現的，它又是如何運做的。

故事開始

隨着中國老百姓生活水平的不斷提升，家家戶戶都有了小汽車，小王預計 5 年後，汽車報廢業務將會迅速發展，並且國家在 2019 年也出臺了新政策《報廢機動車回收管理辦法》，取消了汽車報廢回收的「特種行業」屬性，將開放市場化的競爭。

小王以爲這是一個創業的好機會，因而找了幾個志同道合的小夥伴開始了創業，決定作一個叫「淘車網」的平臺。

故事發展

淘車網一開始是一個 all in one 的 java 應用，部署在一臺物理機上(小王同窗，如今都啥時候了，你須要瞭解一下阿里雲)，隨着業務的發展，機器愈來愈扛不住了，就趕忙對服務器的規格作了升級，從 64c256g 一路升到了 160c1920g，雖然成本高了點，可是系統至少沒出問題。

業務發展了一年後，160c1920g 也扛不住了，不得不進行服務化拆分、分佈式改造了。爲了解決分佈式改造過程當中的各類問題，引入了一系列的中間件，相似 hsf、tddl、tair、diamond、metaq 等，在艱難的業務架構改造後，咱們成功的把 all in one 的 java 應用拆分紅了多個小應用，重走了一遍當年阿里中間件發展和去 IOE 的道路。

分佈式改完後，咱們管理的服務器又多起來了，不一樣批次的服務器，硬件規格、操做系統版本等等都不盡相同，因而應用運行和運維的各類問題就出來了。

還好有虛擬機技術，把底層各類硬件和軟件的差別，經過虛擬化技術都給屏蔽掉了。雖然硬件不一樣，可是對於應用來講，看到的都是同樣的啦，此時虛擬化又產生了很大的性能開銷。

恩，不如咱們使用 docker 吧，由於 docker 基於 cgroup 等 Linux 的原生技術，在屏蔽底層差別的同時，也沒有明顯的性能影響，真是一個好東西。並且基於 docker 鏡像的業務交付，使得咱們 CI/CD 的運做也很是的容易。

不過隨着 docker 容器數量的增加，咱們又不得不面對新的難題，就是大量的 docker 如何調度、通訊呢？畢竟隨着業務發展，淘車網已經不是一個小公司了，咱們運行着幾千個 docker 容器，而且按照如今的業務發展趨勢，立刻就要破萬了。

不行，咱們必定要作一個系統，這個系統可以自動的管理服務器（好比是否是健康、剩下多少內存和 cpu 可使用啊等等）、而後根據容器聲明所需的 cpu 和 memory 選擇最優的服務器進行容器的建立，而且還要可以控制容器和容器之間的通訊（好比說某個部門的內部服務，固然不但願其餘部門的容器也可以訪問）。

咱們給這個系統取一個名字，就叫作容器編排系統吧。

容器編排系統

那麼問題來了，面對一堆的服務器，咱們要怎麼實現一個容器編排系統呢？

先假設咱們已經實現了這個編排系統，那麼咱們的服務器就會有一部分會用來運行這個編排系統，剩下的服務器用來運行咱們的業務容器，咱們把運行編排系統的服務器叫作 master 節點，把運行業務容器的服務器叫作 worker 節點。

既然 master 節點負責管理服務器集羣，那它就必需要提供出相關的管理接口，一個是方便運維管理員對集羣進行相關的操做，另外一個就是負責和 worker 節點進行交互，好比進行資源的分配、網絡的管理等。

咱們把 master 上提供管理接口的組件稱爲 kube apiserver，對應的還須要兩個用於和 api server 交互的客戶端：

• 一個是提供給集羣的運維管理員使用的，咱們稱爲 kubectl；
• 一個是提供給 worker 節點使用的，咱們稱爲 kubelet。

如今集羣的運維管理員、master 節點、worker 節點已經能夠彼此間進行交互了，好比說運維管理員經過 kubectl 向 master 下發一個命令：「用淘車網用戶中心 2.0 版本的鏡像建立 1000 個容器」，master 收到這個請求以後，就要根據集羣裏面 worker 節點的資源信息進行一個計算調度，算出來這 1000 個容器應該在哪些 worker 上進行建立，而後把建立指令下發到相應的 worker 上。咱們把這個負責調度的組件稱爲 kube scheduler。

那 master 又是怎麼知道各個 worker 上的資源消耗和容器的運行狀況的呢？這個簡單，咱們能夠經過 worker 上的 kubelet 週期性的主動上報節點資源和容器運行的狀況，而後 master 把這個數據存儲下來，後面就能夠用來作調度和容器的管理使用了。至於數據怎麼存儲，咱們能夠寫文件、寫 db 等等，不過有一個開源的存儲系統叫 etcd，知足咱們對於數據一致性和高可用的要求，同時安裝簡單、性能又好，咱們就選 etcd 吧。

如今咱們已經有了全部 worker 節點和容器運行的數據，咱們能夠作的事情就很是多了。好比前面所說的，咱們使用淘車網用戶中心 2.0 版本的鏡像建立了 1000 個容器，其中有 5 個容器都是運行在 A 這個 worker 節點上，那若是 A 這個節點忽然出現了硬件故障，致使節點不可用了，這個時候 master 就要把 A 從可用 worker 節點中摘除掉，而且還須要把原先運行在這個節點上的 5 個用戶中心 2.0 的容器從新調度到其餘可用的 worker 節點上，使得咱們用戶中心 2.0 的容器數量可以從新恢復到 1000 個，而且還須要對相關的容器進行網絡通訊配置的調整，使得容器間的通訊仍是正常的。咱們把這一系列的組件稱爲控制器，好比節點控制器、副本控制器、端點控制器等等，而且爲這些控制器提供一個統一的運行組件，稱爲控制器管理器（kube-controller-manager）。

那 master 又該如何實現和管理容器間的網絡通訊呢？首先每一個容器確定須要有一個惟一的 ip 地址，經過這個 ip 地址就能夠互相通訊了，可是彼此通訊的容器有可能運行在不一樣的 worker 節點上，這就涉及到 worker 節點間的網絡通訊，所以每一個 worker 節點還須要有一個惟一的 ip 地址，可是容器間通訊都是經過容器 ip 進行的，容器並不感知 worker 節點的 ip 地址，所以在 worker 節點上須要有容器 ip 的路由轉發信息，咱們能夠經過 iptables、ipvs 等技術來實現。那若是容器 ip 變化了，或者容器數量變化了，這個時候相關的 iptables、ipvs 的配置就須要跟着進行調整，因此在 worker 節點上咱們須要一個專門負責監聽並調整路由轉發配置的組件，咱們把這個組件稱爲 kube proxy。

咱們已經解決了容器間的網絡通訊，可是在咱們編碼的時候，咱們但願的是經過域名或者 vip 等方式來調用一個服務，而不是經過一個可能隨時會變化的容器 ip。所以咱們須要在容器 ip 之上再封裝出一個 service 的概念，這個 service 能夠是一個集羣的 vip，也能夠是一個集羣的域名，爲此咱們還須要一個集羣內部的 DNS 域名解析服務。

另外雖然咱們已經有了 kubectl，能夠很愉快的和 master 進行交互了，可是若是有一個 web 的管理界面，這確定是一個更好的事情。此處以外，咱們可能還但願看到容器的資源信息、整個集羣相關組件的運行日誌等等。

像 DNS、web 管理界面、容器資源信息、集羣日誌，這些能夠改善咱們使用體驗的組件，咱們統稱爲插件。

至此，咱們已經成功構建了一個容器編排系統，下面咱們來簡單總結一下上文提到的各個組成部分：

• Master 組件：kube-apiserver、kube-scheduler、etcd、kube-controller-manager；
• Node 組件：kubelet、kube-proxy；
• 插件：DNS、用戶界面 Web UI、容器資源監控、集羣日誌。

這些也正是 K8s 中的重要組成部分。固然 K8s 做爲一個生產級別的容器編排系統，這裏提到的每個組件均可以拿出來單獨講上不少內容，本文只是一個簡單入門，再也不展開講解。

Serverless 的容器編排系統

雖然咱們已經成功實現了一個容器編排系統，而且也用的很舒服，可是淘車網的王總裁（已經不是當年的小王了）以爲公司花在這個編排系統上的研發和運維成本實在是過高了，想要縮減這方面的成本。王總想着有沒有一個編排系統，可以讓員工專一到業務開發上，而不須要關注到集羣的運維管理上，因而他和技術圈的同窗瞭解了一下，發現 Serverless 的理念和他的想法不謀而合，因而就在想：啥時候出一個 Serverless 的容器編排系統就好啦。

幸運的是，王總在阿里雲網站上，看到了一款叫作 Serverless Kubernetes 的產品。。。後面的故事就不展開講了，由於到了這個地方，更重要的事情就出現了。

招人啦！

雲原生和 ECI 研發團隊招人啦，讓咱們一塊兒打造業界領先的雲原生和彈性計算服務，爲社會提供穩定高效的數字經濟基礎設施！

• 3 年以上分佈式系統相關經驗，熟悉高併發，分佈式通訊，存儲等相關技術；
• 熟練掌握 Golang/Java/Rust 語言開發，具有 Python, Shell 等其它一種或多種語言開發經驗；
• 對容器和基礎設施相關領域的技術充滿熱情，有 PaaS 平臺相關經驗，在相關的領域如 Kubernetes、Serverless 平臺、容器技術、應用管理平臺等有豐富的積累和實踐經驗（如產品落地，創新的技術實現，開源的突出貢獻，領先的學術研究成果等）。

簡歷投遞通道：

• cloudnativehire@list.alibaba-inc.com（雲原生）
• lingzhi.wlz@alibaba-inc.com（ECI）

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