2020年開始我在公眾號上分享 K8s 學(xué)習(xí)筆記的時候?qū)儆谶厡W(xué)邊寫，每學(xué)會一塊內(nèi)容，記錄總結(jié)發(fā)布在公眾號上。如今回看，發(fā)現(xiàn)很多內(nèi)容、知識點寫的過于生硬，很多名詞不知道是干什么的，就直接翻譯了過來，這就導(dǎo)致文字沒有溫度，內(nèi)容層次也不夠。

所以嘗試重新組織語言、文章段落，把 K8s 的這些知識寫的更有層次些，讓大家更容易讀懂，更有溫度，不再是覺得對文檔的翻譯和概念的堆砌。

K8s基礎(chǔ)入門和實踐--大綱

前三篇理論，后兩篇實踐，理論篇也會有一些例子，不會讓文章內(nèi)容太枯燥。其實之前已經(jīng)寫過一篇 Docker 與 K8s 的關(guān)系，算是進入K8s學(xué)習(xí)之前的預(yù)熱，先分清兩者的關(guān)系。

本篇文章聚焦K8s的整體架構(gòu)，給大家描繪出K8s的大致模樣。

K8s 是什么

Kubernetes（單詞太長，后面用 K8s 代替 ）是一個基于容器技術(shù)的分布式架構(gòu)方案，它源自Google內(nèi)部大規(guī)模集群管理系統(tǒng)——Borg，自2015年開源后得到開源社群的全力支援，IBM、惠普、微軟、RedHat等業(yè)界巨頭紛紛加入，成為后來的 CNCF 組織（Cloud Native Computing Foundation，云原生計算基金會）首個畢業(yè)的項目。

K8s 具備完善的集群管理能力，包括多層次的安全防護和準入機制、多租戶應(yīng)用支撐能力、透明的服務(wù)注冊和服務(wù)發(fā)現(xiàn)機制、內(nèi)建負載均衡器、故障發(fā)現(xiàn)和自我修復(fù)能力、服務(wù)滾動升級和線上擴容、可擴展的資源自動調(diào)度機制、多粒度的資源配額管理能力。還提供完善的管理工具，涵蓋開發(fā)、部署測試、運維監(jiān)控等各個環(huán)節(jié)。

總結(jié)一句話：是一套結(jié)合了容器編排和集群調(diào)度管理的大規(guī)模分布式系統(tǒng)解決方案。

K8s 長什么樣子

K8s 不是我們現(xiàn)實可以看到摸到的一個東西，所以初學(xué)者看完 K8s 是什么的描述后，可能也是覺得云里霧里。那么這里我就嘗試描繪一下 K8s 它到底長什么樣子。描述一個解決方案的樣貌，其實直白點說就是它的整體架構(gòu)是什么樣的，由哪些核心部分組成，每個部分相互怎么交互這些。

我們先來看一下K8s的整體的結(jié)構(gòu)。

K8s 的整體結(jié)構(gòu)

K8s 采用Master / Work Node（最初稱為Minion，后改名Node） 的結(jié)構(gòu)，Master Node（主節(jié)點）控制整個集群，Work Node（從節(jié)點）為集群提供計算能力。使用者可以通過命令行或者 Web 控制臺頁面的方式來操作集群。

下圖可以清楚地表示出 K8s 的整體架構(gòu)

K8s 的整體架構(gòu)圖

了解到 K8s 由主節(jié)點、工作節(jié)點兩大部分組成后，接下來我們逐一展開，看看主節(jié)點和工作節(jié)點分別由哪些組件構(gòu)成。

主節(jié)點

Master 節(jié)點是 K8s 集群的大腦，負責向外開放集群的 API，調(diào)度和管理整個集群。集群至少要有一個Master節(jié)點，如果在生產(chǎn)環(huán)境中要達到高可用，還需要配置 Master 集群。

下面這張圖，描繪出了主節(jié)點內(nèi)部的結(jié)構(gòu)。

K8s主節(jié)點內(nèi)部結(jié)構(gòu)

Master主要包含 API Server、Scheduler、Controllers? 三個組成部分， 以及用作存儲的 etcd，它用來儲存整個集群的狀態(tài)。

• etcd：由CoreOS開發(fā)，是一個高可用、強一致性的鍵值存儲，為Kubernetes集群提供儲存服務(wù)，類似于zookeper。它會存儲集群的整個配置和狀態(tài)。主節(jié)點通過查詢 etcd 以檢查節(jié)點，容器的現(xiàn)狀。
• API Server：kubernetes最重要的核心元件之一，提供資源操作的唯一入口（其他模塊通過API Server查詢或修改資源對象，只有API Server才能直接操作etcd），并提供認證、授權(quán)、訪問控制、API注冊和發(fā)現(xiàn)等機制。
• Scheduler：負責資源的調(diào)度，按照預(yù)定的調(diào)度策略將 Pod（k8s中調(diào)度的基本單位）調(diào)度到相應(yīng)的Node上，這里說的 Node 就是Work Node，當然如果是只有一個節(jié)點的集群，Master 也會同時作為 Work Node。
• Controllers：通過 API Server 查詢要控制的資源對象的預(yù)期狀態(tài)，它檢查其管控的對象的當前狀態(tài)，確保它們始終處于預(yù)期的工作狀態(tài)，它們的工作包括比如故障檢測、自動擴充、減少、滾動更新等。

