2020年開始我在公眾號上分享 K8s 學習筆記的時候屬于邊學邊寫，每學會一塊內容，記錄總結發布在公眾號上。如今回看，發現很多內容、知識點寫的過于生硬，很多名詞不知道是干什么的，就直接翻譯了過來，這就導致文字沒有溫度，內容層次也不夠。

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

K8s基礎入門和實踐--大綱

前三篇理論，后兩篇實踐，理論篇也會有一些例子，不會讓文章內容太枯燥。其實之前已經寫過一篇 Docker 與 K8s 的關系，算是進入K8s學習之前的預熱，先分清兩者的關系。

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

K8s 是什么

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

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

總結一句話：是一套結合了容器編排和集群調度管理的大規模分布式系統解決方案。

K8s 長什么樣子

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

我們先來看一下K8s的整體的結構。

K8s 的整體結構

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

下圖可以清楚地表示出 K8s 的整體架構

K8s 的整體架構圖

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

主節點

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

下面這張圖，描繪出了主節點內部的結構。

K8s主節點內部結構

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

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

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

• Deployment
• StatuefulSet
• Service
• DaemonSet
• Ingress

具體干什么的，放到下篇文章—K8s面向對象再詳細介紹，沒錯想用K8s，你也得面向對象，可怕不。到時候會結合著例子一塊看。

我們繼續看K8s 的工作節點的內部結構。

工作節點

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

K8s 工作節點的內部結構

kubelet

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

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

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

Container Runtime

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

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

Pod

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

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

kube-proxy

為集群提供內部的服務發現和負載均衡，監聽 API Server 中 Service 控制器和它后面掛的 endpoint 的變化情況，并通過 iptables 等方式來為 Service 的虛擬IP、訪問規則、負載均衡。

總結

本篇文章聚焦K8s的整體架構，給大家描繪出K8s的大致模樣。下一節我們來說說 K8s 的面向對象，以及我們能接觸到的常用控制器對象。此刻看到這句話你的心情可能是："納尼，這廝也是面向對象？面向對象，怎么老是你？"

是的，K8s 也是面向對象的，而且面向的還很徹底，就跟某語言說的一切皆對象一樣徹底。不過正因為它是面向對象的，那么以面向對象的方式來思考這些東西，反而會很好理解，畢竟我們每天都要面向"對象"，不是么：）。