我們能接觸到的控制器有，下面這些：

• Deployment
• StatuefulSet
• Service
• DaemonSet
• Ingress

具體干什么的，放到下篇文章—K8s面向?qū)ο笤僭敿毥榻B，沒錯想用K8s，你也得面向?qū)ο?，可怕不。到時候會結(jié)合著例子一塊看。

我們繼續(xù)看K8s 的工作節(jié)點的內(nèi)部結(jié)構(gòu)。

工作節(jié)點

K8s 集群的工作節(jié)點，可以是物理機也可以是虛擬機器。Node 上運行的主要 K8s 組件有kubelet、kube-proxy、Container Runtime 、Pod 等。

K8s 工作節(jié)點的內(nèi)部結(jié)構(gòu)

kubelet

K8s 集群的每個工作節(jié)點上都會運行一個 kubelet 程序 維護容器的生命周期，它接收并執(zhí)行Master 節(jié)點發(fā)來的指令，管理節(jié)點上的 Pod 及 Pod 中的容器。同時也負責Volume（CVI）和網(wǎng)絡(luò)（CNI）的管理。

每個 kubelet 程序會在 API Server 上注冊節(jié)點自身的信息，定期向Master節(jié)點匯報自身節(jié)點的資源使用情況，并通過cAdvisor監(jiān)控節(jié)點和容器的資源。

通過運行 kubelet，節(jié)點將自身的 CPU，RAM 和存儲等計算機資源變成集群的一部分，相當于是放進了集群統(tǒng)一的資源管理池中，交由 Master 統(tǒng)一調(diào)配。

Container Runtime

容器運行時負責與容器實現(xiàn)進行通信，完成像容器鏡像庫中拉取鏡像，然后啟動和停止容器等操作， 引入容器運行時另外一個原因是讓 K8s 的架構(gòu)與具體的某一個容器實現(xiàn)解耦，不光是 Docker 能運行在 K8s 之上，同樣也讓K8s 的發(fā)展按自己的節(jié)奏進行。

想要運行在我的生態(tài)里的容器，請實現(xiàn)我的CRI （Container Runtime Interface），Container Runtime 只負責調(diào)用CRI 里定義的方法完成容器管理，不單獨執(zhí)行 docker run 之類的操作。這個也是K8s 發(fā)現(xiàn)Docker 制約了它的發(fā)展在 1.5 后引入的。

Pod

Pod 是 K8s 中的最小調(diào)度單元。我們的應(yīng)用程序運行在容器里，而容器又被分裝在 Pod 里。一個 Pod 里可以有多個容器，也可以有多個容器。沒有統(tǒng)一的標準，是單個還是多個，看要運行的應(yīng)用程序的性質(zhì)。不過一個 Pod 里只有一個主容器，剩下的都是輔助主容器工作的。

比如做服務(wù)網(wǎng)格 Istio 的 Envoy 網(wǎng)關(guān)，就是放在Pod的輔助容器運行來實現(xiàn)流量控制的。 這就是 K8s 的容器設(shè)計模式里最常用的一種模式：sidecar。顧名思義，sidecar 指的就是我們可以在一個Pod中，啟動一個輔助容器，來完成一些獨立于主進程（主容器）之外的工作。

kube-proxy

為集群提供內(nèi)部的服務(wù)發(fā)現(xiàn)和負載均衡，監(jiān)聽 API Server 中 Service 控制器和它后面掛的 endpoint 的變化情況，并通過 iptables 等方式來為 Service 的虛擬IP、訪問規(guī)則、負載均衡。

總結(jié)

本篇文章聚焦K8s的整體架構(gòu)，給大家描繪出K8s的大致模樣。下一節(jié)我們來說說 K8s 的面向?qū)ο?，以及我們能接觸到的常用控制器對象。此刻看到這句話你的心情可能是："納尼，這廝也是面向?qū)ο螅棵嫦驅(qū)ο螅趺蠢鲜悄悖?

是的，K8s 也是面向?qū)ο蟮?，而且面向的還很徹底，就跟某語言說的一切皆對象一樣徹底。不過正因為它是面向?qū)ο蟮?，那么以面向?qū)ο蟮姆绞絹硭伎歼@些東西，反而會很好理解，畢竟我們每天都要面向"對象"，不是么：）。